Boot.ini – Mapping rdisk Value to Disk

bootlinuxwindows

Following are the contents of a sample boot.ini:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /NOEXECUTE=OPTIN /FASTDETECT
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows 2000 Professional" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP Home Edition" /NOEXECUTE=OPTIN /FASTDETECT

The rdisk value tells the physical disk number.

So, if I have three hard disks say:

/dev/sda
/dev/sdb
/dev/sdc

Then how to know which disk (/dev/sda or /dev/sdb or /dev/sdc) is rdisk(0) and which disk is rdisk(1), etc.?

Best Answer

Trial and error?

I'm sure there is a method by which Windows orders the disks, but even if I knew it, I wouldn't trust it and would alwasys check before changing stuff.

The boot.ini file gives you some clues, such as what operating system is on which disk. You may then be able to work it out from that. eg is there only one ntfs partition on a particular disk and two on others, what users are on each operating system and so have directories on each Windows system. You could even boot into each operating system and save a file in its system partition to help you.

(If you are trying to work out which disk a broken entry in boot.ini refers to, msconfig.exe has an option to check the boot paths to make sure that each option should boot.)

BIOS vs UEFI Hardware

When your power on your computer it has to start executing a program somewhere. Typically this is a ROM on the motherboard that contains a program, for a long time this program was called BIOS and it functioned in specific (somewhat) standard ways. It controlled some hardware features among other things but most importantly it passes control over to an OS on some other media in a well defined manner.

The BIOS "standard" program was later replaced by UEFI which has the same purpose (mostly) and it too has a method of passing control over to an OS on some other media.

BIOS boot

When BIOS boots, it reads the first sector from the primary boot device which is assumed to contain a bootloader and starts executing it. This first sector is called the Master Boot Record (MBR). The disk is assumed to be using the DOS partitioning scheme.

On the old DOS partitioning scheme (also sometimes referred to as MBR) a whopping 446 bytes of program space is reserved for the bootloader in the MBR. Who would ever need more than 446 bytes amirite? So larger bootloaders typically make use of a "feature" of the DOS partitioning scheme where there is around 1-2 MBs or so of unused space immediately following the MBR. The bootloader would have a "stage 1" and "stage 2" where stage 1 is stored in the MBR and simply loads stage 2 which is stored in this "unused" area.

UEFI boot

When UEFI boots it assumes that the primary boot device is using GPT, and looks for a partition with a specific type, namely: "EFI System Partition". This partition is assumed to FAT 12,16 or 32. Once found, it scans the partition for bootloaders by looking for files with names that end in .efi.

I found that in the context of installing grub, the texts I read were referring to the UEFI boot procedure as simply UEFI, and BIOS boot procedure as BIOS. Which was confusing as I thought they were talking about the actual software on the motherboard ROM.

At any rate an UEFI motherboard can still perform a BIOS boot procedure, typically called "Legacy Boot" or CSM in the UEFI settings.

GPT and DOS/MBR

While GPT differs greatly from the old MBR/DOS partitioning scheme, it has reserved the region where the bootloader on an MBR partitioned disk would reside. This means that you can install a "legacy" bootloader into this reserved space on GPT and use BIOS boot. However there is a caveat, remember that stage 1/2 thing? Yeah GPT doesn't have that "feature" and the reserved region is still only 446 bytes. So to house the stage 2 of the bootloader a special partition type was introduced: "bios_boot". So the bootloader has to be aware that it is being installed on a GPT disk and find the "bios_boot" partition and put it's stage 2 there and let stage 1 find this partition somehow.

Summary

So there are three ways you can boot:

UEFI boot + GPT

Create a partition to hold the bootloader(s), 100 MB or so should be more than enough, set it's type to "EFI System Partition", format it with FAT 12,16 or 32. Mount it somewhere, typically /boot/efi. Then tell grub to install an EFI loader: grub-install --efi-directory=/boot/efi.

UEFI boot should find the partition by looking at the partition table.

I am told that you can use the ESP for your '/boot' as well but I haven't tried.

BIOS boot + GPT

Create a partition to hold stage 2 of the loader, 1-2 MB typically, and set the type to "bios_boot". You do not need to put a filesystem on this partition or to mount it, grub will "own" it do the what it needs. The position of this partition on the disk should be irrelevant. Then install grub on MBR as usual grub-install /dev/sdx. Grub should detect that it is a GPT disk, find the bios boot partition (and complain if it doesn't!) and install the appropriate stage 1 and stage 2.

BIOS boot + MBR

Simply create a DOS partition scheme on your disk and use grub-install /dev/sdx to write the MBR, the bios boot partition is not needed.

Chain loading secondary drive with MBR from primary drive with GPT

So I found out that grub doesn't allow chain loading a BIOS bootloader from an UEFI bootloader for whatever reason. I personally don't see why it wouldn't be possible but at least grub doesn't seem to support it.

So to fix my issues I set my GPT drive as primary boot device in UEFI settings, then use BIOS boot to load grub from the GPT device as above. Which means that it is able to chain load Win7 from the MBR on the first disk.