| Summary: | sys-fs/eudev - no more /dev/loop-control or /dev/mapper/control | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nico Rittner <nrittner> |
| Component: | [OLD] Core system | Assignee: | eudev team <eudev> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Nico Rittner
2015-07-19 12:06:40 UTC
(In reply to Nico Rittner from comment #0) > I miss /dev/loop-control and /dev/mapper/control. They are not created > anymore after upgrading from 1.10-r2 to 3.1.2. So loop.ko or dm_mod.ko are > not loaded at first use of losetup/dmsetup like before. workaround is > manually loading look.ko / dm_mod.ko before. no custom udev-rules in use. > both times the same losetup-version (util-linux) and the same kernel is in > use. > This is probably due to the modprobe to kmod switchover. That happened between eudev-2.1.1 and eudev-3.0. Can you test if 2.1.1 worked and 3.0 doesn't? If you don't have time to work on this, can you give me steps to reproduce (I get what you're saying, but the devil is in the details!) I have a hunch. Could you provide the output of the following commands? rc-update kmod static-nodes --format=tmpfiles below it is. this guide https://wiki.gentoo.org/wiki/Udev/Upgrade_Guide#udev_204_to_208 refers to the missing dev-nodes, but the change i did is from 216 to 220 (according "udevd --version", seems to be the udev version eudev is based on). just found out that the output of "kmod static-nodes --format=tmpfiles" is written to /run/tmpfiles.d/kmod.conf in kmod-static-nodes but "nobody" seem to read/interprete this file, which contains all information to create the dev-nodes. Who should do so ? Thanks. root @ gw-a.edu / # rc-update binfmt | boot bootmisc | boot devfs | sysinit dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit local | default localmount | boot loopback | boot modules | boot mount-ro | shutdown mtab | boot netmount | default procfs | boot root | boot savecache | shutdown swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit urandom | boot root @ gw-a.edu ~ $ kmod static-nodes --format=tmpfiles d /dev/cpu 0755 - - - c! /dev/cpu/microcode 0600 - - - 10:184 c! /dev/fuse 0600 - - - 10:229 c! /dev/cuse 0600 - - - 10:203 c! /dev/loop-control 0600 - - - 10:237 d /dev/net 0755 - - - c! /dev/net/tun 0600 - - - 10:200 c! /dev/ppp 0600 - - - 108:0 d /dev/mapper 0755 - - - c! /dev/mapper/control 0600 - - - 10:236 c! /dev/vhost-net 0600 - - - 10:238 d /dev/snd 0755 - - - c! /dev/snd/timer 0600 - - - 116:33 d /dev/snd 0755 - - - c! /dev/snd/seq 0600 - - - 116:1 aah, /lib/rc/sh/tmpfiles.sh seems to do this job. at least it should. will survey. (In reply to Nico Rittner from comment #4) > aah, /lib/rc/sh/tmpfiles.sh seems to do this job. at least it should. will > survey. In openrc that should be taken care of in sysinit runlevel by tmpfiles.dev (which you have listed there). tmpfiles.setup might also help with this but I don't know the specific details of how this works anymore.. Could you provide the output of these commands? cat /run/tmpfiles.d/kmod.conf ls -l /usr/lib/tmpfiles.d ls -l /run/tmpfiles.d ls -l /etc/tmpfiles.d hi and sorry for delayed reply. here it is:
- cat /run/tmpfiles.d/kmod.conf:
(exists but is empty)
- /usr/lib/tmpfiles.d and /etc/tmpfiles.d do not exist
- /run/tmpfiles.d has kmod.conf (above)
since /lib/modules/${KERNEL_VERSION}/modules.devname
was also empty (only comment on 1st line) i decided
to go back to a previous kernel-build, and the
missing device nodes are back again now. i did the
change of the kernel (actual same cfg) the same day
as new eudev appeared in portage and suspected eudev
as cause.
will investigate what happened to my kernel-config.
since eudev seems not to be the cause here i think
we can close this issue. thanks for your support.
Upon reflection a kernel problem rather than an eudev problem. Thank you Nico. |
