On 06/12/2018 12:43 AM, Michael Shell wrote:
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.
There are a lot of things that can go wrong when disk sector numbers are
embedded into the code like lilo does. I do not know anything about the
internals of elilo though.
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.
The code on the boot sector is very short (448 bytes as I recall). That
does have enough to find the grub partition and read from there. In
grub legacy the boot sector (sector 0) read exactly one sector (sector
1) and that loaded the other sectors up through sector 31. The sector 1
code was referred to stage 1 and the sectors 2-31 were stage 2.
Sometimes this mechanism interfered with other programs. Autocad, for
instance, wrote some data to the same area.
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 don't think you can say that for all BIOS firmware, but it is
certainly true for some. Personally, I always make the grub partition sda1.
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 see. I guess I've never had a system with multiple disk controllers.
My development system has six sata drives, but they are all plugged into
the motherboard so that is one controller. I think that multiple
controllers are rare outside of large organizations.
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.
USB is separate as is a CD/DVD device. At least it is in any BIOS that
I have worked with. Perhaps it is a problem if multiple USB drives are
plugged in at boot. I have not tried that.
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.
That comes down to HW design, don't you think?
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.
I would think that the MB would always be first. The issue would then
be between multiple plugin controllers.
-- Bruce
--
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
