On Mon, 11 Jun 2018 23:20:51 -0500 Bruce Dubbs <[email protected]> wrote:
> What issues with GPT and legacy boot? Grub needs some space for it's > code that is OS independent. A separate small partition makes sense. > Putting the boot code in firmware is what does not make sense. And you > still need a custom EFI partition even then. > > Talking about a second stage loader is really about grub legacy. The > current grub doesn't work like that. The old way of using a fat > partition table and loading code in sectors 2-32 was really a kludge. Well, according to: https://en.wikipedia.org/wiki/BIOS_boot_partition "When used, the BIOS boot partition contains the second stage of the boot loader program, such as the GRUB 2; the first stage is the code that is contained within the Master Boot Record (MBR). Use of this partition is not the only way BIOS-based boot can be performed while using GPT-partitioned hard drives; however, complex boot loaders such as GRUB 2 cannot fit entirely within the confines of the MBR's 398 to 446 bytes of space, thus they need an ancillary storage space. On MBR disks, such boot loaders typically use the sectors immediately following the MBR for this storage; that space is usually known as the "MBR gap". No equivalent unused space exists on GPT disks, and the BIOS boot partition is a way to officially allocate such space for use by the boot loader." So, with GPT disks under BIOS systems, there is no way to initially load a boot loader complex enough to be able to read a filesystem. Lilo worked by requesting the sector numbers that corresponded to its second stage (and in turn, it's second stage requested the sector numbers of the kernel image to boot). That is why lilo had to be rerun every time a kernel image file was moved. So, when grub is running on a BIOS system with a GPT disk, it works a bit like lilo, except the second stage loader is contained in its own partition (where it can't be touched by mv, rm and friends) and that second stage is smart enough to be able to read files on FAT and EXTx filesystems without relying on fixed sector numbers. In this way, there is no need to "rerun" grub if a kernel image file is relocated as is the case with lilo. BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo, etc., must ensure that the (second stage) boot loader as well as any kernel image files are located within the first 2 TB of the drive because the BIOS calls can't handle sector numbers beyond that. > I believe the slots the sata drives are plugged into have priorities. > I've never seen the disks reverse identification. that would really be > a bad race condition. If it was happening, we would certainly have > heard about it. I can't remember exactly how I was bitten by it, but it wasn't via USB. It might have been from the use of a removable rack or SD card to SATA adapter (as a "rescue" boot) that sometimes would have media in it and sometimes not. In any case, according to https://wiki.archlinux.org/index.php/persistent_block_device_naming "If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary." As I understand it, that is the policy of the kernel developers - a system might work in many cases, but it is not guaranteed and a future kernel update could break systems that rely on any fixed /dev/sd* naming. To me, this means that, until udev becomes active and we can control things as we wish, any /dev/sd* specifiers are to be considered worthless. I do not like that policy. Unless countermanded by a kernel option, on-motherboard controllers should be enumerated before those of any add-on card or USB device. Also, SATA slots for a given controller should be enumerated in a fixed order, and IMHO, a SATA/PATA/SCSI slot should be enumerated regardless of whether a drive has been plugged into it. I would go so far as to make it that an initial, say, half a dozen drive names would be reserved for each USB controller regardless of whether a USB mass storage device was actually present at boot. I would also not enumerate USB drives in the /dev/sdx sequence, they would get their own sequence /dev/usbdx, because those do not have known/fixed slots as SATA controllers do. In a more complex arrangement, controllers could be enumerated like the devices they carry - /dev/sdAb1 - controller A, drive b, partition 1 with motherboard controllers being enumerated first, and then those on PCI, etc., slots, in the order of the slots they are plugged into. In short, I would try hard to avoid changing existing device names, most especially for devices on controllers on the motherboard, if later something is merely added-to/plugged-into the system. Cheers, Mike -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
