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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx26t6he....@jidanni.org
