Upgrading grub, MBR vs. first block in a partition
in [Linux Hardware]
|
Prev: ECC error correction/scrubbing on x86-64
Next: Facing Problem with USB Floppy Drive while using write protected floppy.
From: Andrew Gideon on 26 Jan 2010 15:16 As I understand it, grub stage1 needs to know where grub stage2 is. If there's a change, then stage1 needs to be rewritten. But stage1 might be in a disk's MBR, or a generic MBR might be invoking stage1 from the bootable partition's first block. Yes? If that's right, then how is it determined whether a new stage1 needs to be written to the MBR? Thanks... Andrew
From: Pascal Hambourg on 26 Jan 2010 15:42 Hello, Andrew Gideon a �crit : > As I understand it, grub stage1 needs to know where grub stage2 is. If > there's a change, then stage1 needs to be rewritten. Not always. In some cases the stage 1 loads an intermediate stage 1.5 which understands the filesystem containing the stage 2. Quote from GRUB documentation : " These are called Stage 1.5, because they serve as a bridge between `stage1' and `stage2', that is to say, Stage 1.5 is loaded by Stage 1 and Stage 1.5 loads Stage 2. The difference between `stage1' and `*_stage1_5' is that the former doesn't understand any filesystem while the latter understands one filesystem (e.g. `e2fs_stage1_5' understands ext2fs). So you can move the Stage 2 image to another location safely, even after GRUB has been installed. While Stage 2 cannot generally be embedded in a fixed area as the size is so large, Stage 1.5 can be installed into the area right after an MBR, or the boot loader area of a ReiserFS or a FFS." Unfortunately, a stage 1.5 cannot be installed in the boot area of all filesystems due to lack of space. > But stage1 might be in a disk's MBR, or a generic MBR might be invoking > stage1 from the bootable partition's first block. Yes? Correct. > If that's right, then how is it determined whether a new stage1 needs to > be written to the MBR? You know when the stage 2 is updated, I guess. There might also be a chance that the filesystem moves parts of the stage 2 in different sectors on its own, but I have never heard about such an event. However I read reports that GRUB 2 (which I don't use myself) warns about the installation of the stage 1 into a partition boot record being unreliable.
From: Andrew Gideon on 26 Jan 2010 16:41 On Tue, 26 Jan 2010 21:42:17 +0100, Pascal Hambourg wrote: > Not always. In some cases the stage 1 loads an intermediate stage 1.5 > which understands the filesystem containing the stage 2. That just restates my question somewhat. In the cases where a stage 1.5 is used, then the stage1 needs to be able to find it. An upgrade of grub may require an update of the stage1 information, so there must be a way for the software doing the update to determine whether the stage1 is in the MBR or not. If we install grub "by hand", then this is a matter of setup(hd0) vs. setup(hd0,0) (or whatever disk or partition is being used). But how does automation updating grub know to where setup was pointed when grub was last installed? That is, how does automation know whether to do setup (hd0) or setup(hd0,0) (or to provide some other set of parameters to setup)? [...] > You know when the stage 2 is updated, I guess. I think you're answering a slight different question than what I asked. It's not "when does the stage1 require updating" but "when the stage1 requires updating - whenever that is - how does the updating mechanism know whether or not to write a new stage1 into the MBR?" If the MBR contains a stage1 that is let go out of date, the result can be an unbootable system (it would just print "GRUB" and stop, I believe). If the MBR contains some other loader that is overwritten by a new stage1, then whatever that old loader was doing would be lost. So this mechanism would appear to need to know whether the MBR contains a stage1. How does it know? Thanks... - Andrew
From: David W. Hodgins on 26 Jan 2010 17:03 On Tue, 26 Jan 2010 16:41:14 -0500, Andrew Gideon <c182driver1(a)gideon.org> wrote: > setup(hd0,0) (or whatever disk or partition is being used). But how does > automation updating grub know to where setup was pointed when grub was > last installed? That is, how does automation know whether to do On my Mandriva system, the installation scripts generate ... $ cat /boot/grub/install.sh grub --device-map=/boot/grub/device.map --batch <<EOF root (hd0,13) setup --stage2=/boot/grub/stage2 (hd0,13) quit EOF In my case, /dev/sda14 contains the root filesystem and grub, while I use GAG as the mbr boot manager. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: Andrew Gideon on 26 Jan 2010 17:25
On Tue, 26 Jan 2010 17:03:59 -0500, David W. Hodgins wrote: > On my Mandriva system, the installation scripts generate ... $ cat > /boot/grub/install.sh > grub --device-map=/boot/grub/device.map --batch <<EOF root (hd0,13) > setup --stage2=/boot/grub/stage2 (hd0,13) quit EOF > > In my case, /dev/sda14 contains the root filesystem and grub, while I > use GAG as the mbr boot manager. Yes, if this were used by the "install a new version of grub" automation it would solve the problem. It has embedded w/in it the idea that stage1 is written to partition 13 of disk 0. But I don't see an equivalent in either Fedora 12 or CentOS 5 (64 bit versions). Yet I cannot see how a grub upgrade would work w/o the upgrading software knowing whether or not to modify the content of the MBR. Thanks... Andrew |