edgy update-grub destroys kopt

Bug #62195 reported by Jim Bray
48
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Fix Released
High
Steve Langasek
Intrepid
Fix Released
High
Steve Langasek

Bug Description

Binary package hint: grub

update-grub in edgy has new and, for me, undesirable functionality which renders the system unbootable without skilled intervention.

1) update-grub should not mess with kopt at all, except
in the case of an initial install. From menu.list:

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script
## EXCEPT FOR THE DEFAULT OPTIONS BELOW

## ## Start Default Options ##
## default kernel options
Old kopt:
#kopt=root=/dev/hda6 etcetc
After update-grub:
#kopt=root=UUID=05df6308-cc97-4b8f-a3db-d9f5665667b8 ro

2) grub's unrequested trashing of my kopt, which I have set exactly as I want it, doesn't work. The fact that it is doing this without user input, either as a debconf setting
or from update-grub itself, is .... not so good...

3) while I might want to point my root at LABEL=ubuntu
or whatever, I don't know why I'd want to use UUID. Perhaps there is a good reason, but to me it is ugly and
essentially non-human-readable (I still like the Old Way of
human-readable config files). Apparently my kernels
don't much like UUID either; don't know how they feel about
LABEL yet.

Workaround: I'll pin it back to dapper.

Thanks.

Jim Bray (jb-cs)
description: updated
Revision history for this message
Dennis Kaarsemaker (dennis) wrote : Re: [Bug 62195] edgy update-grub destroys kopt

This behaviour is very intentional, /etc/fstab is also migrated to use
UUIDs by default. If it doesn't work for you, please tell us what fails
so it can be fixed.

Revision history for this message
Jim Bray (jb-cs) wrote :

 Thanks for your reply.

1) If I don't want to use UUIDs, but prefer labels or the time-honored way, do I need to drop Ubuntu in favor of Debian
or is there still a choice in the matter?

2) Kernel doesn't boot when update-grub has mangled my kopts.
"No Root", etcetc. Apparently can't find it.

3) Items such as kopt_2_6_18 were also blown away.

  I've been searching on UUID and so forth to try to find some convincing reason why I would want to use UUID instead of the other alternatives, but without much success. I assume this was discussed somewhere in an Ubuntu Wiki or something. Can you give me a pointer to the discussion so I can see the reasons for the apparently forced change to UUIDS, so I can see if it is something I want to do?

Thanks.

Revision history for this message
Dennis Kaarsemaker (dennis) wrote : Re: [Bug 62195] Re: edgy update-grub destroys kopt

On ma, 2006-09-25 at 17:00 +0000, Jim Bray wrote:

> 1) If I don't want to use UUIDs, but prefer labels or the time-honored
> way, do I need to drop Ubuntu in favor of Debian or is there still a
> choice in the matter?

You can change it back of course :)

> 2) Kernel doesn't boot when update-grub has mangled my kopts.
> "No Root", etcetc. Apparently can't find it.

That's why I didn't close the bug ;) You hit a bug in the conversion
routine.

> I've been searching on UUID and so forth to try to find some
> convincing reason why I would want to use UUID instead of the other
> alternatives, but without much success.

Using /dev entries is error-prone, booting with or without USB sticks
plugged in can reorder devices. Same goes for docking stations and even
race conditions in the loading of modules can reorder drives.
--
Dennis K.

Time is an illusion, lunchtime doubly so.

Revision history for this message
Erik Postma (e-j-postma+launchpad) wrote :

Hi, I was bitten by this as well. While I appreciate that the new default should be UUID-based, I think this should be taken care of in the hooks of the grub package. I think it's absolutely wrong that running update-grub (which typically occurs after installing a new kernel, as you all know) after having manually reset kopt to

#kopt=root=/dev/hda5

forces this back to

#kopt=root=UUID=some-hex-gibberish

This in effect means that there's no way to avoid having to manually re-edit menu.lst after each update-grub.

To be explicit: If I put

   # kopt=root=/dev/hda5 ro

in the right place in menu.lst, then run update-grub, I get

   # kopt=root=UUID=7138f191-499e-4b7e-8f68-c1019f785215 ro

in that same place back, and consequently

   kernel /vmlinuz-xyz root=UUID=7138f191-499e-4b7e-8f68-c1019f785215 ro quiet splash

