OSDev.org

Hi,
So this might be a dumb question but I can't seem to find a way to determine which disk is my boot sector loaded from, but it would be essential to load the rest of my bootloader.
Is there any way I can find this out without hard-coding the disk id into my program?
Thanks!

If you care to read,
The BIOS passes the drive number in DL. Now what those values mean is for you to
find. Wikipedia, Internet, Websites should have a lot of info about this.
Seriously this was the FIRST thing I was taught when I came to OSDev,
I'd say you'll save some trouble if you try to search the Web for such trivial things.

Somehow I couldn't find it anywhere. But thanks for the help!!

I don't usually hijack threads, but since creating another thread with a title similar to this (ie. Determining boot disk) would be dubious, here I am.

My question differs from the OPs somewhat: I don't have %dl and I'm loaded by GRUB. I have no interest in BIOS's 'drive number', since I'm exclusively using ATA to read/write the disk.

So what I'm looking for is some way to get the ATA drive (ie. primary/secondary and master/slave) that I booted from... I think Windows does this thing where it assumes the first active partition, but I don't want to do that (for obvious reasons)

Any clues?

Hi,

requimrar wrote:My question differs from the OPs somewhat: I don't have %dl and I'm loaded by GRUB. I have no interest in BIOS's 'drive number', since I'm exclusively using ATA to read/write the disk.

So what I'm looking for is some way to get the ATA drive (ie. primary/secondary and master/slave) that I booted from... I think Windows does this thing where it assumes the first active partition, but I don't want to do that (for obvious reasons)

If you do have the drive number from BIOS, then you can use the get drive parameters BIOS function to determine which disk on which controller it is.

Now, if you have a look at the "Boot Information Format" section in the multi-boot spec; you'll see there's "drives_length" and "drives_addr" fields (at offset 52 and 56, if flags[7] is set). You'll also notice that this is optional, does tell you drive numbers for potentially many disks, doesn't tell you which of those disks was the boot device, and doesn't tell you which disk on which controller any of them are. You might feel like assuming you booted from BIOS device 0x80, but of course that assumption can easily be wrong; and you might also feel like assuming that the first disk on the primary controller is device 0x80 (and that assumption can easily be wrong too).

Now imagine that when you install your OS you add a special marker on that drive/partition to say that this is where you booted from; and you write some code to search all the drives/partitions for that special marker. Further, let's assume that the user creates a backup of the drive/partition (e.g. copies the data "as is" to a different drive), or installs a second version of your OS, and now there's 2 drives/partitions with your special marker. This doesn't work reliably either.

Another option is to find and parse GRUB's configuration, and attempt to use that to figure out which drive GRUB was told your OS was booted from. This can't work reliably either (e.g. imagine 2 versions of your OS installed), would be very messy, and means that your OS can't boot from any other boot loader that support the multiboot specification.

Finally, the last option is to give up and use a kernel command line; where the boot loader passes some sort of "bootdev=??" string to your kernel. This mostly means end-user hassles, and hoping that the end-user didn't forget and didn't screw it up (but we all know the end user will forget and/or will screw it up, so... ).

Basically, the only way you can do it reliably is to get the information from the BIOS. Multiboot doesn't give you the information itself, and multiboot also doesn't give you the drive number (so you can't switch back to real mode and ask the BIOS yourself). The only real alternatives are to stop using multiboot (write your own boot loader so that it's easy to get the information you want), or to use a combination of several different unreliable techniques in the hope of ending up with something more reliable than any one of those techniques alone.

For example, you could parse GRUB's configuration to attempt to figure out which device number your OS was booted from, and have a special marker on the drive/partition, and have a command line option; and then assume that if 2 or more of the 3 different techniques give you the same answer then that answer is more likely to be the right answer.

Of course writing your own boot loader is likely to be easier than using multiboot...


Cheers,

Brendan

I would also like to suggest another solution. If you assume that at some point you will have an installer for you OS. And you assume you would be the one to write that installer, you can do something a little tricky

If you say that at some static offset in your kernel file is the information you need (Easily hard coded using dd, dw, or related in an assembler file) you could use this info in your kernel. And you would have your installer (at install time) write the correct information at these offsets.

This obviously has drawbacks such as not working if the user changes drives, though this can be resolved with a "fixboot" like command in a repair program/boot loader/what have you. And I'm sure some others.

This is the best way I have thought of solving this problem, and how I currently plan to handle it.

- Monk

The only reliable way I can think of, is to use the BIOS boot disk number (e.g. 80h) and query the BIOS parameter so that your get disk geometry.
Since the user may have used multiple disk of exactly same vendor, model and capacity, you read a random sector and get a checksum, and make sure every disk have different checksum, or signature.

Now you may identify such disk from your native device tree.

Next, within the disk you may have multiple installation in different partition, or even co-exist in same partition. So you need a way to identify the boot partition, one way is to inject a unique identifier in your VBR, and make sure any format tool does not create two volume of same identifier within same disk.

Now you know which disk and partition your OS boots from.

If you support multiple installation within same partition, it's now much easy to deal with in your custom boot loader, and I think I don't need much more explanation.

* Note that the above logic can be further optimized, like if the disk geometry alone can be uniquely determinate each disk, you may skip reading sectors for a signature.

* Note 2. I'm sure uEFI or other boot mechanism provide better way to deal with this.

As Brendan eloquently explained, GRUB / Multiboot has a f#$ked up design because they don't reliably inform you what disk was booted from.

Bluemoon has a really good solution to reliably determining the boot disk.
I guess Bluemoon uses Int 13/AH=48h - IBM/MS INT 13 Extensions - GET DRIVE PARAMETERS for getting the disk information.

Bah, that's so ridiculously convoluted.

I guess i'll have to use the BIOS commands at boot time by dropping to real mode...
But doesn't the BIOS disk geometry tell which bus the ATA drive is on?

requimrar wrote:But doesn't the BIOS disk geometry tell which bus the ATA drive is on?

Not all BIOS return such info, so you need to fall back to the above anyway.
Seriously, do you want to trust what BIOS return? I will not surprise if BIOS tell me its an ATA drive on ISA bus, while it is indeed USB stick with emulation.
The geometry, however, there is less thing to lie. (total number of sectors on drive and bytes per sector; and don't trust CHS info).