Prev: ECC error correction/scrubbing on x86-64
Next: Facing Problem with USB Floppy Drive while using write protected floppy.
From: Robert Nichols on 27 Jan 2010 11:23
In article <dZJ7n.119763$gv3.31724(a)news.usenetserver.com>,
Andrew Gideon <c182driver1(a)gideon.org> wrote:
: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.

Indeed, for those systems the GRUB packages do not have any post-
installation scripts to run a GRUB installer, so in the absence of an
embedded stage 1.5 you cannot upgrade GRUB except in the context of a
major upgrade where anaconda would ask where to install the boot
loader, or by manually running the GRUB installer afterward.

If you do have an embedded stage 1.5 then all is well. The stage1_5
file appropriate to the file system gets installed in a fixed area**
outside the file system, and so is not overwritten by the upgrade.
Stage 1.5 understands that file system and finds the stage 2 file
that way.

** The MBR and logical drives within an extended partition typically
have the remainder of the track containing the main or extended
partition table available for this. The primary partitions do
not, and you'll see the "embed ... failed (this is not fatal)"
message when you try to install GRUB on those partition boot
sectors.

--
Bob Nichols AT comcast.net I am "RNichols42"
From: Andrew Gideon on 28 Jan 2010 10:27
On Wed, 27 Jan 2010 10:23:19 -0600, Robert Nichols wrote:

> Indeed, for those systems the GRUB packages do not have any post-
> installation scripts to run a GRUB installer, so in the absence of an
> embedded stage 1.5 you cannot upgrade GRUB except in the context of a
> major upgrade where anaconda would ask where to install the boot loader,
> or by manually running the GRUB installer afterward.

That's pretty annoying. I've touched on the subject of MBRs, Lilo/Grub,
etc. every so often over the years, esp. since many computers I touch
mirror the boot disk using mdadm. This most recent visit was due to a
failed Fedora 12 upgrade (just a "yum upgrade" on an already running
Fedora 12 machine). It rendered the system unbootable, where it simply
displayed the "GRUB" text indicating stage1.

A quick PXE boot to our rescue environment, and a grub setup(hd0) (to
both mirrors) and the problem was solved. But now I wonder what we have
in that machine's MBR. Will we always have to install to the MBR now,
now that there is no generic MBR that loads the next stage from the
beginning of the bootable partition?

I also wonder what exactly occurred to "break" the system. Grub stage1
in the MBR pointing to the wrong location for stage1.5 or stage2? Stage1
or stage1.5 in the bootable partition pointing to the wrong location for
stage2?

Either way, it is unpleasant to find that an upgrade can break booting.
I'd like to know the proper path to avoiding this for the future. Always
install grub on the MBR? Never install grub on the MBR? Something else?

>
> If you do have an embedded stage 1.5 then all is well. The stage1_5
> file appropriate to the file system gets installed in a fixed area**
> outside the file system, and so is not overwritten by the upgrade. Stage
> 1.5 understands that file system and finds the stage 2 file that way.

I understand - perhaps incorrectly *laugh* - that stage1 is written to
either the MBR or the beginning of the bootable partition. If the
latter, where is stage1.5 written?

>
> ** The MBR and logical drives within an extended partition typically
> have the remainder of the track containing the main or extended
> partition table available for this. The primary partitions do not,
> and you'll see the "embed ... failed (this is not fatal)" message
> when you try to install GRUB on those partition boot sectors.

I'm afraid that I don't understand that paragraph. Even from the
beginning: What is a "logical drive"?

I do understand partitioning, and extended partitions vs. primary. But
it seems to me that you're writing that one can only put a stage1.5 in an
extended partition, and that would surprise me since I actually tend to
not have extended partitions. I use LVM, so I typically have only two or
perhaps three partitions: /boot and the partition used as a physical
volume for LVM.

Thanks...
- Andrew

From: Robert Nichols on 28 Jan 2010 23:19
In article <l1i8n.27418$377.22127(a)news.usenetserver.com>,
Andrew Gideon <c182driver1(a)gideon.org> wrote:
:On Wed, 27 Jan 2010 10:23:19 -0600, Robert Nichols wrote:
[SNIP]
:> If you do have an embedded stage 1.5 then all is well. The stage1_5
:> file appropriate to the file system gets installed in a fixed area**
:> outside the file system, and so is not overwritten by the upgrade. Stage
:> 1.5 understands that file system and finds the stage 2 file that way.
:
:I understand - perhaps incorrectly *laugh* - that stage1 is written to
:either the MBR or the beginning of the bootable partition. If the
:latter, where is stage1.5 written?
:
:>
:> ** The MBR and logical drives within an extended partition typically
:> have the remainder of the track containing the main or extended
:> partition table available for this. The primary partitions do not,
:> and you'll see the "embed ... failed (this is not fatal)" message
:> when you try to install GRUB on those partition boot sectors.
:
:I'm afraid that I don't understand that paragraph. Even from the
:beginning: What is a "logical drive"?
:
:I do understand partitioning, and extended partitions vs. primary. But
:it seems to me that you're writing that one can only put a stage1.5 in an
:extended partition, and that would surprise me since I actually tend to
:not have extended partitions. I use LVM, so I typically have only two or
:perhaps three partitions: /boot and the partition used as a physical
:volume for LVM.

