Bug#580426: marked as done (check for effects of GRUB_DISABLE_LINUX_UUID=true)
Your message dated Thu, 6 May 2010 00:10:06 +0200
with message-id <20100505221006.GU19138@baikonur.stro.at>
and subject line Re: Bug#580426: check for effects of GRUB_DISABLE_LINUX_UUID=true
has caused the Debian Bug report #580426,
regarding check for effects of GRUB_DISABLE_LINUX_UUID=true
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
580426: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580426
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-base
Version: 2.6.33-1~experimental.4
Severity: wishlist
Hello. I notice the linux-base package snoops around to get a list of
changes the user needs to approve.
Well, there is one item it forgot to investigate:
If the user has
GRUB_DISABLE_LINUX_UUID=true in his grub configuration,
well, he will very likely get stuck in "waiting for the root filesystem"
and thus no be able to boot, at least with linux-image-2.6.33-2-686,
with more than a single partition.
Therefore your script should perhaps poke around /boot/grub/grub.cfg,
update the entries there, and warn the user not to probably use
GRUB_DISABLE_LINUX_UUID=true anymore.
P.S., I am very curious, if one day, for some reason, the user finds
himself locked out of the system due to not having the proper UUID at
boot, whereas in the past, he could edit the boot command line (e.g.,
by typing "e" in grub), and fill in some guesses like /dev/hda1,
/dev/hda2 etc. until he got the right one where the root filesystem
lives, but nowadays, with no alternative to the very long UUID strings,
there is no way he is going to guess it, so he won't be booting for a
very long while?
E.g., when I noticed the above problem, that I still was using
/dev/hda11 in /boot/grub/grub.cfg and what thus no longer to boot upon
upgrading to linux-image-2.6.33-2-686, than goodness I had an older
kernel that could still boot using "/dev/hda11" so I could get in and
rerun grub without GRUB_DISABLE_LINUX_UUID=true in order to make a
/boot/grub/grub.cfg that linux-image-2.6.33-2-686 could deal with.
So maybe this new UUID stuff should be fitted with an escape hatch,
where saying something like UUID=/dev/hda11 could perhaps be give the
user a tiny chance to be able to boot in case he somehow doesn't have
the full UUID at hand.
P.S., I took a look in /var/lib/dpkg/info/linux-base.postinst and all I
can say is that the bottom line is "are you sure there is UUIDs on each
relevant line in /boot/grub/grub.cfg".
Note that I use
grub-pc:
Installed: 1.96+20080724-16
Candidate: 1.98-1
but that shouldn't matter, as your script shouldn't need to know exactly
which version I use or why I hold back a little.
--- End Message ---
--- Begin Message ---
On Thu, May 06, 2010 at 04:54:05AM +0800, jidanni@jidanni.org wrote:
> Package: linux-base
> Version: 2.6.33-1~experimental.4
> Severity: wishlist
>
> Hello. I notice the linux-base package snoops around to get a list of
> changes the user needs to approve.
>
> Well, there is one item it forgot to investigate:
> If the user has
> GRUB_DISABLE_LINUX_UUID=true in his grub configuration,
such a configuration is not default and user fault.
not supported.
> well, he will very likely get stuck in "waiting for the root filesystem"
> and thus no be able to boot, at least with linux-image-2.6.33-2-686,
> with more than a single partition.
>
> Therefore your script should perhaps poke around /boot/grub/grub.cfg,
> update the entries there, and warn the user not to probably use
> GRUB_DISABLE_LINUX_UUID=true anymore.
>
> P.S., I am very curious, if one day, for some reason, the user finds
> himself locked out of the system due to not having the proper UUID at
> boot, whereas in the past, he could edit the boot command line (e.g.,
> by typing "e" in grub), and fill in some guesses like /dev/hda1,
> /dev/hda2 etc. until he got the right one where the root filesystem
> lives, but nowadays, with no alternative to the very long UUID strings,
> there is no way he is going to guess it, so he won't be booting for a
> very long while?
>
> E.g., when I noticed the above problem, that I still was using
> /dev/hda11 in /boot/grub/grub.cfg and what thus no longer to boot upon
> upgrading to linux-image-2.6.33-2-686, than goodness I had an older
> kernel that could still boot using "/dev/hda11" so I could get in and
> rerun grub without GRUB_DISABLE_LINUX_UUID=true in order to make a
> /boot/grub/grub.cfg that linux-image-2.6.33-2-686 could deal with.
>
> So maybe this new UUID stuff should be fitted with an escape hatch,
> where saying something like UUID=/dev/hda11 could perhaps be give the
> user a tiny chance to be able to boot in case he somehow doesn't have
> the full UUID at hand.
>
> P.S., I took a look in /var/lib/dpkg/info/linux-base.postinst and all I
> can say is that the bottom line is "are you sure there is UUIDs on each
> relevant line in /boot/grub/grub.cfg".
newer postinst warns more directly about the consequences of not using
UUID's.
closing thus.
--- End Message ---
Reply to: