lucid hangs on boot because of device ownership

Bug #557909 reported by thamieu on 2010-04-08
52
This bug affects 9 people
Affects Status Importance Assigned to Milestone
devmapper (Ubuntu)
Undecided
Unassigned

Bug Description

I've got some logical volumes and one of them can't be mounted at boot, pausing the boot process.

Plymouth shows the following message, but waiting is useless:
"Continue to wait; or press S to skip mounting or M for manual recovery"

The lv which couldn't be mounted is the latest device created in /dev/mapper. It is owned by root.disk instead of root.root. Changing permissions to root.root allows the lv to be mounted at boot.

Regards,
thamieu

Michel (michel-crondor) wrote :

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

Alvin (alvind) wrote :

Setting to confirmed because of comments in bug 527666.

Changed in devmapper (Ubuntu):
status: New → Confirmed
frankie (frankie-etsetb) wrote :

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

Michel (michel-crondor) wrote :

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

frankie (frankie-etsetb) wrote :

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.

Michel (michel-crondor) wrote :

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/...

doclist (dclist) wrote :

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.

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

Other bug subscribers