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 Thu, Aug 6, 2015 at 5:04 PM, Chris Murphy <lists at colorremedies.com> wrote:> 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.OK I did that and this works. ## At the GRUB boot menu, hit c to get to a shell grub> root (hd0,0) grub> setup (hd0) grub> setup (hd1) That's it. What I did to test is was I zero'd the first 440 bytes of vdb and the the first 512 bytes of vdb1. I confirmed that this disk alone does not boot at all. After running the above commands, either drive boots. NOW, I get to say I've seen stage 1.5 get used because when it did the setup, it said it was embedding /grub/e2fs_stage1_5. In the above case hd0,0 is first disk first partition which is /boot. Anyway, this seems about 8 million times easier than linux grub-install CLI. Now I get to look back at OP's first email and see if he did this exact same thing already, and whether we've come full circle. -- Chris Murphy
On Thu, Aug 6, 2015 at 5:19 PM, Chris Murphy <lists at colorremedies.com> wrote:> Now I get to look back at OP's first email and see > if he did this exact same thing already, and whether we've come full > circle.Shit. He did. All I can think of is that either the GRUB/BIOS device designations are wrong (they should be (hd2) or (hd3) I can't actually tell how many drives are connected to this system when all of this is happening) so the bootloader is installing to a totally different drive. Or yeah, there is in fact some goofy incompatibility with an HBA where it gets to stage 1.5 and then implosion happens. *shrug* -- Chris Murphy