os2-base insists upon modifying C:\CONFIG.SYS rather than os2_boot_drive CONFIG.SYS

[Lewis Rosenthal]

This is not a failure of getbootdrive.exe (as I originally thought). After reading ticket #339 and updating os2-rpm to 1-9, I can still reproduce the failure of the os2-base package to edit the correct CONFIG.SYS.

Example:

C:\CONFIG.SYS exists, but does not have any SHELL= statements in it.

U: is the current boot volume.

Reinstall, downgrade, or update os2-base on U:, and C:\CONFIG.SYS is edited to insert:

SET SHELL=U:/usr/bin/sh.exe
SET EMXSHELL=U:/usr/bin/sh.exe
SET CONFIG_SHELL=U:/usr/bin/sh.exe
SET MAKESHELL=U:/usr/bin/sh.exe
SET EXECSHELL=U:/usr/bin/sh.exe

U:\CONFIG.SYS is untouched (if entries are manually removed before reinstall/update, they are not added).

As getbootdrive.exe does return the correct drive, I'm not sure where else the os2_boot_drive or os2_config_sys macros could be failing. While this ticket is opened against os2-base, clearly the problem lies in an rpm macro which can potentially impact a number of other packages.

[Silvan Scherrer]

this seems like a macro expansion issue. we are looking at it

[dmik]

The reason behind this failure is this change to cube: ​http://trac.netlabs.org/cube/changeset/5. It broke the "magic" hack by Yuri Dario which would replace the drive letter in c:\config.sys with the drive letter of \OS2 in PATH (normally the OS/2 boot drive letter). I guess Yuri did this hack specifically to overcome the issue you are now facing.

Lewis, Silvan says that this change was made on behalf of your request. Can you please clarfy what was the exact situation where this Yuri's hack prevented cube from working on your side? This is needed for a proper workaround.

Back then we thought that eliminating this hack would be fine because we replaced c:\config.sys usages with a macro in .specs but didn't account for secondary macro expansion (which is surely necessary in this case).

And now I want to modify cube once again in order to still avoid secondary expansion but also fix the problem you had when you asked us to fix cube in the first place.

[Lewis Rosenthal]

Apologies for the wait, Dmitriy.

AIUI, with the hack in place, when the target file to be modified is on C: (specifically), its drive is changed to the boot drive, so, if booted from Z: and cube is called to modify C:\config.sys, it will instead modify Z:\config.sys.

Now, under the conditions normally used by rpm/yum/ANPM, the booted system is the one with the CONFIG.SYS to be modified, so this negative side-effect is not observed. Unfortunately for the ArcaOS installer, it will always be present. As a result, we initially utilized a different cube lacking Yuri's modification. This led to there being multiple cube releases not only available for install, but actually installed in ArcaOS (one by rpm and one installed in \sys\install), which function differently.

So, the actual fix, it would seem, would be to how the secondary macro expansion is handled. However, as a short term solution, I could see reimplementing Yuri's mod - but only when specifically called via a command line option - and then changing the %cube macro to utilize it.

[Silvan Scherrer]

please try latest os2-base from exp repo. there we added the right expansion. If this is the final solution we are discussing

[Lewis Rosenthal]

Testing now, and will advise later today.

Thanks a million!!!

[Lewis Rosenthal]

This seems to work as advertised, however, with some downgrading/updating, I did manage to run low on some memory resource. I'll have to check a bit more to see if something is now leaking which was not leaking before.

I'll either resolve this as fixed tomorrow or will advise as to what I find in terms of resource usage.

[Lewis Rosenthal]

My prior resource exhaustion must have been due to something else. I repeated my testcase 20+ times, and shared memory returned to the exact amount from which it started (no leaks).

At this point, I can say that this change has addressed the symptom we were seeing.

Thanks!