OSDev.org

Sorry for being so annoying but how do I know which drive is loaded my operating system? For example a IDE or SATA drive.

What if 2 drives have exactly the same content? Cloned drives for example.

How detect the real boot drive?

Thanks for advance!


EDIT: Assuming that I have implemented storage drivers.

Easy way - Get the user to tell you. (EDIT: I.e. via a kernel option, usually stored in the bootloader's config. Linux does this with the ROOT=<devname> option)
Harder way - Get the bootloader to tell you (e.g. multiboot contains the BIOS drive and partition number) and convert that to the device name.

thepowersgang wrote:Easy way - Get the user to tell you. (EDIT: I.e. via a kernel option, usually stored in the bootloader's config. Linux does this with the ROOT=<devname> option)

What if the same bootloader is 2 units with the same format and the same serial number for example?

thepowersgang wrote:Harder way - Get the bootloader to tell you (e.g. multiboot contains the BIOS drive and partition number) and convert that to the device name.

Without multiboot please. How multiboot get partition number?

Well, if the bootloader config is the same, you'll boot from the same disk.

The bootloader gets the disk is was booted from by some firmware specific method (e.g. for the BIOS, the BIOS disk number is passed in DL, uEFI would probably pass the same information another way).

The best method is to use a bootloader config, because that allows storing the kernel and bootloader on a different disk to the system disk (e.g. for a network terminal, the kernel will be loaded via TFTP, but the filesystem would be mounted via NFS)

Hi,

lweb20 wrote:How detect the real boot drive?

For booting from disk on BIOS systems; the BIOS tells you which "device number" in DL, and you'd convert that into something more specific (e.g. which device on which controller on which bus) by using the Int 0x13 Extensions, GET DRIVE PARAMETERS BIOS function. If that function isn't supported or doesn't help then you'd fall back to the older GET DRIVE PARAMETERS function, which may need to be combined with something else (e.g. in case there's several devices with the same number of cylinders, heads and sectors per track).

For UEFI, I think it's possible (but haven't tried it) to convert the "disk IO protocol" number you're given by the firmware into a "which device on which controller on which bus" format using the EFI_DEVICE_PATH_PROTOCOL.

Another approach that can be used (instead of or in addition to using the firmware's functions) is to record the disk drive's serial number and/or the "which device on which controller on which bus" information into the boot loader when the boot loader is being installed. This is not fool-proof - e.g. nothing prevents the user from cloning their disk drive so that everything is the same except the disk drive's serial number, and nothing prevents the user from unplugging the disk drive and plugging it in somewhere else.

My last alternative is "stamping". During boot, your boot loader can generate a random-ish number/GUID (e.g. possibly derived from the real time clock or something), and write that number to the boot device and give the number to your kernel. That way your kernel can search for the device that has the same "random-ish number/GUID" stored in the correct place, and be relatively sure that it has found the correct device. This method is immune to disk cloning and hardware reconfiguration problems. Of course when I say "relatively sure" I mean there's still a chance of collisions (e.g. where one or more other devices happen to have the same bytes by accident) that depends on the size of the number/GUID you use and how much entropy you can cram into it (probably not very much entropy if you're only able to use the RTC). The other disadvantage here is that your boot code needs to write to the disk, which means it can't work for "read only" devices (and there's a small chance of write errors).

Also note that the best approach may be a combination of several alternatives, where you choose the device that has the highest probability of being the boot device based on all sources of information available.

For other media everything may be different. For example, for booting from network it's relatively easy to remember the MAC address of the local network card, the IP address of the TFTP server and the file name/s it downloaded (but extremely hard to determine if IP addresses or remote files have changed while you were booting). There's also possible complications; like "firmware supported software RAID", where you're booting from a set of disks and not booting from one disk; people booting from USB and unplugging the device while you're booting; etc.


Cheers,

Brendan

Brendan wrote:Hi,

lweb20 wrote:How detect the real boot drive?

For booting from disk on BIOS systems; the BIOS tells you which "device number" in DL, and you'd convert that into something more specific (e.g. which device on which controller on which bus) by using the Int 0x13 Extensions, GET DRIVE PARAMETERS BIOS function. If that function isn't supported or doesn't help then you'd fall back to the older GET DRIVE PARAMETERS function, which may need to be combined with something else (e.g. in case there's several devices with the same number of cylinders, heads and sectors per track).

...

Another approach that can be used (instead of or in addition to using the firmware's functions) is to record the disk drive's serial number and/or the "which device on which controller on which bus" information into the boot loader when the boot loader is being installed. This is not fool-proof - e.g. nothing prevents the user from cloning their disk drive so that everything is the same except the disk drive's serial number, and nothing prevents the user from unplugging the disk drive and plugging it in somewhere else.

My last alternative is "stamping". During boot, your boot loader can generate a random-ish number/GUID (e.g. possibly derived from the real time clock or something), and write that number to the boot device and give the number to your kernel. That way your kernel can search for the device that has the same "random-ish number/GUID" stored in the correct place, and be relatively sure that it has found the correct device. This method is immune to disk cloning and hardware reconfiguration problems. Of course when I say "relatively sure" I mean there's still a chance of collisions (e.g. where one or more other devices happen to have the same bytes by accident) that depends on the size of the number/GUID you use and how much entropy you can cram into it (probably not very much entropy if you're only able to use the RTC). The other disadvantage here is that your boot code needs to write to the disk, which means it can't work for "read only" devices (and there's a small chance of write errors).

Also note that the best approach may be a combination of several alternatives, where you choose the device that has the highest probability of being the boot device based on all sources of information available.

...

Thanks for the response. I will use the extensions, and if not work "get drive parameters" and other methods such BPB check, and finally time method (if possible).

Disk drive's serial number (using bios)?

EDIT: I finished getting the disc number (dl) with their data but what about the partition number? (no multiboot) Can be examining the MBR?

lweb20 wrote: Thanks for the response. I will use the extensions, and if not work "get drive parameters" and other methods such BPB check, and finally time method (if possible).

Disk drive's serial number (using bios)?

EDIT: I finished getting the disc number (dl) with their data but what about the partition number? (no multiboot) Can be examining the MBR?

Your bootloader implicitly knows the partition (it loaded the kernel from it!), so it should just pass that on...

Hi,

lweb20 wrote:EDIT: I finished getting the disc number (dl) with their data but what about the partition number? (no multiboot) Can be examining the MBR?

Most boot managers support a variety of "slightly less than standard" tricks, like pretending a partition is active when it's not, booting from an extended partitions, booting from the second (or third, or ...) hard disk, etc. Examining the real MBR can break these tricks.

When the MBR/boot manager passes control to your boot sector it's supposed to make sure DS:SI points to the partition table entry for your partition (and DL contains the device number). This is what you should use.


Cheers,

Brendan

Bootloader can do following:
- record partition serial number / volume label
- calculate MD5 checksum of first 512KiB (1024 sectors assuming they are 512 bytes) of boot partition
- OS then knows exactly what partition was boot partition

This assumes there aren't 2 identical partitions.
In the extremely unlikely event there are 2 identical partitions..... it doesn't matter. The OS can use either one to load its kernel, modules etc.

For GPT, the partition UUID is a good fallback guess. You should probably do the same as Windows does - scan all partitions at startup; if it finds duplicates, it renames them

Brendan wrote:Most boot managers support a variety of "slightly less than standard" tricks, like pretending a partition is active when it's not, booting from an extended partitions, booting from the second (or third, or ...) hard disk, etc. Examining the real MBR can break these tricks.

When the MBR/boot manager passes control to your boot sector it's supposed to make sure DS:SI points to the partition table entry for your partition (and DL contains the device number). This is what you should use.

Thank you very much, I did not know. But what if there are no MBR? (a virtual hard disk for example)

lweb20 wrote:Thank you very much, I did not know. But what if there are no MBR? (a virtual hard disk for example)

A virtual device is to resemble a real device. If a virtual disk has no bootloader, you can't boot from it.

Combuster wrote:

lweb20 wrote:Thank you very much, I did not know. But what if there are no MBR? (a virtual hard disk for example)

A virtual device is to resemble a real device. If a virtual disk has no bootloader, you can't boot from it.

I meant virtual disks with .img extension, as if it were a floppy but in fat32 filesystem.
edit: without MBR, only BPB.

Combuster wrote:If a virtual disk has no bootloader, you can't boot from it.

Try reading

Combuster wrote:

Combuster wrote:If a virtual disk has no bootloader, you can't boot from it.

Try reading

My virtual disk have a bootloader but not have MBR.