LVM/MD root filesystem not found by uuid

[hunger]

Hi there!

There is no need to convert LVM volumes to UUIDs: LVM finds its physical volumes on all disks and maps the logical volumes stored on them to well defined names. This is pretty similar to what libvolumeid does... but since LVM's logical volumes are named by the user it tends to have better names then those numbers used as UUIDs.

Note: the original reporter indicated the bug was in package 'libvolumeid0'; however, that package was not published in Baltix.

[hunger (hunger)]

Damn... this bug was supposed to go to ubuntu edgy. How do I change that?

[hunger (hunger)]

Not in baltix.

[Aurelien Naldi (aurelien.naldi)]

I have mixed feelings about this.

I was about to report a similar bug for grub as the move to UUID everywhere currently prevents my edgy system from booting (I can boot if I put back the old "root=/dev/mapper/...." argument in grub). I am marking this as also affecting grub, for the record.

On the other hand, I find UUID better than labels or lvm volume names as they are more likely to be uniq. A while ago I put a friend's hard drive in my computer to get its data back, we where both using LVM with identical volume names, which was a bit problematic (I don't remember the details though). UUIDS might help in this area, but pushing the user to choose non-clashing LVM names might be enough.

[Scott James Remnant (Canonical) (canonical-scott)]

By "no need", do you just mean that you feel it's not useful to do it -- or is there some bug caused by doing so?

What does an "LVM volume" device name look like?

[Aurelien Naldi (aurelien.naldi)]

I guess that the original reporter really did mean "not needed", but it my case, it causes a bug :)
I have just checked, it is still present after recreating my initramfs. The problem is that it can not find my LVM volume by UUID.
The strange thing is that /etc/fstab has also been modified to use UUID (making it much less nice to edit manually) and it did not cause any problem, though my /home partition is also a LVM one and it does _NOT_ appear in /dev/disk/by-uuid/ !!

My exact setup is LVM on software RAID 5. I am not very fluent with the initramfs process so I can not tell in which state it is when it drops me the busybox shell, but I could give you output of commands run from it if needed.

LVM "partitions" are under /dev/mapper/ and the user can choose their name. Mine are called: vg_$VG-lv_$HOST$PART
where $VG designs the volume group to which it belongs, $HOST is my hostname (to avoid clashes when adding disks from a similar installation from another host) and $PART is the role of this volume (home, root32 and root64 in my case).

[Dominik Kubla (dbkubla)]

Don't know about LVM, but it certainly does not work with mirrored disks using MD. The system is unable to boot because it can not find the UUID before the MD device has been started. So the system just hangs "waiting for root device..."

Silently converting the root device entry is VERY BAD! Even in a development branch: You simply can't know enough about the installation to do it reliably.

So simply ask the user if he wants to convert the entry and don't touch the rescue entry unless the user has confirmed that the change worked.

udev: 093-0ubuntu7
initramfs-tools: 0.69ubuntu6

Kind regards,
  Dominik

[hunger (hunger)]

I was not sure whether this broke boot-up or not since I converted grub and fstab back before rebooting:-)

I am pretty sure now that it does break boot up since the LVM driver do not get an entry in /dev/disks/by-id/ ...

[hunger (hunger)]