in the boot stanzas. This is in contradiction to the man page of update-grub, which states that this is one of the two options that I should configure. So in particular, I think that the function convert_kopt_to_uuid in /sbin/update-grub should be ripped out and moved into somewhere in the hook scripts.

Revision history for this message
Jim Bray (jb-cs) wrote :

  Quite. Choosing the hex-gibberish option for initial
installations for new users is all well and good, but forcing the adoption of this for existing installations is another matter, a philosophy of Free Software incompatible with mine.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

The distribution/package upgrade should do the conversion, and not upgrade-grub. Really. If the conversion needs to be baked into upgrade-grub, it should only be invoked by a special option --convert-to-UUID for instance.

Revision history for this message
Michal Suchanek (hramrach) wrote :

For me UUID does not work either. It is probably because my kernel does not have an initrd, and cannot decode the gibberish by itself.

And no, the Ubuntu kernels are not good enough. If I want a new or updated module I have to compile my own (and only then I install a different kernel - otherwise it is a waste of time).

I could rebuild one of the outdated Ubuntu kernels but I still do not know how to make a kernel with an initrd. Without this kopt overwriting nonsense everything worked nicely for me.

Admittedly one should be able to boot from USB sticks and such if the UUID thingy worked so it is good option to have. However, It should not be forced when the option was not so originally, and was even manually changed back.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Michal, you can find some howto's on compiling ubuntu kernels on the wiki. You'll find that you don't have to compile the whole kernel if you just want to add/update some modules. initrd support is just a kernel compile option btw.

Revision history for this message
Robin Sheat (eythian) wrote :

I'm seeing this as a real problem too. I have a machine with root on /dev/sdb1 (Just a SATA disk with ext3, nothing fancy), and update-grub puts the UUID reference in kopts, however the kernel only seems to work with root=/dev/sdb1.

I'd consider this critical, as it renders the machine unbootable unless you know what you are doing and edit the command line as the machine is starting. There really needs to be an option to leave kopts unchanged.

Revision history for this message
butdie (butdiene-gmail) wrote :

I confirm this is a nasty "intentional" bug.

I understand the benefits of using UUID over /dev entries, but leaving a system unbootable after upgrade is way to much.

now, the user has to manually edit the grub entries to boot, and manually edit menu.lst, and forget about update-grub.

any bug leaves the system unbootable is critical to me.

Changed in grub:
status: Unconfirmed → Confirmed
importance: Undecided → High
Revision history for this message
era (era) wrote :

I just went through a relatively nightmarish dist-upgrade from Dapper to Edgy.

Unfortunately, I was unable to capture the exact message which scrolled by -- the significance of it was unclear to me at the time -- but during the dist-upgrade, there was a message to the effect that I had duplicate UUID:s on my system, and that using UUID would not be possible.

(I'm not familiar with the concept, so it's not very easy for me to actually troubleshoot this. Any hints are most welcome.)

However, my grub/menu.lst was nevertheless "upgraded" to use UUID:s. Attempting to boot the system resulted in around a minute of the bootup splash screen with the progress bar not moving at all, and then eventually a BusyBox initramfs shell and no particular hints about how to proceed from there.

Luckily, I was able to boot back into a working system by guessing that root=/dev/hda1 would be better than root=UUID=72616e646f6d-686578-67617262616765

hda1 is a PATA device and I also have a second SATA disk on sda1 ... I'm including the output from lshw just to be on the safe side.

Revision history for this message
era (era) wrote :

Also found out about bug #68888 while Googling around. For the record, my /etc/mdadm/mdadm.conf contains a single line, just "DEVICE partitions".

Er, ahem, tap tap tap, is this thing on, should I submit a separate bug report?

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Era, yes, your issue with "UUID would not be possible" and things still being converted to UUID should be filed in a separate bug report.

Revision history for this message
Michal Suchanek (hramrach) wrote :

Not necessarily. It is just just another condition that should be checked before the options are converted. The current script converts to UUIDs unconditionally afaict.

So far there are

 - duplicate UUIDs
 - kernels without initrd

The script should also warn when there is UUID already and one of the conditions occurs.

It could also create something like /boot/grub/menu.lst.converted, and not attempt the conversion again once this file is present. That way if people manually fix what the script broke it will not break it again.

Revision history for this message
yabbadabbadont (yabbadabbadont) wrote :

For those who wish update-grub to never convert the kopt line to use UUID, just edit update-grub and in the convert_kopt_to_uuid function, comment out the lines where "convert=:". There really should be an option to turn this behavior on or off.

Revision history for this message
Robin Sheat (eythian) wrote :

yabbadabbadont, problem is that is likely only to last until a grub update comes through which replaces it, runs update-grub, and makes the machine unbootable again.

Revision history for this message
John Jason Jordan (johnxj) wrote :

I've just been bitten by this yet again. I have been struggling with this for a long time:

http://ubuntuforums.org/showthread.php?t=457135

This time the kernel upgrade changed everything to a UUID that was listed in #kopt, ignoring the setting in #groot. I have the Grub manual and other documentation, but I can't figure out what the priority between the two lines is. In this case the UUID in #kopt was bogus, so rebooting after the kernel upgrade dumped me to an intramfs prompt. I also don't understand how the bogus UUID got into the #kopt line in the first place. And I can't find any documentation on how to write something in the #kopt line that will tell the update script where the root partition is, or tell it to ignore #kopt.

I have to add my voice here -- I don't care how "logical" the existing code is and I don't care about philosophical issues. Leaving the user's computer unbootable is simply not acceptable. I participate in a local Linux user group. We hold Linux Clinics where we help people transition from "that other operating system" to Linux. Mostly we help new users install Linux on their computers, and we always push Ubuntu as our first suggestion. We hand out dozens of Ubuntu CDs every month. I hate it when something like this happens to one of our new users. This "bug" has been around for too long.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

John, #kopt and #groot are two different things:
- The #kopt=root= setting is used by the initrd (after the kernel has booted) and should be a UUID to avoid trouble with device renaming. This is the "root partition" in Linux terms, but not the "root" in grub terms.
- The #groot is used by grub to find the partition where the kernel and initrd are hiding (often called the "boot partition" in Linux terms), and it has to use grub notation like (hd0,2). This is used by grub for its "root" command.

Revision history for this message
Pascal de Bruijn (pmjdebruijn) wrote :

This forceful behaviour is very nasty when your not using an initrd.

On my server I compile my own kernel, which I package with make-kpkg. Without an initrd the UUIDs don't work properly, and the system fails to boot.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Pascal, you're better off using an initrd, otherwise you're really on your own. Use the Ubuntu kernel source packages and build from them, or use the --initrd option of make-kpkg.

Revision history for this message
Walter Tautz (wtautz) wrote :

I have no problem making UUID the default I suppose but the # kopt line is suppose to be edited by humans
and should not be overwritten (at least this is what the comments in the file suggest).

It is interesting to note that if one has the line like:

# kopt=root=UUID=d401f1eb-681d-41f8-bf63-62d8da629044 ro

and changes it by hand to to

# kopt=root=UUID=abcd ro

That is, I make something up, then update-grub will assume the entry DOES NOT need to be updated.

At the very least, make update-grub update the entry EVERYTIME.

Unless I put in the old name, i.e.,

# kopt=root=/dev/sda6 ro

then it gets overwritten with the UUID stuff.

It is interesting to note that this behaviour is likely due to:

As noted above, the # kopt entry should be edited only by humans and its value should be used in the
various kernel sections below......

Try it and you will see I am correct.

Revision history for this message
Richard Wall (richardw) wrote :

I have just found the same problem in Gutsy. I have a cut down, compact flash installation of Gutsy, which I am duplicating using dd. I wanted to use root=/dev/hda1 rather than UUID because I was worried that UUID might not be same on each duplicated machine. I couldn't use /dev/sda1 because the via82cxxx IDE chipset still seems to represent block devices as hda1 etc.

I've just realised though, that UUID isn't related to the device, but to the formatted file system so it can be used in dd duplicated machines.

I still agree though, with above posters; update-grub shouldn't interfere with the human editable kopt lines in menu.lst.

Revision history for this message
David Masover (ninja-slaphack) wrote :

Oh, and let's not forget -- menu.lst now lies. It provides a number of options, with instructions on how to use them -- which are then messed with by update-grub.

