longlegs said: Now, if you find some thing magical about hd instead of sd, sr, .... From the viewpoint of a new user, a drive is a drive is a drive and who cares whether it is ide, scsi, sata, pata, juju, cd, fd or whatever.
Floppy drives are 'fd', Hard drives are 'hd', optical devices are 'cd', seems pretty logical to me, I don't think there is a lot of confusion over that point.
Which only leaves confusion over the numbering, which could be dealt with by indicating to people that numbering starts at 0 at the time they are given the option to specify the location.
If you look in the disk manager in Windows the first hard disk is 0. If you look in the boot.ini file, the identification of the hard drives and partitions there is more cryptic resembling something more like the way the linux kernel identifies them. Grub doesn't care how the OS represents the drive, it just needs to be kept up to date about which drive should be represented by what number.
BTW is a 32char DID# any better that say a 4 charDID? (DriveID)
The UUID thing has it's advantages and disadvantages, but that's an OS thing, grub doesn't care that. I did see some references about being able to use a UUID with the find command, but I did not follow up to see how you would actually use that.
Not knowing whats behind that button, it's likely that a new user would not choose that button, would wind up with no bootloader. That seems like a default (what you get by NOT doing something) to me.
My expectation is a new user would accept the default, not click on the advanced button, and ends up with grub installed in the MBR of the first HD or if they do click on advanced and don't understand what they are looking at, they don't change anything and they end up with grub in the MBR of the first HD.
There are three things that come into play.
1. In what order does your motherboard recognize the drives?
2. In what order does the OS recognize the drives?
3. How are the drives mapped in the device.map file?
Say you have a SCSI HD an IDE HD and an IDE CD/DVD, the IDE stuff could be SATA or PATA, it doesn't really matter.
I don't think it's typical, but on some computers if you boot from the SCSI your SCSI HD will be seen as the first HD, if you boot from your IDE CD to install the OS then your IDE HD will be seen as the first HD. I don't know what drivers are available at boot time when you boot off of the Ubuntu CD, but if that doesn't include the SCSI drivers your IDE stuff will always be recognized at boot time and the SCSI won't be recognized until the boot process is far enough along for modules to start being loaded, so the IDE stuff will always be first.
If you change the boot order in the bios, that may also change the order in which the different types of drives are recognized.
The device.map is created based on the way things are recognized at the time of installation, if that is different than it is when you boot normally, you have some problems.
1. If you don't choose where to install grub it will most likely be installed to the MBR of the wrong drive.
2. If you do choose where to install grub, but don't verify that the drives show up in the order you expect, you might choose the wrong place to install grub.
3. If you verify that the drives show in a different order and made the necessary adjustment to get grub installed in the correct location, you have to make corrections after the fact. Either edit the device.map file (it's a text file) to remap the order of the drives based on what is in the grub boot entries or edit the grub boot entries based on the order the drives are actually detected in. Either way it's a PITA.
Theoretically if you bios lets you choose which hard drive should be first in the boot order, that should always be hd0, if I am reading things correctly. If you can only choose which type of drive should be booted first (SCSI, IDE, etc...) then there is the added potential for something to go wrong and with SCSI I believe there are extra variables in the way different motherboards may handle things.
Looks like there was some discussion (Link) about possibly retiring device.map with grub2, but it sounds to me like we are not there yet.
Later, Seeker