[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub installation may get erroneous after a hardware reconfiguration

From: Arbiel (gmx)
Subject: Re: Grub installation may get erroneous after a hardware reconfiguration
Date: Tue, 19 Mar 2013 10:14:36 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3


Enclosed are two numbered files, generated on my own PC.
blkid.numbered, for displaying uuids
grub.cfg.numbered, generated when I installed a Ubuntu distribution on an external device dedicated to get the internal drive of another PC used at a place without Internet connection.

At the other place, grub stopped running when it got at line 62, because it did not find any 'hd1,msdos5' device, as device hd1 at installation time had got device hd0 at running time. So the only result of this line 62 is to have had grub fail.

You can see on line 12 of the blkid listing that line 64 would have properly set root. You can also see that without lines 62 and 129, I would have been able to start the configuration and then run grub-mkconfig to adapt grub.cfg at the new configuration.

So here is the reason why I asked for discontinuing the generation of those "set root=" instructions whose only result is to have grub fail.

As long as I am concerned, I am quite able to suppress those lines by myself. The only real issue is to consider whether or not other people may act as I do and install a system in a place on a given configuration and used it at another place in another configuration.

Le 19/03/2013 07:50, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :
Keep list CC'ed
On 18.03.2013 23:50, Arbiel (gmx) wrote:


Le 14/03/2013 18:59, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :
On 14.03.2013 16:26, Arbiel (gmx) wrote:


The grub installation procedure should make no assumption regarding the
eventual runtime configuration concerning device and file references.

1) grub.cfg file contains "set root=.." instructions which refer to
partitions which are present at installation time, but could be absent
at runtime. These instructions may cause grub to stop booting,
displaying a message "No such device", and are of no use as they are
followed by "seach --set=root ... " instructions which set root
according to the runtime configuration.

Please, remove these "set root=.." instructions.

As long as search has found the right device, the value of root is
overridden. If it didn't work the problem is somewhere else. The
usefulness of these lines is for bw-compatibility mainly.

The issue is not with the "search" instructions which, as you say,
overwrite the value set by the preceding "set root=(hd....)"
instructions. The issue is with these "set root=(hd,...) instructions
which can refer to an inexistant device,

Not a problem since no file is referenced without explicit drive between
these instructions

because the running
configuration is not what the installation configuration was. In that
case, grub displays a "No such device" message and stops the booting

If you see any such problem, it's caused by a bug somewhere else, not
the set root statement. You write a lot about how to fix an issue you
haven't even really shown to exist. Please provide a replication
instructions with VM and recent bzr checkout

2) grub now embeds a little file to properly set the root variable when
core.img and grub/grub.cfg do not reside on the same partition. Such a
file should also be embedded even when both core.img and grub/grub.cfg
reside on the same partition, as the reference to this partition may get
illegal at runtime. No one knows whether or not the destination drive
has been ported away to another configuration, where its address differs
from what it was at installation time.

Only the partition number is stored, not the drive. And partition number
doesn't change on disk move

Please always embed a file to properly set root, prefix and

A recent boot-repair report showed the embedding of a 2 line grub shell
file to properly set the root variable to a device refered to by its
UUID. However, the inclusion may have been the result of the use
gub-mkimage command inside the installation procedure. So, the issue may
be to be reported to Ubiquity, the software responsible for Ubuntu
distributions installation. So forget about my request.

UUIDs are used for cross-disk installation. Partition numbers on
single-disk ones. In any case neither changes after swapping disks

Bug-grub mailing list

Attachment: grub.cfg.numbered
Description: Text document

Attachment: blkid.numbered
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]