And update-grub, by the way, contains a hardcoded switch statement -- looks like /dev/md[0-9] is now supported. Great. I run a partitioned raid, which means the raid device is /dev/md_d0, and the actual partition is /dev/md_d0p2. I can now look forward to an upgrade, every now and then, requiring manual intervention to keep my system bootable.

Attaching a patch for gutsy.

Here's the essential problem: Even assuming the uuid stuff works flawlessly, every time (which would be nice), and even assuming nobody ever wants to manually set a device name, there are certain devices which apparently aren't detected by uuid. Rather than having a list of device names known to work by uuid, the update-grub script instead assumes that anything it doesn't recognized as incompatible with uuid is, in fact, compatible. That's just reckless.

Unfortunately, I don't know enough about how things are looked up by uuid to know exactly which devices are supported, and which aren't, or how update-grub should know that. And I do think that at the very least, a manual disable should be allowed.

Revision history for this message
David Masover (ninja-slaphack) wrote :

Also: I agree that /dev/foo is error-prone, for auto-generated /dev/sd* corresponding to physical devices. However, my /boot is by UUID just fine, and the RAID device is also assembled by UUID. By the time we get to RAID, LVM, or simple custom device-mapper stuff, it's already pretty much a user-defined device name, hardcoded in a config file.

Revision history for this message
David Masover (ninja-slaphack) wrote :

Still exists in Hardy, a year and a half after first reported. Just spent the past hour or two figuring out that this was (yet again!) the issue, and then re-hacking update-grub (as my version had, of course, been nuked by the system update)

Is anyone paying attention? Where should I send my patch, if not this bug report?

Revision history for this message
David Masover (ninja-slaphack) wrote :

Does it help to assign to a person? (And am I allowed to do so?)

Changed in grub:
assignee: nobody → vorlon
Revision history for this message
martyg (snowbird) wrote :

+1

I wasted 2 hours this week tracking this same problem down.

You would think since Importance == HIGH this issue would have been dealt with long ago.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

No, you're not supposed to assign other people to bugs.

Changed in grub:
assignee: vorlon → nobody
Revision history for this message
Walter Tautz (wtautz) wrote :

martyg wrote:
> +1
>
> I wasted 2 hours this week tracking this same problem down.
>
> You would think since Importance == HIGH this issue would have been
> dealt with long ago.
>
>
Yes, it's annoying but it does point out the need to always
check bug trackers first *before* wasting one's time, sigh...

Revision history for this message
Steve Langasek (vorlon) wrote :

It may be that the correct solution for intrepid, now that we're past the point where we need to support upgrades from pre-UUID versions of Ubuntu, is to simply drop the migration code in update-grub since it really shouldn't be needed for hardy->intrepid upgrades. I think it's going to be easier to prove the correctness of such a change than to try to patch the existing code to selectively mangle kopt - though of course that won't solve this issue for users of hardy.

I understand the case for non-UUID-based root if you're not using an initramfs. Can someone explain to me why UUIDs are a problem in practice for RAID configurations, though? Is this a question of the UUID being incorrectly interpreted as belonging to the physical volume instead of the RAID group? If so, I think that's a much more serious bug in the UUID detection which needs to be corrected there, regardless of any changes to update-grub.

Revision history for this message
David Masover (ninja-slaphack) wrote :

From what I could tell, the UUID was simply never tracked down. I didn't investigate too much -- net user-visible result is, the machine hangs in the initramfs for several minutes before it finally concludes that it couldn't find anything to mount the root filesystem with.

It could be that the UUID code doesn't know to track RAID at all, and only looks at devices that were available at kernel boot time, before the initramfs?

What I can tell you is that they're just about completely redundant for RAID configurations, among other things. If I already have an mdadm.conf which I'm using to build the cluster -- or a crypttab which I'm using to build the md-crypt device -- or even some md kernel autodetection, based on UUIDs and metadata stored in the physical volumes...

In all of these cases, the actual device I am mounting is going to be the same, every time, as it is hardcoded *somewhere* -- the underlying physical volumes may or may not have been setup by UUID. If they have, then why do UUID stuff twice? If they're setup by /dev/sd*, then there's not much point in using UUIDs higher up the chain.

