/etc/default/grub cannot disable use of UUID

Bug #499483 reported by Eskild Jacobsen
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Expired
Undecided
Unassigned
Nominated for Karmic by Sergei Vorobyov

Bug Description

Binary package hint: grub-common

Although disabeling the use of UUID's should be possible from /etc/default/grub, it cannot work of obvious reasons. This might not seem very important, but it makes image-based deployments almost impossible if not fixed.

Even though /usr/sbin/grub-mkconfig is correct, it sources /usr/lib/grub/grub-mkconfig_lib which completly ignores the entry altogether.

Approximately line 170
######
if fs_uuid="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then
    echo "search --no-floppy --fs-uuid --set ${fs_uuid}"
  fi
######

could easily be replaced by something like the following lines, and the issue would be solved :-)

#######
  if [ ! "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] ;then
      if fs_uuid="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then
      echo "search --no-floppy --fs-uuid --set ${fs_uuid}"
      fi
  fi
#######

-Eskild

Revision history for this message
Eskild Jacobsen (eskild-jacobsen) wrote :
Revision history for this message
Ruben Romero (huayra) wrote :

this affects netbased installs

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Felix Zielcke (fzielcke) wrote : Re: [Bug 499483] [NEW] /etc/default/grub cannot disable use of UUID

Am Dienstag, den 22.12.2009, 14:36 +0000 schrieb Eskild Jacobsen:
> Public bug reported:
>
> Binary package hint: grub-common
>
> Although disabeling the use of UUID's should be possible from
> /etc/default/grub, it cannot work of obvious reasons. This might not
> seem very important, but it makes image-based deployments almost
> impossible if not fixed.
>
> Even though /usr/sbin/grub-mkconfig is correct, it sources
> /usr/lib/grub
> /grub-mkconfig_lib which completly ignores the entry altogether.
>

Note that it's called GRUB_DISABLE_LINUX_UUID and not GRUB_DISABLE_UUID.
We won't change that upstream.
We only made it for the Linux kernel root= parameter because in some
configurations root=UUID doestn't work and we can't reliable detect
that.
Our plans are to get totally rid of device.map and so the use of the old
GRUB Legacy style `set root=(hd,xy)' in grub.cfg and only rely on search
--fs-uuid.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Revision history for this message
Eskild Jacobsen (eskild-jacobsen) wrote :

Hello Felix

I think you might have read this bug report a bit fast... This is actually for the kernel root= parameter. What I'm trying to point out, is that in order to use grub2 without UUID on file systems, the proposed solution will work great. File system UUID is a sure way to get into trouble if one is using image-based deployment (fog, ghost...), because one usually will have a new UUID on each filesystem, but kernel root=UUID=... will point to an non existing fs. Without being able to disable this feature and use for instance root=/dev/sda2 as a root device as opposed to root=UUID=... in the grub configuration one will have issues. Of course, one could do this manually, but it will fail every time you get a new kernel, or update your grub configuration. One could of course argue that one shouldn't use image based installations, but i beg to differ, and would like to point out that an image based deployment system is much faster than an installation based deployments.

I really hope you will take these considerations into account, because this really is a serious issue for us, and probably many others.

-Eskild

P.S. sorry about not using diff -u when I made the patch...

Revision history for this message
Nixloz (nixloz) wrote :

On some systems removing the search statement altogether makes the boot process much slower.
Is it possible to use it with the conventional /dev/sXX references at all, or can it only search using uuid?

Revision history for this message
Felix Zielcke (fzielcke) wrote : Re: [Bug 499483] Re: /etc/default/grub cannot disable use of UUID

Am Sonntag, den 17.01.2010, 16:26 +0000 schrieb Leppie:
> On some systems removing the search statement altogether makes the boot process much slower.
> Is it possible to use it with the conventional /dev/sXX references at all, or can it only search using uuid?
>

GRUB can't know how the later booted kernel and udev names the /dev/
files for your disks.
It can only use UUIDs LABEL and a file on the filesystem which the
search command already supports.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Revision history for this message
Nixloz (nixloz) wrote :

>GRUB can't know how the later booted kernel and udev names the /dev/
>files for your disks.
>It can only use UUIDs LABEL and a file on the filesystem which the
>search command already supports.

then why does the search still use the --fs-uuid option even though
GRUB_DISABLE_LINUX_UUID is set to true and uncommented?
should the "set root=(hdX,Y)" command not take care of the location
for grub to look for its files?
in some cases the search seems to be looking for different UUID's
than those passed by the command (set in grub.cfg).

Revision history for this message
Felix Zielcke (fzielcke) wrote :

Am Montag, den 18.01.2010, 02:43 +0000 schrieb Leppie:
> >GRUB can't know how the later booted kernel and udev names the /dev/
> >files for your disks.
> >It can only use UUIDs LABEL and a file on the filesystem which the
> >search command already supports.
>
> then why does the search still use the --fs-uuid option even though
> GRUB_DISABLE_LINUX_UUID is set to true and uncommented?

Because it has LINUX in there and is not named just GRUB_DISABLE_UUID.
It's only for the linux root=UUID kernel parameter. Not for GRUB itself
for what search and set commands are.

> should the "set root=(hdX,Y)" command not take care of the location
> for grub to look for its files?

Hardcoded GRUB devices aren't reliable. You have to
change /boot/grub/device.map to match your BIOS boot order.
And as soon as you change your BIOS boot order or sometimes it's even
enough to just add another disk to your PC and you need to fix
device.map again.

> in some cases the search seems to be looking for different UUID's
> than those passed by the command (set in grub.cfg).

It uses (Well it should, else it's a bug) the UUID of the filesystem
which contains the file the command after search uses.
So if your /boot is a seperate partition search command uses the UUID
of /boot so GRUB can find the Linux kernel and then in the linux command
it uses for root=UUID= the UUID of your / filesystem.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Revision history for this message
Felix Zielcke (fzielcke) wrote :

Am Montag, den 11.01.2010, 09:47 +0000 schrieb Eskild Jacobsen:
> Hello Felix
>
> I think you might have read this bug report a bit fast... This is
> actually for the kernel root= parameter.

Well according to your bug submission you mean clearly the search
--fs-uuid --set command and not the Linux kernel root= parameter.
Then your submission is wrong and please fix it then.
As I said search command has nothing to do with the Linux root=
parameter.
/etc/grub.d/10_linux honours GRUB_DISABLE_LINUX_UUID.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Revision history for this message
Sergei Vorobyov (svorobyov) wrote :

I would also be in favor of adding this feature

DISABLE_GRUB_SEARCH_ALTOGETHER=true

(or whatever name you choose), as described and suggested in the very first message of this thread by Eskild.

Rationale: if your BIOS does not support large (>137GB ;) disks then Grub gets stuck unable to search for the UUID
and the system cannot boot. This happens regularly, after you upgrade the kernel. It's painful to comment it out or run an extra script deleting searchers from grub.cfg. Please add it along with the comment that one can use it for their own
risk.

Thanks,
Sergei

Revision history for this message
Colin Watson (cjwatson) wrote :

We really need to fix such bugs instead of working around them. Hardcoding device names is responsible for literally hundreds of other open bug reports, and the only way to fix this is to use a more dynamic approach throughout. Sergei, I hope there's a separate bug report filed for the problem you describe?

Revision history for this message
Nixloz (nixloz) wrote :

Colin, isn't this the cause of this bug? the issue found with the UUID is because of the bioses not being able to support booting off a device >137GB
the whole discussion was that if by disabling the UUID altogether by setting a variable in the grub defaults file this could be circumvented without having to continiously reapply the modifications.

Revision history for this message
Colin Watson (cjwatson) wrote :

But GRUB is not intrinsically limited to using the BIOS for this. If we got to the point of being able to use ata.mod across the board, or even just detected the problem and used ata.mod when necessary, it wouldn't matter what the BIOS supported.

Revision history for this message
Joshua (joshudson) wrote :

I've hit this before on a system where UUIDs were unstable but /dev/sdxy identities and bios identities weren't.

Annoying.

Revision history for this message
Colin Watson (cjwatson) wrote :

Blink. Why were your UUIDs unstable? They're meant to be set in
filesystem superblocks.

Revision history for this message
Joshua (joshudson) wrote :

Because I'm about 5 times more likely to replace the primary hard drive and copy all files over than add hard drives in a manner that changes the detection order.

Revision history for this message
Marcus Tomlinson (marcustomlinson) wrote :

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]

Changed in grub2 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.