When a system has more than one disk, and those disks are connected to different controller types that use different disk drivers, various issues can arise. When you have more than one disk in your system, you already have to be careful of which disk is the one that becomes disk 0, and you also have to be careful if that changes during the boot process. When those disk are on different types of controllers, the issues compound.
This page explains some of the details about the issues involved when you have more than one storage controller in your system. For those who want to just skip to the end and get the short version, the solution that works in most cases is to just make sure that the order of device drivers in your config.sys matches the detected order of device types in the BIOS. Note that the detected order of device types in the BIOS is not the same as the boot order in the BIOS.
For the purposes of the examples on this page, it will be assumed that there is one NVME device and one AHCI disk and that AirBoot is the boot manager. The problems and solutions provided apply to other types of disks, configurations, and combinations as well.
The BIOS phase of the boot process
Many modern BIOS have options to select the boot order and may have a specific menu to choose the boot device for any particular boot. Which disk is chosen by the BIOS can change from BIOS to BIOS, and can change from boot to boot. A UEFI BIOS complicates this even more depending whether or not the CSM is enabled and whether or not if finds an ESP. Once the BIOS has chosen a disk to boot from, the BIOS reads the initial boot loader from the disk. This could be from the ESP in the case of a UEFI BIOS, or from block 0 in the case of a traditional BIOS or a UEFI BIOS through a CSM.
To boot ArcaOS from a device (AHCI or NVME), the BIOS must have support for that device to be able to read the initial boot loader from the device (whether from the ESP or from block 0), and then it must be be able to supply services to the boot loader to read the kernel and base drivers from the media.
Note that the boot device selected in the BIOS is only the device the boot loader is loaded from, not the device or partition the OS is loaded from. It is possible for the initial boot loader (AirBoot, for example) to be read from the AHCI disk, and then the boot loader (AirBoot, or whatever) to read the OS from the NVME device (or vice versa). When there are multiple devices involved, it can be confusing which device is which and since the boot loader uses BIOS services to read the OS, the boot loader and the BIOS must agree which disk is which or disk reads will fail.
Once the OS and the disk drivers are loaded and take over, BIOS services are no longer necessary. However, OS loading is still not complete and another point of confusion can occur. If the device the OS/2 drivers think it is booting from agrees with the device the BIOS was using to boot from, then everything proceeds normally. If they do not agree, the you get the “OS/2 is not able to operate your hard disk” error. With only one boot device present they almost always agree. However, anytime more than one device is present there is the possibility the boot device can change part way through the boot process.
If you have setup AirBoot on both disks, then it can be confusing which one is actually being used. The answer is whichever one the BIOS chooses to boot from. Also remember that whichever disk AirBoot is loaded from does not indicate which disk the OS is loaded from They can be different.
Loading the disk drivers and the operating system
Once the operating system is loading and the disk drivers are loaded, the order of the disk drivers in the config.sys becomes important. The disk connected to the first driver become disk 0. The disk connected to the second driver becomes disk 1. If the driver order in the config.sys put the ACHI driver first, and the NVME driver second. then the AHCI disk becomes disk 0 and the NVME disk becomes disk 1, which might be contrary to how the BIOS sees it. This will have an effect on things that assume disk 0 is the boot disk like partition managers, reboot selectors, and trap dumps.
Special care must be used when installing ArcaOS on a system with multiple disk types, or when booting ArcaOS on a system with multiple disk types. Early portions of the boot process use BIOS functions to read the disk before disk drivers and LVM ever get loaded. Things can get very confusing and problematic if the BIOS disk layout doesn’t agree with the ArcaOS disk layout.
Drive letter conflicts
When you have disks of different connection types, it is much easier to create partitions on both disks that are assigned the same drive letter. Normally this is not an issue because LVM simply moves the conflicting drive letter to a different drive letter. This happens all the time with removable USB disks. However consider the situation where you have an AHCI disk setup with a bootable C:, a bootable D:, and another data partition E:. Now add an NVME disk with a single C: partition on it.
If the NVME driver is first and the AHCI driver is second, the NVME disk will stay C:, and the AHCI disk will get moved: C: becomes D:, D: becomes E:, and E: becomes F:. If you were booting C: and the NVME disk does not contain a bootable volume, the you will get the dreaded “OS/2 cannot operate your disk” message. If you try booting D: in this configuration, you will actually be booting the C: partition on the AHCI disk. File names in config.sys will point to C: not D: and things get very confused.
If the AHCI driver is first, and the NVME driver is second, the AHCI disk will stay as assigned, and the NVME disk will move to F: However, it is the NVME disk that the BIOS thinks it is booting, and it is the AirBoot on the NVME disk that gets used.
Things that assume disk 0 is the boot disk
MiniLVM can install and remove AirBoot. MiniLVM assumes that what it thinks is disk 0 is the boot disk. If this doesn’t match with what the BIOS thinks is the boot disk, then any changes made by MiniLVM to the AirBoot boot manager will not have any effect on booting.
Reboot selectors such as XWP shutdown also operate on what it thinks is disk 0. If this doesn’t match what the BIOS thinks is the boot disk, then these operations will have no effect on booting.
Similarly, trap dumps are done by using BIOS functions so they get written to the first SADUMP partition it finds. If there is mismatch between what the BIOS thinks is the boot disk and what the operating system thinks is the boot disk, you may get unexpected results.
This entry last updated: by