I stumbled across this problem when modularizing the kernel. The boot messages contained # dmesg | grep bcache [ 2.921002] systemd-udevd[1356]: RUN{builtin}: 'kmod load bcache' unknown /lib64/udev/rules.d/69-bcache.rules:21 [ 2.966955] systemd-udevd[1356]: RUN{builtin}: 'kmod load bcache' unknown /lib64/udev/rules.d/69-bcache.rules:21 [ 3.037230] systemd-udevd[1416]: Process 'bcache-register /dev/sdc' failed with exit code 1. [ 3.411432] systemd-udevd[1413]: Process 'bcache-register /dev/sda' failed with exit code 1. and needless to say that bcache stopped working: # /etc/init.d/cryptomount.data start * Starting data - /dev/bcache0 Device /dev/bcache0 doesn't exist or access denied. (doesn't exist) I had a look at lib64/udev/rules.d/69-bcache.rules:21 and see there RUN{builtin}+="kmod load bcache" ok. What does it do when called manually? # kmod load bcache invalid command 'load' kmod - Manage kernel modules: list, load, unload, etc Usage: kmod [options] command [command_options] Options: -V, --version show version -h, --help show this help Commands: help Show help message list list currently loaded modules static-nodes outputs the static-node information installed with the currently running kernel kmod also handles gracefully if called from following symlinks: lsmod compat lsmod command rmmod compat rmmod command insmod compat insmod command modinfo compat modinfo command modprobe compat modprobe command depmod compat depmod command uh - Surely You're Joking, Mr. Feynman! I'm not sure which of the multiple wrongs here is to be corrected. The document level? The udevd config level? The kmod implementation? Reproducible: Always Steps to Reproduce: 1. have bcache kernel module 2. try to use /dev/bcache0 3. fail
You're overlooking the RUN{builtin} part. udevd doesn't actually call /bin/kmod; it uses its own implementation based on libkmod. Which package provides /lib/udev/rules.d/69-bcache.rules? I don't have it installed locally.
(notwithstanding the kmod help text misleadings) /lib/udev/rules.d/69-bcache.rules comes from sys-fs/bcache-tools tried to re-emerge, still getting [ 2.946425] systemd-udevd[1358]: RUN{builtin}: 'kmod load bcache' unknown /lib64/udev/rules.d/69-bcache.rules:21 ... [ 2.987366] systemd-udevd[1358]: RUN{builtin}: 'kmod load bcache' unknown /lib64/udev/rules.d/69-bcache.rules:21 [ 3.058248] systemd-udevd[1404]: Process 'bcache-register /dev/sdc' failed with exit code 1. ... [ 3.430748] systemd-udevd[1432]: Process 'bcache-register /dev/sda' failed with exit code 1. Now this is interesting: > udevd doesn't actually call /bin/kmod; > it uses its own implementation based on libkmod. The machine has libkmod # locate libkmod /lib64/libkmod.so.2 /lib64/libkmod.so.2.3.0 /usr/include/libkmod.h /usr/lib64/libkmod.so /usr/lib64/pkgconfig/libkmod.pc but these files belong to kmod-22, not to udev. The udev has kmod USE flag set Installed versions: 228^t(03:53:27 PM 01/27/2016)(kmod ....
If - after the unsuccessfull bootup - I manually issue the commands > modprobe bcache > /lib64/udev/bcache-register /dev/sdc > /lib64/udev/bcache-register /dev/sda /dev/bcache0 is known and I can start it up: > /etc/init.d/cryptomount.data start * Starting data - /dev/bcache0
Could youplease test 1.0.8_p20140220? I imported several patches from fedora as the original upstream seems to be inactive.
(In reply to Justin Lecher from comment #4) > Could youplease test 1.0.8_p20140220? I imported several patches from fedora > as the original upstream seems to be inactive. i'm not sure what the crc64 patch is supposed to achieve but as is it prevents probe-bcache from linking: cc -Wall `pkg-config --cflags uuid blkid` probe-bcache.c `pkg-config --libs uuid blkid` -o probe-bcache /tmp/.private/root/ccpQanvy.o: In function `crc64': probe-bcache.c:(.text+0x4d): undefined reference to `crc_table' collect2: error: ld returned 1 exit status
I synced and got this These are the packages that would be fetched, in order: Calculating dependencies / !!! Problem resolving dependencies for sys-fs/bcache-tools from @selected ... done! !!! The ebuild selected to satisfy "sys-fs/bcache-tools" has unmet requirements. - sys-fs/bcache-tools-1.0.8_p20140220::gentoo USE="" PYTHON_TARGETS="-python3_3 -python3_4 -python3_5" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( python_targets_python3_3 python_targets_python3_4 python_targets_python3_5 ) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) It's because I still ran Python 2.7 - I'll try with 3.4
(In reply to PaX Team from comment #5) > (In reply to Justin Lecher from comment #4) > > Could youplease test 1.0.8_p20140220? I imported several patches from fedora > > as the original upstream seems to be inactive. > > i'm not sure what the crc64 patch is supposed to achieve but as is it > prevents probe-bcache from linking: > > cc -Wall `pkg-config --cflags uuid blkid` probe-bcache.c `pkg-config > --libs uuid blkid` -o probe-bcache > /tmp/.private/root/ccpQanvy.o: In function `crc64': > probe-bcache.c:(.text+0x4d): undefined reference to `crc_table' > collect2: error: ld returned 1 exit status I've tested and can verify that it fails with GCC 4.9 (compiles with GCC 5.3). I've added a patch to the ebuild for it to compile with GCC 4.9.
I can also confirm that it compiles with gcc 5.3 and when python is set to 3.5 (would probably work with 3.4 python also) I just restarted the server in question and: works! Resolved as far as I'm concerned.
j(In reply to Justin Lecher from comment #4) > Could youplease test 1.0.8_p20140220? I imported several patches from fedora > as the original upstream seems to be inactive. I wanted to reply to this before the bug is closed. https://evilpiepirate.org/git/bcache-tools.git This does not look inactive. Quite the contrary - it seems.
(In reply to PetaMem R&D from comment #9) The master branch has been quiet for over a year; but the bcache-dev-wip branch seems quite active indeed. Get them to cut a release already!
(In reply to David Seifert from comment #7) > I've tested and can verify that it fails with GCC 4.9 (compiles with GCC > 5.3). I've added a patch to the ebuild for it to compile with GCC 4.9. i have gcc 4.9 and still fails: cc -Wall -std=gnu99 bcache-super-show.c bcache.o `pkg-config --libs uuid` -o bcache-super-show /tmp/.private/root/ccVQEdMU.o: In function `main': bcache-super-show.c:(.text+0x415): undefined reference to `crc64' i guess crc64 should be a 'static inline' function which works fine here. as a sidenote, CFLAGS seems to be ignored by this package...
(In reply to PaX Team from comment #11) > (In reply to David Seifert from comment #7) > > I've tested and can verify that it fails with GCC 4.9 (compiles with GCC > > 5.3). I've added a patch to the ebuild for it to compile with GCC 4.9. > > i have gcc 4.9 and still fails: > > cc -Wall -std=gnu99 bcache-super-show.c bcache.o `pkg-config --libs > uuid` -o bcache-super-show > /tmp/.private/root/ccVQEdMU.o: In function `main': > bcache-super-show.c:(.text+0x415): undefined reference to `crc64' > > i guess crc64 should be a 'static inline' function which works fine here. as > a sidenote, CFLAGS seems to be ignored by this package... Something is wrong on your side. For me and others CC and CFLAGS are respected.
Guys, please retry 1.0.8_p20140220-r1.
