lucid hangs on boot because of device ownership

How did you change the permissions, permanently? I can't find any udev rules specifying the permissions on my system.

Setting to confirmed because of comments in bug 527666.

I also come here from bug #527666.

    mountall 2.10 reported by dpkg, though mountall --version return 2.8

I have /usr and /home in lvm and fails to mount. I can't se no message about pressing SM. Waiting for some time and pressing S and typing ALT-F1 and I am able to log in as root. Then I do mount -a.

I attach my mountall.log

Michel,

As a workaround, you just have to perform "chgrp root /dev/mapper/device" to set the correct ownership.

I noticed that in Karmic, /dev/mapper/* are all owned by root.admin, while in Lucid they must belong to the root group in order to be mounted by mountall.
However, I don't understand why it is necessary to set the group to root (same as the owner user), since permissions are set to 660 for those files.

Regards

thamieu,

But that's not persistent across reboots, right? udev just recreates the device inodes, what I do not understand is why some of them are owned by root:root, and others by root:disk. Another curious thing is that /dev/sda1 etc are all owned by root:disk, and work perfectly! I'm currently away from the system in question, but one of the things where the problem might reside could be /etc/lvmtab or /etc/lvm/lvm.conf. The latter file seems to include the umask, for one, and maybe other permission-related stuff as well.

Regards.

I don't know what kind of device you have in /dev/mapper, but mine are logical volumes. Curiously, only the latest created (during install) belongs to the disk group. Chgrp does have a persistent effect accross reboots on it.

Indeed, /dev/sd* belong to root.disk too and are mounted during boot.

Please find enclosed my /etc/lvm/lvm.conf.
I haven't seen anything interesting in. Maybe someone else will ?

Regards

I have 4 files in /dev/mapper, all the lvm ones are root.disk:

crw-rw---- 1 root root 10, 59 2010-04-08 11:15 control
brw-rw---- 1 root disk 252, 1 2010-04-08 11:15 DADES-home
brw-rw---- 1 root disk 252, 0 2010-04-08 11:15 DADES-usr
brw-rw---- 1 root disk 252, 2 2010-04-08 11:15 DADES-var

This is not a fresh install, but an upgrade from karmic.

I did a chown root:root on my /dev/mapper/vg-opt, but it doesn't survive a reboot on my system. thamieu: I'm really curious why it works on your system, these device inodes should all be created dynamically by udev on boot, /dev resides in memory. To change permissions permanently, normally one would need to create udev rules, in /etc/udev/rules.d/...

Permission change does not persist across reboots for me either.

This morning, I turned on the computer and got the problem. "The disk drive for /backup is not ready yet or not present"

I can swear lvbackup was owned by the root group when I turned it off, and I assure you I've never done anything with udev.

I checked ownership : lvbackup was this time owned by the disk group and, surprise, lvroot (which holds the system root), was owned by the disk group too (but was mounted)!
I performed a chgrp on lvbackup, and type reboot in a terminal.

Same problem on boot, but this time lvroot is owned by the root group, as it was before.
I changed ownership again, but this time performed the reboot through the graphical interface.
And, guess what ? It booted fine and lvbackup was owned by root.root.

This is pretty freaky, isn't it ? My guess is the "reboot" process launched through the graphical interface actually holds some data in memory, while the reboot command in a terminal performs a clean reboot.

I performed a "shutdown" through the GUI, then pressed the power button. Boot failed.

Finally, I can say that ownership *is not* persistent across reboots, making this bug more annoying than I thought.