2Pete:
I have not really used either of my eCS installations since installing ArcaOS but decided to try booting eCS2.1 with various ArcaOS Driver Pack updates. Boot stops with a SYS1201: vboxdrv.sys not installed.
The same problem with eCS2.2b2 - which surprised me as ecS2.2b2 is the system that was in use when I first installed and used VirtualBox successfully.
Both eCS installations are using acpi 3.23.05 and os2krnl 14_106 SMP
Hm, VBoxDrv.sys doesn't install? I can't imagine why this can happen. Tried many kernels and PSD drivers -- never seen this. Could
you try to help me to track why this happen? So, this happens with 14.106_SMP and ACPI.PSD 3.23.05? I tested this combination, and everything booted well. I tested it in MCP2 and eCS 2.2 beta II, on a single-core Athlon 64 machine and two Core2Duo machines -- all worked well. Can you give me more details? Did you installed any other updates except the kernel and ACPI.PSD? Are you sure it was ACPI 3.23.05? Maybe, it was some other version? (also, it's possible that AN has different builds having the same version number, which behave differently. We can exchange more bldlevel details. For example, the copy of ACPI.PSD 3.23.05 I have is built 1 Feb 2017 12:52:11. Does your copy differ?)
Failed to create the VirtualBoxClient COM object.
The application will now terminate.
Callee RC: NS_ERROR_ABORT (0x80004004)
This happens when VBox cannot load VBoxRT.dll or some other DLL. This is usually because some dependent DLL's installed via rpm packages are missing, or are different version. You could try to update, or better, remove the DLL's listed here:
http://trac.netlabs.org/vbox/ and install them over. This is basically the same problem as with newer versions of Mozilla, when some DLL's XUL.DLL depends on, are missing or incorrect version.
2Doug Bissett:
I run the old VBox 1.6.1, and the beta 5.0.6, under ArcaOS. No unexpected problems. The won't run OS/2, because you need VT-x/AMD-V enabled, and the OS/2 versions of VBox can't do that (be sure that the option is turned off). You can run a 64 bit OS, as a guest, but it will be dead slow, so don't bother even trying (like 12 hours to boot win 7 64 bit).
OS/2 versions of VBox since about r147 support hardware assisted virtualization. I was able to run OS/2 guest on OS/2 host successfully. 64-bit OS'es currently don't run ok. Most probably, you will get a hang. But it is still being worked on. Though, because of limitations of IBM kernels, this is currently supported on OS/4 kernels, only. They have some required mechanisms like API's for running some code on all CPU's in parallel, getting the current CPU number etc.
How did you managed to run a 64-bit OS? On which VBox version? I was unable to run a 64 bit OS neither in RAW mode, nor with HW virtualization.
2Dave Yeo: This error does nothing with NSPR. It is just a failed COM object initialization because it cannot load a DLL. NS_ERROR_ABORT seems to be an XPCOM error, not NSPR. Also, VBox doesn't use NSPR from yum repo. It carries its own version of NSPR based on VBox Runtime (IPRT, Innotek Portable RunTime) with itself.
BTW, about your ifx error. I saw dmt (the eCS version of ifx) hangs in the past with eCS but none with ArcaOS. Doug might have a point in the ordering in config.sys.
I never seen this in my eCS with DMT. Also, I have no idea how IFX/DMT can hang, or not, depending on VBoxDrv position in config.sys. I suspect this is some SMP-related problem, though.
2Pete*2:
The resolution to the "timing problem" with the vboxdrv.sys was to move the line higher up the config.sys file - no problem booting now, no need to use Shift as IFX is starting.
Probably, this is indeed some timing problem, so before VBoxDrv "settles a bit", i.e., finishes some activity, and activity done by IFX, should pass some time. An idea may be that VBoxDrv and IFX do something at the same time, but on different CPU's. This somehow leads to a hang. Currently SMP support in VBoxDrv is limited on IBM kernels. IBM kernels have no API returning the current CPU number. So, this is currently emulated with finding the current local APIC number. But LAPIC numbers are not guaraneteed to be consecutive. The may be "holes" between valid LAPIC numbers. So, if an attempt to use an invalid CPU number from the hole in the range 0..MaxCPUNumber is made, an unexpected result can happen, e. g., a hang. So, this currently works reliably only on OS/4 kernels, where an API exist returning a correct CPU number from a contiguous range. VBox assumes that the range 0..MaxCPUNumber should be contiguous.
PS: I never sort CONFIG.SYS automatically, because I prefer to edit it manually. So, I have it being sorted out logically, grouping related statements together. This is easier to support, with a little performance impact. I always placed the VBoxDrv.sys loading string at the end of CONFIG.SYS.