Summary: | /etc/init.d/udev should do do "udevadm trigger --action=change" if /dev is devtmpfs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xake <kanelxake> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | agk, cardoe, poncho, robbat2, slashbeast |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | A patch for udev's init script. |
Description
Xake
2011-04-28 16:53:42 UTC
+1, I can confirm it. After boot I have full device nodes under /dev/mapper + the same 'nodes' under /dev/dm-X. I have to do udevadm trigger --action=change to change /dev/mapper/* to symlinks to /dev/dm-X. Created attachment 276311 [details, diff]
A patch for udev's init script.
*friendly bump* The attached patch doesn't check to see if /dev is DEVTMPFS or TMPFS; it just checks to see if /dev is a mount point. Is that the way we want this to work? William It is done intentionally. Udev init script check if /dev is mounted, if is, then it will not run own magic. devtmpfs is just fancy tmpfs with nodes managed by kernel, it can also be tmpfs in initramfs and nodes created by mdev, then this tmpfs is moved to realroot before running switch_root. As udev will not be the one who create nodes when /dev is already mounted, then we should run 'udevadm trigger --action=change' to make our /dev follow udev rules. As I already posted example, on devtmpfs I have both /dev/mapper/vg-rootfs and /dev/dm-0 as nodes, with gentoo's udev rules /dev/mapper/vg-rootfs suppose to be a symlink to /dev/dm-0 (for example). after running this udevadm trigger my devtmpfs-powered /dev become the vaild udev /dev. (At list this is how I understand the issue and solution ;p) Hi, I have not forgotten about this bug. I'm working on getting udev 172 into the tree. In looking at upstream's README, I have noticed the following exerpt: ------ cut here ------ - The udev daemon should be started to handle device events sent by the kernel. During bootup, the kernel can be asked to send events for all already existing devices so that they too can be configured by udev. This is usually done by: /sbin/udevadm trigger --type=subsystems /sbin/udevadm trigger --type=devices ------ cut here ------ If you compare that to the way we populate /dev, there is quite a difference, but I'm not sure why. That is what I'm attempting to figure out. How's it going? This bug is still marked as unconfirmed, I think we confirmed it. (In reply to comment #7) > How's it going? This bug is still marked as unconfirmed, I think we confirmed > it. I found out, from upstream, that we are not supposed to use --action=change in the init scripts. Also, I discovered that 10-dm.rules is not part of the udev package, so we need to find out which package it belongs to and see what those rules look like. 10-dm.rules is from LVM/dmsetup. (In reply to comment #9) > 10-dm.rules is from LVM/dmsetup. This appears to be an issue with the udev rules for lvm2, so I am adding the lvm2 maintainers to this bug. @zake @piotr: Can you please post the version of lvm2 you have installed? @lvm2 maintainers: Can you take a look at 10-dm.rules for lvm2 and make sure that the actions are set up so that --action=add works correctly for the coldplug sequence? Thanks, William sys-fs/lvm2-2.02.88 but I think this is not really lvm issue, I have readed my notes and looks like the problem is there for other nodes too, like /dev/pktcdvd is created as file, node, by mdev, and then when udev starts it does print error because it suppose to be a dir with a control node inside. I have written there that 'udevadm trigger --action=change' fix that. The thing is to 'udevlize' /dev on start, when udev pickup already created /dev. This thread on the udev mailing list discusses the issue [1]. In a nutshell, we should not use --action=change in the coldplug sequence. Also, I do not know which version of udev you are running. Thanks, William [1] http://www.spinics.net/lists/hotplug/msg05104.html sys-fs/udev-171-r2 I received more information on this bug from upstream [1]. Basically this seems to emphasize that we should be using --action=add, and the fs type makes no difference. [1] http://www.spinics.net/lists/hotplug/msg05135.html Hey @William any progress? I just had issues because of this bug. As /dev/mapper/* wasnt symlinks, it was nodes, with different permissions than /dev/dm-*, proper permissions are root:disk 660, but the devtmpfs-created /dev/mapper/* nodes are root:root 600. udevadm trigger --action=change (or just udevadm trigger) fix it. (In reply to comment #13) > sys-fs/udev-171-r2 Please verify with >=sys-fs/udev-197-r3 and >=sys-fs/udev-init-scripts-19-r1. Now udev is requiring devtmpfs for /dev so I suspect things have changed here. (In reply to comment #16) > Please verify with >=sys-fs/udev-197-r3 and > >=sys-fs/udev-init-scripts-19-r1. Now udev is requiring devtmpfs for /dev so > I suspect things have changed here. I don't see this issue anymore with above mentioned packages. The symlinks in /dev/mapper/* correctly point to /dev/dm-* Close, as per Comment #17. Xake, reopen if you still experience the problem. Thanks. |