As for assigning someone else to the bug, at the very least, it was an email that I found in the source file in question. Still, if I wasn't supposed to do that, I apologize.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Sat, Apr 26, 2008 at 02:20:17PM -0000, David Masover wrote:
> It could be that the UUID code doesn't know to track RAID at all, and
> only looks at devices that were available at kernel boot time, before
> the initramfs?

No, that's not the case, a large number of devices are only available once
the initramfs starts.

> What I can tell you is that they're just about completely redundant for
> RAID configurations, among other things. If I already have an mdadm.conf
> which I'm using to build the cluster -- or a crypttab which I'm using to
> build the md-crypt device -- or even some md kernel autodetection, based
> on UUIDs and metadata stored in the physical volumes...

> In all of these cases, the actual device I am mounting is going to be
> the same, every time, as it is hardcoded *somewhere* -- the underlying
> physical volumes may or may not have been setup by UUID. If they have,
> then why do UUID stuff twice? If they're setup by /dev/sd*, then there's
> not much point in using UUIDs higher up the chain.

md kernel autodetection isn't going to give you guaranteed ordering of the
raid devices; so you would still want a more reliable method of associating
the devices to mountpoints than a numerical index of the md device.

Revision history for this message
Gary (gary-geisbert) wrote :

This issue still exists in hardy and the solution of forcing users to adapt this behavior is short-sighted.

There are many situations where UUID doesn't work, and we need to have a "correct" way of disabling this behavior since commenting out some lines in update-grub will get overwritten as soon as a new update-grub is released. Rather than telling everyone that they're wrong for not using UUID, why not just add in some code that allows us to disable this behavior?

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Gary, if there's a situation where UUID doesn't work, it should be fixed properly. Please report it as a bug.

Meanwhile, I looked at David's patch and it looks sane, safe and clean. I guess there is just a resistance to do anything at all with the old grub-update, it's so ugly and messy and developers are only longing for people to migrate to grub2, for which these things can be done simpler and better.

Before I saw David's patch, I had my own patch (see attachment) which is just a one-liner, it allows people to set "NO_CONVERT_UUID=yes" in /etc/default/grub. If shorter would be better.

Anyway, looking at convert_kopt_to_uuid() I noticed something that at least looks wrong:
   if [ -L "$DEV" ] && readlink "$DEV" | grep -q "^/dev/mapper/"
Shouldn't that be "$root" instead of "$DEV"? $DEV is only set as a side-effect in another function, last used when finding the /boot partition. If this is intended, it is certainly cowboy programming. But I guess it will break and do the wrong thing if /boot is using /dev/mapper and / is not. Just an example of the mess.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Hmm... I guess that $DEV check is supposed to disable UUID conversion when $root (from $kopt) is a link to /dev/mapper/*. It will do the wrong thing in this case if /boot is not on /dev/mapper (which is most cases since the BIOS needs to read /boot).

Revision history for this message
Gary (gary-geisbert) wrote :

UUID doesn't work if you use ghost to image the disk and then restore it somewhere else.

This isn't a bug that can be "fixed" anywhere, since it's not really a bug.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Jun 06, 2008 at 07:17:16PM -0000, Gary wrote:
> UUID doesn't work if you use ghost to image the disk and then restore it
> somewhere else.

Isn't ghost a full-disk backup/restore solution? If it is, then UUIDs
should work correctly in such an environment.

On the flip side, ghost would also not work with device names in the event
that you tried to do a backup/restore between a system whose controller uses
libata and one whose controller does not. So it's not as if avoiding UUIDs
is a reliable solution either.

