[Bug 62195] Re: edgy update-grub destroys kopt
Bug is still(!!) existing in Hardy. Today, I updated my machine from vanished Gutsy to Hardy and my menu.lst was fucked up again! -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
On Sun, Jan 18, 2009 at 03:10:06AM -, 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
On 18/10/2008, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Fri, Oct 17, 2008 at 11:11:20AM -, 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 -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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 PROTECTED]> Fri, 17 Oct 2008 15:46:40 -0700 ** Changed in: grub (Ubuntu Intrepid) Status: Confirmed => Fix Released -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
On Fri, Oct 17, 2008 at 11:11:20AM -, 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
** Changed in: grub (Ubuntu) Assignee: (unassigned) => Steve Langasek (vorlon) -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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 -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
> 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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
On Fri, Jun 06, 2008 at 07:17:16PM -, 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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). -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. ** Attachment added: "oneliner to end years of frustration" http://launchpadlibrarian.net/15089605/update-grub.nouuid.patch -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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? -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
On Sat, Apr 26, 2008 at 02:20:17PM -, 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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
>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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
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... -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
No, you're not supposed to assign other people to bugs. ** Changed in: grub (Ubuntu) Assignee: Steve Langasek (vorlon) => (unassigned) -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
+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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
Does it help to assign to a person? (And am I allowed to do so?) ** Changed in: grub (Ubuntu) Assignee: (unassigned) => Steve Langasek (vorlon) -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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? ** Attachment added: "patch.hardy" http://launchpadlibrarian.net/1303/patch.hardy -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. ** Attachment added: "patch.gutsy" http://launchpadlibrarian.net/13411558/patch.gutsy -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://bugs.launchpad.net/bugs/62195 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
Also found out about bug #6 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? -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. ** Attachment added: "era's lshw" http://librarian.launchpad.net/5943935/lshw -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
** Changed in: grub (Ubuntu) Status: Unconfirmed => Confirmed ** Changed in: grub (Ubuntu) Importance: Undecided => High -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
** Bug 54042 has been marked a duplicate of this bug -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 62195] Re: edgy update-grub destroys kopt
On ma, 2006-09-25 at 17:00 +, 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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62195] Re: edgy update-grub destroys kopt
** Description changed: Binary package hint: grub - update-grub in ubuntu has new and, for me, entirely - unwanted functionality which is broken, incorrect and + 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 + ## by the debian update-grub script + ## EXCEPT FOR THE DEFAULT OPTIONS BELOW ## ## Start Default Options ## - ## default kernel options - ## default kernel options for automagic boot options - ## If you want special options for specific kernels use kopt_x_y_z - ## where x.y.z is kernel version. Minor versions can be omitted. - ## e.g. kopt=root=/dev/hda1 ro - ## kopt_2_6_8=root=/dev/hdc1 ro - ## kopt_2_6_8_2_686=root=/dev/hdc2 ro - # kopt=root=UUID=05df6308-cc97-4b8f-a3db-d9f5665667b8 ro + ## 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 entirely unwanted 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 + 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) please revert update-grub to the way it has worked for - years. In the meantime I will pin it back to Dapper. + 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. -- edgy update-grub destroys kopt https://launchpad.net/bugs/62195 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
