On Thu, Aug 6, 2015 at 2:59 PM, Gordon Messmer <gordon.messmer@xxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