In any event, I do acknowledge
(https://bugs.launchpad.net/ubuntu/+source/grub/+bug/62195/comments/30) that
this is a completed transition, and it would be reasonable to drop the UUID
migration support now for intrepid for that reason.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Gary (gary-geisbert) wrote :

> Isn't ghost a full-disk backup/restore solution? If it is, then UUIDs
> should work correctly in such an environment.

No, they don't. Ghost can backup only used space, and then restore that by creating a new partition and filesystem (which will have a different UUID), and then writing the files to that filesystem.

> On the flip side, ghost would also not work with device names in the event
> that you tried to do a backup/restore between a system whose controller uses
> libata and one whose controller does not. So it's not as if avoiding UUIDs
> is a reliable solution either.

You're correct, but this isn't a bug report on what would break ghost. This is a problem with update-grub.

Revision history for this message
David Masover (ninja-slaphack) wrote :

Thomas, not every instance of UUIDs not being recognized -- at least in the way we're discussing here -- is a bug. Sometimes, it is difficult or impossible to recognize them. Sometimes, it makes no sense to recognize them anyway.

Look at the examples which the script already deliberately ignores. Crypto, for example -- you can create a mapping of /dev/mapper/some_name to an underlying UUID device. So, by the time you're trynig to mount that, you actually do want to open it by device name -- because that device name already corresponds to a real UUID device, so you already have all of the benefits of that.

RAID is another example, for pretty much the same reasons. /dev/md0, or /dev/md_d0p1, are names that the admin creates, which map (somehow) to underlying block devices.

The problem is, a simple regex/glob looking for known patterns is not enough. Some people compile custom kernels. Some people don't use initramfs. Some people might just be using a devicename you hadn't thought of. Either way, by the time someone's digging in menu.lst to disable the UUIDs, it seems reasonable to assume they know what they're doing.

So yes, sometimes UUIDs not being recognized are their own bug, but not always. No matter how perfect we get the UUID detection, there should always be a way to disable that.

Revision history for this message
pbaco (pbaco) wrote :

I've another configuration where this update-grub "undocumented feature" is a problem.

I'm using several (20) Hardy+LTSP servers with 2 (strictly) identical disks, mounted in amovible disk racks.

The second one is a "backup mirror" of the first one (using an initial dd copy). Every night, a rsync routine updates the second disk, and the system is rebooted. t's a kind of mirror backup, a compromise between RAID and regular backup. In case of first (boot) disk crash, users just need to swap disk racks and reboot to get a running system within a couple of minutes, which is the main goal of this approach (used in public schools).

The only solution to get this to work is to use device names (i.e /dev/sd?) in menu.lst, not UUIDs.
I can't use different UUIDS for the 2 disks: in that case, the 2 menu.lst files would be different. Rsync will overwrite any change, and reboot after a disk crash will not work.
I can't use identical UUIDS for the 2 disks: in that case, grub randomly boots from first or second disk...

So I need to get a menu.lst using disk device names instead of UUIDs. And update-grub (launched automatically at every kernel update) gently wipes out my kopt option...

I think it's definitely a bug: update-grub MUST keep the "kopt" option just like it reads it from menu.lst, and must not try to reset to another value (containing UUIDs).

Pierre

Steve Langasek (vorlon)
Changed in grub:
assignee: nobody → vorlon
Revision history for this message
David Panofsky (ubuntu-avantextreme) wrote :

This mandatory behavior of update-grub to convert kopt entries to UUIDs really needs to be reconsidered. I understand why from a user-friendliness or newbie point of view one might want this behavior, but there needs to be an option somewhere (even if it's somewhere esoteric) which allows a user to turn this behavior off.

I've been using Linux nearly exclusively since 1996, starting with Debian 1.2 (rex) and switching to Ubuntu more recently. Despite the struggle that I've sometimes had with Linux's lack of user-friendliness, the argument I've always been able to make is that it "does what I tell it to do, not what somebody in Redmond or Cupertino thinks it should do." The reason many people choose Linux is for flexibility and control over their computers.

I've had many experiences over the past 11 years when a developer/package-maintainer/distribution chooses a *default* behavior that I've disagreed with, but
this is one of the very few times when I've been *forced* to patch (re-patching anytime an upgrade occurs) my system, switch distributions, or fall in line with somebody else's idea of how I should use my computer.

Please give me the option of choosing whether update-grub should 'fix' my kopt line or leave it be.

Revision history for this message
Fred Cooke (fred-cooke) wrote :

This bug is only two weeks from it's two year anniversary. At the top it says "confirmed" and priority "high" and yet two full years later it is still the case in a fresh install of 804. You *almost* had a debian > ubuntu convert, but stuff like this combined with someone incapable of stringing a sentence together correctly writing scripts to do automounting of USB stuff :

"The following shows how to put sync and noatime on for devices smaller then 1Gb and off for device larger then that. Note that the sync option can wear out device faster then you'd like too."

/etc/hal/fdi/policy/preferences.fdi

and not having an easy to reach/find way to turn off that behaviour have just about driven me away within 24 hours.

My "I've used debian for ever" story isn't quite as good as that guy up above, but it's not far off and I agree that behaviour that forces users to do it "your way" is totally unacceptable. Furthermore, making it unnecessarily difficult for an experienced user to manualise things (eg runlevels and console count etc) in order to help the lazy and dumb is very far from OK.

Get it together guys...

Fred.

Revision history for this message
perpetualrabbit (perpetualrabbit) wrote :

I use a workstation as an image for a number of other workstations, and install and update those with rsync. So, if I upgrade the image and a new kernel is installed, update-grub is run. This means that the UUID in menu.lst will now be spread by rsync to all those other workstations, rendering them unbootable when they go down.

This means I must have simple device names in menu.lst, not UUIDs.

Please make update-grub NOT overwrite any # kopt=root=/dev/sda6 settings I have made.

Please, in general, do not try to overrule systemadministrators, as you will only make our life more difficult and in the end force people like me to install another distro like SuSE of Fedora over Ubuntu. Because that is what my boss will decide if I have to spend too much time on crap like this when I upgrade the images.

Remember that Ubuntu is not only used by Joe Linux @ home, but also by universities, schools and other institutions that need an imaging solution.

Thank you.

Revision history for this message
Michal Suchanek (hramrach) wrote :

Well, the fix to this problem is trivial. Actually there are many possible fixes.

a) make the script note that the conversion was already performed, and not re-convert

b) make a separate script for the conversion and run it on system install or system upgrade but not on package upgrade

