On 08/05/2015 10:23 AM, Chris Murphy wrote:> Nothing about hd0 or hd1 gets baked into the bootloader code. It's an > absolute reference to a physical drive at the moment in time the > command is made.Is that true? If I have a system with two disks, where device.map labels one as hd0 and the other as hd1, and I swap those numbers, the resulting boot sector will differ by one bit. My understanding was that those IDs are used to map to the BIOS disk ID. Stage 2 will be read from the partition specified to the grub installer at installation, as in: grub> install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0,1)/grub/stage2 p (hd0,1)/grub/grub.conf Stage 1 and 1.5 will, as far as I know, always be on (hd0), but stage2 might not be. If the BIOS device IDs specified in device.map weren't written into the boot loader, how else would it know where to look for them?
On Thu, Aug 6, 2015 at 2:59 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote:> On 08/05/2015 10:23 AM, Chris Murphy wrote: >> >> Nothing about hd0 or hd1 gets baked into the bootloader code. It's an >> absolute reference to a physical drive at the moment in time the >> command is made. > > > Is that true? If I have a system with two disks, where device.map labels > one as hd0 and the other as hd1, and I swap those numbers, the resulting > boot sector will differ by one bit.Hrmm I can't reproduce this in a VM with identical drives. Are you sure stage 2 is in an identical location on both drives? That would account for a one bit (or more) of difference since GRUB's stage 1 contains an LBA to jump to, rather than depending on an MBR partition active bit (boot flag) to know where to go next.> My understanding was that those IDs are used to map to the BIOS disk ID. > Stage 2 will be read from the partition specified to the grub installer at > installation, as in: > grub> install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0,1)/grub/stage2 > p (hd0,1)/grub/grub.conf > > Stage 1 and 1.5 will, as far as I know, always be on (hd0), but stage2 might > not be. If the BIOS device IDs specified in device.map weren't written into > the boot loader, how else would it know where to look for them?stage 1 cannot point to another drive at all. It's sole purpose is to find stage 2, which must be on the same drive. Stage 1.5 is optional, and I've never seen it get used on Linux, mainly because in the time of GRUB legacy, I never encountered an installer that supported XFS for /boot. https://www.gnu.org/software/grub/manual/legacy/grub.html#Images -- Chris Murphy
On Thu, Aug 6, 2015 at 3:19 PM, Chris Murphy <lists at colorremedies.com> wrote:> On Thu, Aug 6, 2015 at 2:59 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote: >> On 08/05/2015 10:23 AM, Chris Murphy wrote: >>> >>> Nothing about hd0 or hd1 gets baked into the bootloader code. It's an >>> absolute reference to a physical drive at the moment in time the >>> command is made. >> >> >> Is that true? If I have a system with two disks, where device.map labels >> one as hd0 and the other as hd1, and I swap those numbers, the resulting >> boot sector will differ by one bit. > > Hrmm I can't reproduce this in a VM with identical drives.OK I did a CentOS 5 installation to raid1s, and it also boots either drive fine. But there's no log telling me how it installed the bootloader. http://ur1.ca/ndhf4 At offset 0x1B8 you'll notice 3 bytes of difference, but this is the disk signature. But what's interesting, this is not grub stage 1. This is a simple parted boot strap code that looks for the active bit in the MBR (the boot flag). When I do this: http://ur1.ca/ndhi3 There's the grub stage1. It's embedded in /boot (vda1) and (vdb1). When dd the 1st sector of vda1 and vdb1 to files, and diff the files, they're identical. So they're both pointing to the same LBA on each disk for stage 2. It really shouldn't matter though, whether this three step jump method is used, or grub stage 1 is written to each MBR gap and from there to stage 2. I might try nerfing the parted and grub stage 1 bootloaders on disk2, and see if the grub shell (which I should still get to from disk 1) will let me install grub directly on these two drives properly. -- Chris Murphy
On 08/06/2015 02:19 PM, Chris Murphy wrote:> stage 1 cannot point to another drive at all. It's sole purpose is to > find stage 2, which must be on the same drive. Stage 1.5 is optional, > and I've never seen it get used on Linux, mainly because in the time > of GRUB legacy, I never encountered an installer that supported XFS > for /boot.Grub's documentation is slightly unclear about that. Here's a system where /boot is part of a RAID1 set on /dev/vdc1 and /dev/vdd1: [root at localhost ~]# cat /boot/grub/device.map # this device map was generated by anaconda (hd0) /dev/vda (hd2) /dev/vdc (hd3) /dev/vdd [root at localhost ~]# grub Probing devices to guess BIOS drives. This may take a long time. GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> root (hd2,0) root (hd2,0) Filesystem type is ext2fs, partition type 0xfd grub> setup (hd0) setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 27 sectors are embedded. succeeded Running "install /grub/stage1 d (hd0) (hd0)1+27 p (hd2,0)/grub/stage2 /grub/grub.conf"... succeeded Done. grub> I believe the final line can be interpreted as: 0: install: the install command 1: /grub/stage1: path to the stage1 file, relative to the root 2: d: grub will look for stage2_file at the address specified in arg 4 3: (hd0): grub will be written to the first block of (hd0), currently mapped to /dev/vda 4: (hd0)1+27: stage1_5 has been embedded to this location. It is being used as "stage2_file" 5: p: the first block of stage2 will be modified with the value of the partition where stage2_file is found 6: (hd2,0)/grub/stage2: 7: /grub/grub.conf: because this arg is present and #4 is really a stage 1.5, the stage2 config file is patched with this configuration file name. If I specify "root (hd3,0)" in the grub shell, the boot loader will differ at 0002032, where it will refer to BIOS device 3 instead of BIOS device 2 for the location of /grub/stage2. --- vda.2 2015-08-06 16:05:32.039999919 -0700 +++ vda.3 2015-08-06 16:05:59.441999927 -0700 @@ -53,7 +53,7 @@ * 0001760 \0 \0 \0 \0 \0 \0 \0 \0 002 \0 \0 \0 032 \0 002 0002000 352 p " \0 \0 \0 003 002 377 377 377 \0 \0 \0 \0 \0 -0002020 002 \0 0 . 9 7 \0 377 377 \0 202 / g r u b +0002020 002 \0 0 . 9 7 \0 377 377 \0 203 / g r u b 0002040 / s t a g e 2 / g r u b / g r 0002060 u b . c o n f \0 \0 \0 \0 \0 \0 \0 \0 \0 0002100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 ...unless I'm mistaken. :)