The extended partition is a primary partition. Within it are one or
more logical partitions, AKA "logical drives." Each of those begins
with a partition table, just like the MBR on the physical drive. As is
the case with the MBR, the remainder of the track following the sector
with the partition table is commonly left free, and the start of data
for the filesystem (or whatever) is at the first sector of the next
track. The most common virtual geometry is 63 sectors per track, and
stage 1.5 fits easily in those remaining 62 sectors. (The largest stage
1.5 needs 19 sectors.) So, when you install stage 1 in the MBR or in
one of those partitions within the extended partition, there is room to
embed stage 1.5. If you install stage 1 in the boot sector of any of
the primary partitions, there is no space available, and the embedding
will fail. Without an embedded stage 1.5, the stage 1 boot loader will
contain sector addresses of files in /boot, and booting will likely fail
if those files are moved. ("Likely," because the old data blocks are
not necessarily overwritten when the files are moved. It is entirely
possible that the system would still boot, using the old data blocks,
only to fail some time later when an unrelated action caused those
blocks to be allocated to something else and overwritten.)

The above is true for the case without LVM. I have never used LVM, so I
don't know what goes on within its logical volumes. If your drive has
only primary partitions, I believe the only opportunity for embedding
stage 1.5 would be when stage 1 is installed in the MBR.

And BTW, if you turn off "DOS Compatibility Mode" when partitioning the
disk, then those 62 sectors are not left free and there is nowhere that
stage 1.5 can be embedded.

--
Bob Nichols AT comcast.net I am "RNichols42"
From: Andrew Gideon on 29 Jan 2010 14:11
On Thu, 28 Jan 2010 22:19:30 -0600, Robert Nichols wrote:

> So, when you install stage 1 in the MBR or in one of those partitions
> within the extended partition, there is room to embed stage 1.5. If you
> install stage 1 in the boot sector of any of the primary partitions,
> there is no space available, and the embedding will fail.

Since I am not using an extended partition, it appears that I can
conclude that I am not using a stage 1.5. Correct?

> Without an
> embedded stage 1.5, the stage 1 boot loader will contain sector
> addresses of files in /boot, and booting will likely fail if those files
> are moved.

Where "moved" means "moved on physical disk" (as opposed to the "mv"
command), right?

This is very likely what occurred during the "yum upgrade" which
triggered the problem. So it is appearing that an upgrade of grub can
leave a system unbootable if the stage1 isn't being updated...which can
occur if the upgrade assumes that the stage1 is either in the partition
or the MBR, and the assumption turns out to be wrong.

That's rather annoying, esp. since it wouldn't be that hard to store the
state in a file. It just seems so annoying and so easy to fix that I'm
having difficulty actually believing that it is true. I must be missing
something.

[...]

> The above is true for the case without LVM. I have never used LVM, so I
> don't know what goes on within its logical volumes. If your drive has
> only primary partitions, I believe the only opportunity for embedding
> stage 1.5 would be when stage 1 is installed in the MBR.

This lost me. Is there a place to embed a stage1.5 if only primary
partitions are in use?


> And BTW, if you turn off "DOS Compatibility Mode" when partitioning the
> disk, then those 62 sectors are not left free and there is nowhere that
> stage 1.5 can be embedded.

Is there a way to determine if "DOS Compatibility Mode" was used on a
given disk? I don't know whether Fedora's installer defaults to having
this set or not.

Thanks...

- Andrew


From: David W. Hodgins on 29 Jan 2010 15:24
On Fri, 29 Jan 2010 14:11:19 -0500, Andrew Gideon <c182driver1(a)gideon.org> wrote:

> triggered the problem. So it is appearing that an upgrade of grub can
> leave a system unbootable if the stage1 isn't being updated...which can

On my mandriva system, "rpm -q --scripts grub" shows the postinstall
scriptlet that gets executed when a grub update is installed.

The script determines where(if) grub is installed, and then updates
it (if found to be installed), generating an error message if grub
has been installed into more than one place.

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.)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ECC error correction/scrubbing on x86-64
Next: Facing Problem with USB Floppy Drive while using write protected floppy.