c) make a dpkg(debconf) question about this that people using apt/aptitude directly would see and people using graphics would not

....

The non-trivial part about some bugs (both Joe @ home style and advanced user style) is to convince Ubuntu people that a fix is indeed needed.

Since you found such a bug and it gets in your way my only advice is:

Switch to some other distro!
Do it right now, don't hold you breath!!

The Ubuntu people are really stubborn, and if they decided to not fix something they won't.

Oh, and thanks to whoever posted the link for building a kernel package. Building a packaged kernel with autogenerated initramfs makes using UUIDs with custom kernels easy but that apparently does not fix everything.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Oct 17, 2008 at 11:11:20AM -0000, Michal Suchanek wrote:
> The Ubuntu people are really stubborn, and if they decided to not fix
> something they won't.

That's completely uncalled-for given that I've *twice* acknowledged in the
bug log that this is a bug that should be fixed. Please do not troll in bug
reports.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub - 0.97-29ubuntu43

---------------
grub (0.97-29ubuntu43) intrepid; urgency=low

  * Drop the convert_kopt_to_uuid handling: this is no longer needed because
    all systems (new installs and upgrades from 8.04) should now have UUID
    settings in menu.lst, and the code was never made to respect admin
    overrides so update-grub is unusable for anyone who needs to specify
    their root by device instead of by UUID. LP: #62195.

 -- Steve Langasek <email address hidden> Fri, 17 Oct 2008 15:46:40 -0700

Changed in grub:
status: Confirmed → Fix Released
Revision history for this message
perpetualrabbit (perpetualrabbit) wrote :

No worries, I was not trolling. I personally don't want to switch from ubuntu to anything else. It is true however that ubuntu sometimes does things that make sense for the home user, but not for large collections of workstations. This grub bug, or rather decision by ubuntu developers to overrule a user/administrator setting is an example of that. Ideally, I want to be able to set the default behaviour of update-grub in a /etc/defaults/update-grub file.

