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