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
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
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
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
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
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
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
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,
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
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
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
** 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
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
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.
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
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
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
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
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
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
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
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
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
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,
+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
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
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...
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
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
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
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
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:
#
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
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
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
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
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
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
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
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
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
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
--
** 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
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
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
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
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
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
--
** 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
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)
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
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
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)
** 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
54 matches
Mail list logo