In my opinion, ubuntu is mainly aimed at either home computers (incl. laptops) and servers, but not large scale client installations. There are virtually no ubuntu-made tools for sysadmins to do tasks typical for such an environment. I need stuff like:
- configuring authentication for LDAP/Kerberos/Active Directory
- account administration (adding, removing, changing accounts, archiving data, quota settings, etc.)
- making a customized menu-system for all users, alacarte can only do it for single users
- imaging solution to install clients over network that is simple yet configurable
- per-user settings for thunderbird, alpine, firefox extensions, numerous other applications
- some kind of central store for images, like git or subversion, combined with a virtualization solution in order to build images and test before installing them on client machines.
- I would be willing to pay for a service by Ubuntu to build deb packages for unpackaged software like for instance `xv´. Every time I need to upgrade the client workstations, I also need to hunt for around 40 or so software packages, not present in the repositories. Ubuntu might be able to make some money to provide a packaging service for people like me.

Anyway, I was not trolling, actually I like to help Ubuntu.

Revision history for this message
Michal Suchanek (hramrach) wrote :

On 18/10/2008, Steve Langasek <email address hidden> wrote:
> On Fri, Oct 17, 2008 at 11:11:20AM -0000, Michal Suchanek wrote:
> > The Ubuntu people are really stubborn, and if they decided to not fix
> > something they won't.
>
>
> That's completely uncalled-for given that I've *twice* acknowledged in the
> bug log that this is a bug that should be fixed. Please do not troll in bug
> reports.

Sorry, i did not notice that one of the comments saying this should be
fixed was finally from an Ubuntu developer, more than a year after a
bug in boot loader caused solely by Ubuntu packaging was marked as
high priority. My attention span is apparently somewhat limited.

Thanks for committing a fix finally.

It took about 1.5 year which is somewhat long for what I imagine as
"high priority" but perhaps it will get into Intrepid final at least
which would be nice.

Still this is not really trolling as there is that evms bug with
similar impact that was only resolved by obsolescence of all Ubuntu
systems carrying it.

I guess it is somebody else who decides which bugs are
release-critical and should be fixed but that does not lessen the
number of use-critical-bug years present in Ubuntu.

Thanks

Revision history for this message
Tommy Williams (talen-quickblade) wrote :

I am here from a duplicate of this bug, and I see this issue as a huge deal.
my experience with this issue:

1) an upgrade of a production server at our co-location from dapper to hardy resulted in botched grub settings, I am still digging through backups to determine the contents of fstab prior to the upgrade. After the upgrade the fstab was pointed to the incorrect device (via uuid) this resulted in an unbootable system and a 60 mile round trip drive out to our co-location to rescue the machine. dist upgrades should not touch my fstab, I like it just how it is. Neither should my operating system determine what is best for me, there is other software I can pay for to do that. I have grub configured just how I want it, please just move my current options to the new grub menu item.

2) This evening I added two hard drives to my home server. In the process of doing this, the UUID entries in both the grub menu and the fstab created problems with the new hard drives (duplicate entries). So, since /dev/ locations change so often that they are no longer reliable, I too feel that UUIDs are non-reliable either. In the ubuntu server distributions use of UUIDs should be disabled, and legacy /dev/ support should be re-inserted. Use of /dev/ locations on my home server would have prevented the problems I experienced this evening. Addition and subtraction of USB and transient devices are not expected on server hardware.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Sun, Jan 18, 2009 at 03:10:06AM -0000, Tommy Williams wrote:
> In the ubuntu server distributions use of UUIDs should be disabled, and
> legacy /dev/ support should be re-inserted.

Definitely not. Servers are the systems *most* likely to be affected by
non-persistent device names in general (because they're the most likely to
have multiple disks on multiple interfaces); UUIDs are the most reliable
method of addressing filesystems in spite of their limitations, so this is
the correct way for Ubuntu to address them in /etc/fstab and menu.lst by
default.

> Use of /dev/ locations on my home server would have prevented the problems
> I experienced this evening.

UUID collisions between filesystems only happen if you clone a filesystem
using dd or the equivalent. Conversely, a UUID reference only becomes
invalid if you remove the disk or reformat the partition, at which point the
admin needs to know to update the references in the config files. I'm sorry
for any trouble the switch to UUIDs caused you, but there are workarounds
for each of these two problems, so not supporting those two cases really is
the lesser evil.

In any event, this particular bug has been resolved for Ubuntu 8.10 and
later so that update-grub will no longer insist on rewriting entries to use
UUIDs after you've configured them manually. I would still recommend that
you use UUIDs; even aside from the questions of unreliable device ordering,
there are no guarantees from Linux upstream that the device naming scheme
itself will remain the same in the future.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Hauke Zuehl (hzuehl) wrote :

Bug is still(!!) existing in Hardy.

Today, I updated my machine from vanished Gutsy to Hardy and my menu.lst was fucked up again!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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