Oh, for the record: LVM uses the kernel device mapper. So it reports its partitions in /dev/mapper/*

mdadm is using the same kernel infrastructure AFAIK, so its partitions should show up in the same place.

[Dominik Kubla (dbkubla)]

$ ls -l /dev/mapper
ls: /dev/mapper: No such file or directory

Your making assumptions again... As I said in the earlier message: You simply can't know how a system looks like. So you'd better not change settings that might break it without the expressed consent of the system administrator.

Regards,
  Dominik

[hunger (hunger)]

I somewhat agree with your point...

BUT ubuntu is a defined base. It has its device mapper stuff in /dev/mapper (which does not exist if you do not use it!). So for a ubuntu install script it is safe to assume that partitions that start with /dev/mapper are device mapper based and not to be touched.

Of course you can map /dev/mapper to something different as system administrator, but then you are on your own and can not expect ubuntu to do a sensible thing.

I do think that changing something fundamental as /etc/fstab needs to give some warning to the system administrator... and indeed that was given (or I would not had the opportunity to fix this issue before rebooting;-).

[Paul Wagland (paul-kungfoocoder)]

Debian also had this problem and resolved it by not converting /dev/mapper:

http://packages.debian.org/changelogs/pool/main/g/grub/grub_0.97-13/changelog.html#versionversion0.97-4

[Mathieu Bérard (mathieu-berard)]

Initramfs scripts cannot mount my root on lvm volume since conversion to UUID.

I think that the /usr/share/initramfs-tools/scripts/local-top/lvm script
which is supposed to activate the root on lvm volume is unable to
work with a root partition specified as an UUID: it try to parse the
root partition variable using a '/dev/mapper/something' pattern.

I also think that it cannot be made to work as the vgchange tool need a volume group name which I don't see how it can be guessed from just the UUID of a not-yet activated logical volume belonging to this volume group.

It can be workarounded by modifying back /boot/grub/menu.lst but you also
have to manually tweak the update-grub script as it blindly want to convert it
back to an UUID on each invocation.

[hunger (hunger)]

For what it is worth: LVM volumes are never listed with their UUID under /dev/disk/by-id/, not even on a ubuntu system that is fully up and running!

So it is simply impossible to address a LVM volume in ubuntu by its UUID!

Maybe it would be a good idea to verify that the UUID of a volume is actually found under /dev/disk/by-id before updating grub? This would stop the grub-updater-script from doing something incredibly stupid:-)

[hunger (hunger)]

Oh, aurelian suggests that UUIDs are not required to be listed in /dev/disk/by-id/ to work... if that really is the case, then my last comment is obsolete:-)

If the UUID system is not based on the entries in /dev/disk/by-id/ then it would be terribly nice if somebody could take the time and explain how this magic is worked.

[David Rasch (rasch)]

Looking at the logic in the actual 'init' script in:

/usr/share/initramfs-tools/

I see a case for a root specifying a UUID
                UUID=*)
                        ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
                        ;;

This logic also caused my upgrade from Dapper to Edgy to fail because of my root on LVM. I had to change these back to /dev/mapper* addresses to achieve a boot. My LVM's also don't show up in /dev/disk/by-uuid

-David

[Matt Zimmerman (mdz)]

Not a grub bug, leaving open against udev for now

[Matt Zimmerman (mdz)]

Scott, have you looked into this further? If this indeed fails for all LVM and/or MD devices, it would be serious indeed

[Paul Wagland (paul-kungfoocoder)]

This could also be considered a problem with the initramfs, and not with udev.

The problem is actually with the /init file in the initramfs, it converts a UUID=* entry into a ROOT entry of "/dev/disk/by-uuid/${ROOT#UUID=}". This is needed, since the mount command included in the initramfs does not understand the -U (mount by UUID) option. This, combined with the fact that udev does not create /dev/disk/by-uuid/ entries for LVM partitions means that booting with an LVM root is not possible without modifying the grub boot entry.

This also explains why mount with the UID specified in the fstab works, as this uses the more advanced non-initramfs mount that does know how to deal with UUID=* entries.

Hope this helps towards a solution, since this is a really disastrous bug, that prevents LVM root systems from booting. Even worse, because of the new tendency to fix initrd images when initramfs-tools are "improved" it can even break a running system and make what used to work stop working.

[Benjamin_L (benjamin-lebsanft)]

I got the same problem here using two SATA disks without any RAID configuration. Had to revert the entries using the live cd all times the updater reverts to uuids.

[Matt Zimmerman (mdz)]

On Fri, Aug 18, 2006 at 06:21:25AM -0000, Benjamin_L wrote:
> I got the same problem here using two SATA disks without any RAID
> configuration. Had to revert the entries using the live cd all times the
> updater reverts to uuids.

If you are not using LVM or RAID, then you likely have a different bug.
Please file it separately with complete details.

--
 - mdz

[Benjamin_L (benjamin-lebsanft)]

I'm using lvm, otherwise I wouldn't have commented.

[Lukas Kolbe (lucky)]

Same problem here. root on LVM, boot hangs on "waiting for root filesystem". Also, my home is on LVM, which doesn't get mounted because the fstab was converted to UUIDs, and for my LVM Volumes, no entries in /dev/disk/by-uuid/ get created.

[Benjamin_L (benjamin-lebsanft)]

I think either usplash or newer kernels still convert lvm to uuid.

[Dominik Kubla (dbkubla)]

It's grub-update, which is part of grub. Any time a kernel package is installed/updated, this script is executed.

For this reason I disagree with the rejection of this bug report by the grub maintainer! A grub script is changing a working system configuration into a non-working. This is most definitely a bug of the grub package. Now the root cause of this bug might well be in some other package but unless this has been determined _AND_ fixed, please stop converting the boot options.

[Matt Zimmerman (mdz)]

grub (0.97-11ubuntu10) edgy; urgency=low

  * Don't transition LVM, evms and dev-mapper devices. (Ubuntu #54002)

 -- Scott James Remnant <email address hidden> Mon, 21 Aug 2006 09:48:55 +0200

[Matt Zimmerman (mdz)]

On Sun, Sep 10, 2006 at 04:42:34PM -0000, Dominik Kubla wrote:
> It's grub-update, which is part of grub. Any time a kernel package is
> installed/updated, this script is executed.
>
> For this reason I disagree with the rejection of this bug report by the
> grub maintainer! A grub script is changing a working system
> configuration into a non-working. This is most definitely a bug of the
> grub package. Now the root cause of this bug might well be in some other
> package but unless this has been determined _AND_ fixed, please stop
> converting the boot options.

Please read the history of this bug; you'll see that it was agreed at the
time that this was a udev issue, as this approach should work even with LVM,
EVMS and MD devices.

After further out-of-band discussion, we agreed not to transition LVM, EVMS
or MD devices at this time, and the corresponding changes have been
implemented.

--
 - mdz

[Benjamin_L (benjamin-lebsanft)]

Then there seems to be a problem with the fix as 2.6.17-7 reverted my lvm back to uuid.

[Matt Zimmerman (mdz)]

On Sun, Sep 10, 2006 at 05:51:06PM -0000, Benjamin_L wrote:
> Then there seems to be a problem with the fix as 2.6.17-7 reverted my
> lvm back to uuid.

The kernel doesn't change your fstab or grub configuration. The former is
done by udev, the latter by grub itself.

Most likely your system was converted by older versions of these packages.
The current versions no longer perform this conversion, and I doubt they
attempt to undo a previous conversion.

--
 - mdz

[Dominik Kubla (dbkubla)]

Matt,

I am not trying to be dense or malevolent. I am well aware that Edgy is a development release, etc. But I am also a computer professional who has to deal with incident reports on a daily basis, so I have a quite good understanging of the issues involved. In my opinion the handling of this bug report has not been adequate.

Just to demonstrate the facts:

# env COLUMNS=120 dpkg -l grub
[...]
ii grub 0.97-11ubuntu10 GRand Unified Bootloader

# egrep -nC1 "Update.*root device.*UUID" /sbin/update-grub
751-
752:# Update the root device to mount-by-UUID
753-kopt=$(convert_kopt_to_uuid "$kopt")

# grep -c UUID /boot/grub/menu.lst
0
# /sbin/update-grub
Searching for GRUB installation directory ... found: /boot/grub
Testing for an existing GRUB menu.list file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-2.6.17-7-generic
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

# grep -c UUID /boot/grub/menu.lst
3

So as you can see, even your "fixed" version silently corrupts the system.

Against the expressed intention of the system owner/administrator who changed the relevant configuration file.

Sorry, but this is simply not acceptable. Especially since upstream Debian can detect manual changes of a config file and will not change it.

[Matt Zimmerman (mdz)]

On Sun, Sep 10, 2006 at 06:26:50PM -0000, Dominik Kubla wrote:
> # egrep -nC1 "Update.*root device.*UUID" /sbin/update-grub
> 751-
> 752:# Update the root device to mount-by-UUID
> 753-kopt=$(convert_kopt_to_uuid "$kopt")

You're making assumptions about the behaviour of a 1000+-line program by
reading one comment.

If you read the convert_kopt_to_uuid function referenced above, you'll see
that it includes conditional code intended to exclude device-mapper (LVM)
and EVMS devices from the conversion.

If you have problems with the conversion, a constructive bug report with
details of your configuration would be appreciated.

Thanks,

--
 - mdz

[Dominik Kubla (dbkubla)]

Am Sunday 10 September 2006 21:02 schrieb Matt Zimmerman:
> On Sun, Sep 10, 2006 at 06:26:50PM -0000, Dominik Kubla wrote:
> > # egrep -nC1 "Update.*root device.*UUID" /sbin/update-grub
> > 751-
> > 752:# Update the root device to mount-by-UUID
> > 753-kopt=$(convert_kopt_to_uuid "$kopt")
>
> You're making assumptions about the behaviour of a 1000+-line program by
> reading one comment.

No, I am not making assumptions. You stated that grub-update will not convert
LVM/devmapper entries anymore to avoid corruption of the system boot process.
I demonstrated that the system boot process is still corrupted for the rather
simple case of root disks being mirrored with MD.

> If you read the convert_kopt_to_uuid function referenced above, you'll see
> that it includes conditional code intended to exclude device-mapper (LVM)
> and EVMS devices from the conversion.

I went through this file line by line and I can say I have a rather good
understanding what it attempts to do and what it does.

You are the one making assumptions here: about how a system is configured.
That is something you can not know reliably. So following the principle of
least impact you should not change anything without explicit consent by the
system administrator requesting the task.

> If you have problems with the conversion, a constructive bug report with
> details of your configuration would be appreciated.

My problem is that you convert the file at all. I do not want this setting to
be converted, even if mounting by UUID would be working.

But as I understand now, the problem is not a technical one, so i will simply
dpkg-divert /sbin/update-grub and disable the conversion stuff in my local
copy and be done with it.

Regards,
  Dominik
--
Be at war with your vices, at peace with your neighbours, and let every new
year find you a better man. (Benjamin Franklin, 1706-1790)

[Matt Zimmerman (mdz)]

On Sun, Sep 10, 2006 at 08:37:14PM -0000, Dominik Kubla wrote:
> Am Sunday 10 September 2006 21:02 schrieb Matt Zimmerman:
> > You're making assumptions about the behaviour of a 1000+-line program by
> > reading one comment.
>
> No, I am not making assumptions. You stated that grub-update will not convert
> LVM/devmapper entries anymore to avoid corruption of the system boot process.
> I demonstrated that the system boot process is still corrupted for the rather
> simple case of root disks being mirrored with MD.

No, you didn't. You grepped for a string in the update-grub script and
claimed that this was evidence that it "corrupted" the system. I can't
agree there.

This conversion is a necessary step in order to support future changes in
the kernel which will change the naming and order in which storage devices
are detected. This is not necessary for LVM or EVMS volumes.

However, as far as I am aware, md devices are assigned in sequential order
based on a device scan, which means that they are susceptible to breakage
due to these ordering changes, and should be mounted by uuid rather than by
explicit device path.

If that isn't working correctly for you, then please help us to debug the
problem.

> > If you read the convert_kopt_to_uuid function referenced above, you'll see
> > that it includes conditional code intended to exclude device-mapper (LVM)
> > and EVMS devices from the conversion.
>
> I went through this file line by line and I can say I have a rather good
> understanding what it attempts to do and what it does.
>
> You are the one making assumptions here: about how a system is configured.
> That is something you can not know reliably. So following the principle of
> least impact you should not change anything without explicit consent by the
> system administrator requesting the task.

In general, I would agree, but in this case, the conversion is necessary in
order to avoid breakage in the future.

You can read the background for this decision in
https://launchpad.net/distros/ubuntu/+spec/probe-for-root-filesystem and
https://launchpad.net/distros/ubuntu/+spec/libata-for-all-ata-disks

If you have specific criticism of the decision, then please address it to
the development mailing list at <email address hidden>, and limit
discussion in this bug report to the matter at hand.

> > If you have problems with the conversion, a constructive bug report with
> > details of your configuration would be appreciated.
>
> My problem is that you convert the file at all. I do not want this setting to
> be converted, even if mounting by UUID would be working.

I'm afraid this is unavoidable, as I've tried to explain above.

> But as I understand now, the problem is not a technical one, so i will
> simply dpkg-divert /sbin/update-grub and disable the conversion stuff in
> my local copy and be done with it.

This will not further the process of fixing the problem. I know of no
reason why UUID mounting of md devices should not work, so your assistance
in debugging the problem would be appreciated.

--
 - mdz

[Jonathan Hudson (jh+lpd)]

Just believe it. UUID for MD devices broke my edgy root=/dev/md0 test box *again* this weekend.

If I've set root=/dev/md0 in menu.lst, please, trust me and don't break my box again.

If I can further help debug this, please tell me how.

-jonathan

[Matt Zimmerman (mdz)]

Reopening udev task, as md detection doesn't seem to be sorted yet.

MD folks, please provide details.

[Dominik Kubla (dbkubla)]

Am Monday 11 September 2006 00:24 schrieb Matt Zimmerman:
> Reopening udev task, as md detection doesn't seem to be sorted yet.
>
> MD folks, please provide details.
>
> ** Changed in: udev (Ubuntu)
> Status: Fix Released => Confirmed

We have two issues at hand:

1. Mounting by UUID does not work for MD in initramfs. I am trying to track
this one down (but I think this is a waste of time because there will always
be rather common scenarios where mounting by UUID will never work. But this
should be discussed elsewhere). I'll have to rig a serial terminal to capture
the console output and create a custom initramfs which will drop to a shell
right before it attempts to mount the root device so that I can do some
debugging.

2. update-grub changes MD to mount by UUID even so it does not work at the
moment. This one is rather easy to fix:

--- update-grub.orig 2006-09-11 20:49:34.000000000 +0200
+++ update-grub 2006-09-11 20:51:48.000000000 +0200
@@ -692,6 +692,9 @@
                        ;;
                /dev/evms/*)
                        ;;
+ /dev/md*) # Don't convert MD for now since there is an
+ # unresolved bug preventing it from working.
+ ;;
                /dev/*)
                        if [ -L "$DEV" ] && readlink | grep -q "^/dev/mapper/"
                        then

This can be backed-out when mounting by UUID for MD works.

Regards,
  Dominik
--
Be at war with your vices, at peace with your neighbours, and let every new
year find you a better man. (Benjamin Franklin, 1706-1790)

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2006-09-11 at 18:58 +0000, Dominik Kubla wrote:

> Am Monday 11 September 2006 00:24 schrieb Matt Zimmerman:
> > Reopening udev task, as md detection doesn't seem to be sorted yet.
> >
> > MD folks, please provide details.
> >
> > ** Changed in: udev (Ubuntu)
> > Status: Fix Released => Confirmed
>
> We have two issues at hand:
>
> 1. Mounting by UUID does not work for MD in initramfs. I am trying to track
> this one down (but I think this is a waste of time because there will always
> be rather common scenarios where mounting by UUID will never work. But this
> should be discussed elsewhere). I'll have to rig a serial terminal to capture
> the console output and create a custom initramfs which will drop to a shell
> right before it attempts to mount the root device so that I can do some
> debugging.
>
break=mount on the kernel command-line.

> 2. update-grub changes MD to mount by UUID even so it does not work at the
> moment. This one is rather easy to fix:
>
I'd rather fix #1. and make mount-by-UUID work.

Scott
--
Scott James Remnant
<email address hidden>

[Dominik Kubla (dbkubla)]

Am Monday 11 September 2006 21:11 schrieb Scott James Remnant:

>
> break=mount on the kernel command-line.
>

Yup. Google already told me about that. Nice.

> > 2. update-grub changes MD to mount by UUID even so it does not work at
> > the moment. This one is rather easy to fix:
>
> I'd rather fix #1. and make mount-by-UUID work.

I doubt that this is possible for all valid configurations. I could name at
least six valid configurations/situations where it will not work out of the
box, will not work ever or will have side-effects so severe that it will lead
to an immediate ban of all Ubuntu installations by the authorities.

But for the problem at hand I think I may have found it. It looks like you
have a circular dependency in /scripts/local-top:

I did a boot with break=mount, then sourced scripts/functions and executed
run_scripts scripts/local-top. Then I checked /dev/disk. There were only
directories by-id and by-path, no by-uuid.

md depends on udev. So udev will be called first. But it will not create
by-UUID entries for RAID components. mdrun has not been executed at this time
so it will also not create by-uuid entries for the MD devices.

Then md starts the RAID devices but udev already ran so the device links will
never be created and the "mount root" step will wait forever for the device
files to appear.

So I think you will have top put /dev/md* on the exclusion list as well. And
that pretty much limits your new booting scheme to desktop systems without
fault-tolerance or recovery features. Given the fact that Ubuntu now also
targets the Enterprise desktop and server markets I'd have to say: Forget
mount by-uuid.

Regards,
  Dominik
--
Be at war with your vices, at peace with your neighbours, and let every new
year find you a better man. (Benjamin Franklin, 1706-1790)

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2006-09-11 at 20:10 +0000, Dominik Kubla wrote:

> I doubt that this is possible for all valid configurations. I could name at
> least six valid configurations/situations where it will not work out of the
> box, will not work ever or will have side-effects so severe that it will lead
> to an immediate ban of all Ubuntu installations by the authorities.
>
What are these valid configurations?

It would help somewhat if you would actually explain them, instead of
just asserting that there's a problem.

> But for the problem at hand I think I may have found it. It looks like you
> have a circular dependency in /scripts/local-top:
>
> I did a boot with break=mount, then sourced scripts/functions and executed
> run_scripts scripts/local-top. Then I checked /dev/disk. There were only
> directories by-id and by-path, no by-uuid.
>
Ok, so this implies that none of the block devices that existed at that
point had UUIDs.

> md depends on udev. So udev will be called first. But it will not create
> by-UUID entries for RAID components. mdrun has not been executed at this time
> so it will also not create by-uuid entries for the MD devices.
>
This makes sense.

> Then md starts the RAID devices but udev already ran so the device links will
> never be created and the "mount root" step will wait forever for the device
> files to appear.
>
udev is RUNNING, not has already ran. This implies that md is somehow
not causing the kernel to issue uevents for the block devices it's
creating?

That should be relatively simple to fix, I would guess.

Another option would be to integrate the various md components in such a
way that they're triggered by the kernel uevents for the underlying
block devices, thus the md portions are in place and the UUID symlinks
created.

Either or both of these things would be good things.

> So I think you will have top put /dev/md* on the exclusion list as well. And
> that pretty much limits your new booting scheme to desktop systems without
> fault-tolerance or recovery features. Given the fact that Ubuntu now also
> targets the Enterprise desktop and server markets I'd have to say: Forget
> mount by-uuid.
>
Which means that next release, no system with md/raid/etc. will boot or
be able to locate its root filesystem. I win on the doomsday war ;)
We're not switching to mount-by-UUID for no good reason, you know.

Scott
--
Scott James Remnant
<email address hidden>

[Dominik Kubla (dbkubla)]

Scott,

nobody does mount by UUID. Neither *BSD, Solaris, AIX, HP-UX, Tru64 does it. These Unix derivatives have pretty smart engineering teams around. That should tell you something...

As for the valid configurations:

Category A (Will probably never work):

1. loopback mounts (eg. crypto root) -> kills secure mobile devices
2. network mounts (eg. nfs root or raid with nbd) -> kills one half of thin client setups
3. layered mounts (eg. unionfs) -> kills the other half of thin client setups and one half of embedded devices
4. tmpfs root -> kills the other half of embedded devices

Category B (Probably resolveable but changes expected behaviour)

5. disaster recovery with replicated root file systems (eg. rsync): there the UUIDs of both filesystem have to be different, otherwise they wouldn't be unique -> kills quite common DR strategy and effectively kills the use in corporate server environments
6. bare metal recovery: restore tape backup to newly installed system will result in a unbootable setup because UUID no longer matches... -> a support nightmare, effectively kills the use in corporate desktop environments

Category C (Has severe side-effects)

7. systems with SAN/iSCSI storage: udev will scan all devices it sees to determine the UUID. this is likely to take a long time ((I know of hosts with several hundred SAN storage volumes assigned to them) and prone to disrupting the operation of other hosts (since Linux does not honor SCSI reservation)-> this kills the enterprise server setups.

[Matt Zimmerman (mdz)]

On Tue, Sep 12, 2006 at 07:09:39AM -0000, Dominik Kubla wrote:
> Scott,
>
> nobody does mount by UUID. Neither *BSD, Solaris, AIX, HP-UX, Tru64 does
> it. These Unix derivatives have pretty smart engineering teams around.
> That should tell you something...

Modern Linux is doing quite a lot of things that those systems have never
done. This isn't about following their lead. :-)

--
 - mdz

[Dominik Kubla (dbkubla)]

Matt,

it's true that Linux did and does a lot of things traditional Unices didn't and don't do. But that is neither here nor there and I shouldn't have mentioned this in the first place.

I raised my objections regarding mount by UUID and it's up to you guys to check their validity regarding Ubuntu's goals.

As for the problem at hand: I am willing to aid in resolving this issue, so if you want me to test something, let me know about it.

Regards,
  Dominik

[Scott James Remnant (Canonical) (canonical-scott)]

Fabio should be uploading a fixed mdrun initramfs script after Knot 3 freeze that at least works around the problem

[Dominik Kubla (dbkubla)]

Am Thursday 14 September 2006 16:26 schrieb Scott James Remnant:
> Fabio should be uploading a fixed mdrun initramfs script after Knot 3
> freeze that at least works around the problem
>
> ** Changed in: udev (Ubuntu)
> Sourcepackagename: udev => mdadm
> Assignee: Scott James Remnant => Fabio Massimo Di Nitto

Ok. I'll check it then and let you know.

Regards,
  Dominik
--
Be at war with your vices, at peace with your neighbours, and let every new
year find you a better man. (Benjamin Franklin, 1706-1790)

[Fabio Massimo Di Nitto (fabbione)]

The new mdadm has been uploaded but it will be approved only after knot-3 cd is out. It's a matter of a few hours and it is also a duplicate of 57607.

[Dominik Kubla (dbkubla)]

Am Thursday 14 September 2006 16:26 schrieb Scott James Remnant:
> Fabio should be uploading a fixed mdrun initramfs script after Knot 3
> freeze that at least works around the problem
>
> ** Changed in: udev (Ubuntu)
> Sourcepackagename: udev => mdadm
> Assignee: Scott James Remnant => Fabio Massimo Di Nitto

After todays update booting by UUID works for straight MD RAID1.

Good work!
  Dominik
--
Be at war with your vices, at peace with your neighbours, and let every new
year find you a better man. (Benjamin Franklin, 1706-1790)

[Benjamin_L (benjamin-lebsanft)]

Latest 2.6.17-8 kernel converted my lvm back to uuid, don't know why.