Gene Heskett wrote: > On Saturday 22 December 2007, Mikkel L. Ellertson wrote: >> Unless you have 3 hard drives that the BIOS sees, this should still >> be 'root (hd1,0)'. This tells Grub to use the second BIOS drive, >> first partition. > > That's what I thought, but the 2nd bios drive is in fact a 350GB, > on ide cable 1, not 0, middle connector, so it would for ata style > access, be /dev/hdd, and there is no /boot partition on it, a gig > of swap & 20 GB of unused /var2, & the rest /dev/hdd3, is all for > amanda to use. Its labeled, so it can show up anywhere in the ide > chain and be found ok. There is a dvdwriter on /dev/hdc's ide1 end > cable position. The bios itself, does not see this added sata card, > a vmlinuz/initrd combo must be loaded from one of the bios visible > drives, which makes the sata drive visible. Booted to fc6/2.6.24-rc6, > a df looks like this: > Because the BIOS does not see the drive, there is no hd2 as far as Grub is concerned. The only way to fix that is a BIOS upgrade, or a SATA controller with its own BIOS. <--------------------[snip]------------> > > So we have drives sca, sdb, and sdc (the sata drive on a via raid card) > > But when booted by the above mechanism, using a fedora kernel to f8, > the drive order is scrambled, with the now sdc becoming sda, hda becoming > sdb and what was hdd is now sdc. > This is because of the order the drivers are loaded. The SATA drive is on the first "SCSI" controller, and the PATA drives are on the second "SCSI" controller. So the SATA controller is scanned forst for drives, and then the PATA controller. Drive letters are assigned in the order the drives are found. > > Humm that brings up another question, of what use is > /boot/grub/device.map file then? The 'grub-install --recheck' > re-wrote that file WITH the linux visible sata drive, like this: > (hd0) /dev/sda > (hd1) /dev/sdb > (hd2) /dev/sdc > > And with an fd0 entry as the first line I've since removed. > > If the bios can't see sdc, that last entry serves no usefull purpose > and the --recheck code needs fixed, its buggier than a 10 day old > deer carcass in August. > The problem is that --recheck is only the best guess that Grub can make from the information it has. Once the system has booted the OS, there is no good way to determine the BIOS order of the drives. This is why the warning about verifying that the drive map is correct. With just about everything handled as SCSI drives now, there will be some problems that will have to be worked out. Partition labels take care of a lot of it by making drive order irrelevant, but you will have to be even more careful using programs like fdisk and dd. Grub will have a harder time guessing BIOS drive order, because the system drive order is not tied to the BIOS order at all, and the BIOS options for booting from other hard drives besides the first one, and for booting from USB drives, results in the BIOS order changing as well. The drive you tell the BIOS to boot from becomes the first BIOS drive. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
