When building a kernel with genkernel and --btrfs option enabled, when booted I get: btrfs-control: No such file or directory And a message about failing to enable btrfs array (or something like this, that can make a photo if neccesary). I think somehow btrfs setup is missing essential files? Thanks.
Important to mention that this did not happen in 4.0.10 version.
No, this means the btrfs kernel module isn't loaded. I don't have a BTRFS setup myself but I know from other genkernel users that they don't have any problems with latest genkernel and BTRFS. Please double check that kernel and initramfs matches. If you don't create both, kernel and initramfs, with genkernel, make sure you pass "--kernel-config=/path/to/used/kernel.config" to genkernel when generating initramfs. If your system is still not booting, enter genkernel rescue shell and create a "gksosreport" (you will see instructions once you enter rescue shell). Please attach this file with used kernel config to this bug.
I made a photo of the error to know exactly what it says, and it is: WARNING: failed to open /dev/btrfs-control, skipping device registration: 1 ERROR: there were 1 errors while registering devices Scanning for Btrfs filesystems I don't have a btrfs array, only a "normal" btrfs partition (with some subvolumes) and this is why my system boots regarding this error (I think it will not boot in case of arrays) Furthermore, there's no reason for the btrfs module not to be loaded, as it is included (ALLMODULES=yes) in genkernel.conf Will attach kernel's config and genkernel.conf config. Note again, that it did not happened in 4.0.10 version.
Created attachment 658630 [details] Kernel config
Created attachment 658632 [details] Genkernel config
Final note: As seen in config, /boot is not mounted when genkernel starts, and grub-mkconfig is run automatically by genkernel, so I don't think the image missmatches kernel image
You attached kernel config shows that you built btrfs a module. Now please do > If your system is still not booting, enter genkernel rescue shell and > create a "gksosreport" (you will see instructions once you enter > rescue shell). Please attach this file with used kernel config to > this bug. This will tell us if you booted the correct initramfs and other stuff. And please make sure you are using >=4.1.2-r2.
Sorry, but I must ask: How to enter shell if system boots correctly? I don't seem to find the correct parameter to grub for entering rescue shell instead of a normal boot.
Is boot successful? At the moment I expect that your system fails to boot... In case boot failed, you should get an error message from genkernel offering you to enter rescue shell. If boot is successful we need to use debug mode instead which will require physical access. Just add "debug" to kernel command-line in /etc/default/grub and re-generate /boot/grub/grub.cfg and reboot (or add it once manually in grub, i.e. select boot entry and hit "e" key). First debug shell will be spawned before udevd will be started. Type "exit" to skip this breakpoint. Wait until you reached "before setting up the root filesystem" breakpoint. When reached run "gksosreport" command. If boot will succeed you don't have to copy gksosreport.txt manually, it will be available in /run/initramfs after system has started. Just type "exit" to leave shell and proceed...
Created attachment 658662 [details] gksosreport output Added the asked gksosreport file
Thank you. I still don't understand: Aside the message regarding > WARNING: failed to open /dev/btrfs-control, skipping device registration: No such file or directory > ERROR: there were 1 errors while registering devices > Scanning for Btrfs filesystems do you experience any problems? And could you please do the same again, but this time, wait for the debug breakpoint before switch_root call (this is the last debug breakpoint) and create the report here? This will show us if system loaded btrfs module when handling root. At the moment it looks like we can skip dobtrfs stuff and get rid of https://github.com/gentoo/genkernel/blob/master/defaults/initrd.scripts#L1615-L1632 because udev will handle that for us...
You can also simulate the removal already: Just remove "dobtrfs" from kernel command-line and see if system is still able to boot.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=369cfa98f72675a285ec98439e9054ab57b234c9 commit 369cfa98f72675a285ec98439e9054ab57b234c9 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-09-11 20:01:37 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-09-11 20:03:24 +0000 Remove "dobtrfs" kernel command-line argument This is no longer necessary with the switch to UDEV. Bug: https://bugs.gentoo.org/739892 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> defaults/initrd.scripts | 32 -------------------------------- defaults/linuxrc | 6 ------ doc/genkernel.8.txt | 3 --- genkernel | 1 - 4 files changed, 42 deletions(-)
Hey, I run into this issue with a btrfs raid and 4.1.2-r3, it fail to mount the root with the UUID and then offer a rescue shell. If I search with btrfs fi show inside the shell I can see it, and this setup was working with previous genkernel version. Seeing this issue, I added the commit 369cfa98f72675a285ec98439e9054ab57b234c9, to genkernel-4.1.2-r3 and rebuilded, still same error (wihtout dobtrfs). I am willing to test / add more details to solve this. Thank you.
I've run into this same problem. I've found out that when the initramfs (which prints four "can't open btrfs-control" messages, since I have RAID 10) gives me the "can't find the root, give me one" prompt, I can simply do this: 1. Type 'shell'. 2. Type 'btrfs device scan' 3. Hit CTRL-D. Then the system will boot properly. I'll attach my gksosreport.txt.
Created attachment 662602 [details] Another gksosreport.txt
I removed `dobtrfs` from the my options in /etc/default/grub, reran `grub-mkconfig -o /boot/grub/grub.cfg`, and rebooted. On reboot, there were no "failed to open" messages, but the system still could not find the root filesystem. Entering the shell, running `btrfs device scan`, and hitting CTRL-D allowed boot to continue. TL;DR: Removing `dobtrfs` removes the warnigns but does not otherwise change boot behavior or the workaround.
I can confirm the workaround: - Without dobtrfs - In the shell btrfs device scan - C^d boot
Looking at the /init in the generated initramfs, the only mention of btrfs (aside from `dobtrfs` setting `USE_BTRFS`) is a call to `setup_btrfsctl`, with a comment about see bug 303529, which has this comment from ten years ago: >All the support for adding binaries in /sbin in already present in genkernel. >Its left as an exercise for the user to figure out how >to build btrfsctl and how to provide it to genkernel to get it inside of >initramfs. >The patch only does what genkernel needs to do minimally to detect BTRFS >volumes. There is no /sbin/btrfsctl in my initramfs. setup_btrfsctl is in /etc/initrd.scripts. It checks for btrfsctl, and if foiund, calls `btrfsctl -a` and `udevsettle`. If not found, it does nothing. There are only two other mentions of BTRFS in /etc/initrd.scripts: once in modules_scan, where if USE_BTRFS (or ZFS, or dmraid, or cryptsetup, or lvm) is set, then: # All of this will require the call of another program before # root becomes available so checking for root after each module # was loaded will only waste time. smart_loading=no The other is in start_volumes, where (if USE_BTRFS is set) it checks for `btrfs` (and issues a warning if not found), then calls `btrfs device scan`. The warnings we were seeing were from the code in modules_scan; apparently /dev/btrfs-control isn't created by udev at the point when `btrfs device scan` is called. Removing `dobtrfs` from the kernel command line disables this code, making the warnings go away. In either case, the Btrfs volumes are not found. setup_btrfsctl does nothing in either case because there's no btrfsctl. The patch listed above on 2020-09-11 removes all this code. There's still no point in the process where `btrfs device scan` is called *after* `/dev/btrfs-control` comes into existence (which apparently happens before we can drop into a shell, which is why the workaround works). Diffing the /init files from the old (working) initramfs and the new one, the only changes that look like they could have an effect is: -# Ensure that device nodes are properly configured -run mdev -s || bad_msg "mdev -s failed" +# Run debug shell if requested +rundebugshell "before starting udevd" + +# Initialize udev +if [ ! -f "/etc/udev/hwdb.bin" ] +then + good_msg 'Generating /etc/udev/hwdb.bin ...' + run udevadm hwdb --update \ + || bad_msg 'Failed to generate /etc/udev/hwdb.bin!' +fi + +good_msg 'Activating udev ...' + +udevd_cmd="run udevd --resolve-names=never" +if [ "${GK_UDEV_DEBUG}" = '1' ] +then + udevd_cmd="${udevd_cmd} --debug > ${GK_UDEV_LOG} 2>&1 &" +else + udevd_cmd="${udevd_cmd} --daemon" +fi +eval "${udevd_cmd}" +if [ $? -eq 0 ] +then + run udevadm trigger --action=add + udevsettle +else + bad_msg "udevd failed to run" +fi This is from before the `setup_btrfsctl` line. I'm not sure how `udev` is supposed to be smart enough to know to call `btrfs device scan`.
You are using BTRFS subvolumes... looks like we are missing an UDEV rule for that. Maybe you can create 80-btrfs.rules with the following content: > SUBSYSTEM!="block", GOTO="btrfs_end" > ACTION!="add|change", GOTO="btrfs_end" > ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end" > RUN+="/sbin/btrfs device scan $env{DEVNAME}" > LABEL="btrfs_end" You need to hack genkernel to add it. Easiest way would be adding it to /var/cache/genkernel/<your GK version>/eudev-*.tar.xz, i.e. extract, put file into usr/lib/udev/rules.d and re-pack. When you now re-create initramfs the rule should be included. Please double check with "lsinitd" from dracut package before rebooting...
Thomas, I tried adding that file to /etc/udev/rules.d and /usr/lib/udev/rules.d and neither worked. I confirmed the file was in the initramfs in both cases. The easiest way to add the file is to create a directory /root/initramfs-overlay/usr/lib/udev/rules.d, put the file in there, and add --initramfs-overlay=/root/initramfs-overlay to the genkernel command line.
Please add gk.udev.debug=true to kernel command-line and share /run/initramfs/udevd.log once you enter debug shell after hitting the error that root wasn't detected.
Created attachment 663658 [details] udevd.log from failed detection of Btrfs RAID10 root subvol
It looks like there's already a /usr/lib/udev/rules.d/64-btrfs.rules. It contains (removing comments): SUBSYSTEM!="block", GOTO="btrfs_end" ACTION=="remove", GOTO="btrfs_end" ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end" IMPORT{builtin}="btrfs ready $devmode" ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0" ENV{ID_BTRFS_READY}=="1", RUN+="/usr/bin/udevadm trigger -s block -p ID_BTRFS_READY=0" LABEL="btrfs_end" The real problem seems to be that the `btrfs device scan` calls in 80-btrrfs.rules, as well as the calls in 64-btrfs.rules, are happening before udev bothers to create the `/dev/btrfs-control` node. Since that's created by the time we drop to shell, it succeeds when I run it from the shell.
No luck looking at udev.log for two weeks? Or did this turn into another bug report? Looking at the udev log (`grep -i btrfs udev.log`), it starts off reading the rules files: Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules Reading rules file: /usr/lib/udev/rules.d/80-btrfs.rules Then it fires them off for the first Btrfs physical partition it finds (one of four in a RAID10): IMPORT builtin 'btrfs' /usr/lib/udev/rules.d/64-btrfs.rules:8 IMPORT builtin 'btrfs' returned non-zero RUN '/sbin/btrfs device scan $env{DEVNAME}' /usr/lib/udev/rules.d/80-btrfs.rules:4 starting '/sbin/btrfs device scan /dev/sdc2' '/sbin/btrfs device scan /dev/sdc2'(err) 'WARNING: failed to open /dev/btrfs-control, skipping device registration: No such file or directory' '/sbin/btrfs device scan /dev/sdc2'(out) 'Scanning for btrfs filesystems on '/dev/sdc2'' '/sbin/btrfs device scan /dev/sdc2' [877] exit with return code 1 Whoops, fails because there's no /dev/btrfs-control. Then it repeats this process for /dev/sda2, /dev/sdd2, and /dev/sdb2. Next it reads the rules files again: Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules Reading rules file: /usr/lib/udev/rules.d/80-btrfs.rules Then... I'm not sure what this is: no db file to read /run/udev/data/+module:btrfs: No such file or directory no db file to read /run/udev/data/+bdi:btrfs-1: No such file or directory Then it decides to create /dev/btrfs-control: handling device node '/dev/btrfs-control', devnum=c10:234, mode=0600, uid=0, gid=0 preserve permissions /dev/btrfs-control, 020600, uid=0, gid=0 creating symlink '/dev/char/10:234' to '../btrfs-control' created empty file '/run/udev/data/c10:234' for '/devices/virtual/misc/btrfs-control' Then another of these: no db file to read /run/udev/data/+bdi:btrfs-1: No such file or directory And that's it. Seems like it needs to create /dev/btrfs-control a lot sooner than it does. I can't tell where in /init these log outputs correspond to.
I've found a workaround in the meantime. Add this to the kernel command line: firstmods=btrfs This gets the `btrfs` module loaded early which gets `/dev/btrfs-control` created so `btrfs device scan` from the udev rules doesn't fail. For example, in `/etc/default/grub`, I have the line: GRUB_CMDLINE_LINUX="firstmods=btrfs" And `genkernel --bootloader=grub2` does the right thing.
So, how should I load OS with btrfs raid5 if dobtrfs option does not work. I have to run "btrfs device scan" and mount fs manually. p.s. genkernel-4.1.2-r3
Created attachment 684654 [details, diff] simple wa to create btrfs-control device
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=c4e6b09c79f33303f749b2b40af51a01f168971f commit c4e6b09c79f33303f749b2b40af51a01f168971f Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-02-15 04:34:57 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-02-15 05:51:47 +0000 linuxrc: load btrfs module manually There is no trigger/rule in UDEV/btrfs-progs to load btrfs module. The only known trigger via mount command could be too late or is maybe insufficient depending on used BTRFS {meta,}data profile. Bug: https://bugs.gentoo.org/739892 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> defaults/linuxrc | 8 ++++++++ 1 file changed, 8 insertions(+)
Hi, I created the following test system: > # lsblk --output NAME,KNAME,FSTYPE,PARTUUID,UUID > NAME KNAME FSTYPE PARTUUID UUID > sda sda > ├─sda1 sda1 vfat 69b1e90f-ad5a-4027-86e7-49055ec62227 6C77-49A2 > ├─sda2 sda2 ext4 2a083990-70e3-4dbe-aca3-f63f956ee24b 2535ad13-763f-4042-a6c8-5fe6c9f9671c > ├─sda3 sda3 swap 2279b24c-1033-48b5-9e59-629c5bbbdbee eab32d12-5d08-468f-8bd9-7c2efa9195ae > └─sda4 sda4 crypto_LUKS d71c01b5-7bc6-48e3-ae08-5727a5ddd03d ce7959ef-2d3c-4da8-8dac-fd75b0a700be > └─root dm-0 btrfs 4e47c0ba-f6ab-4b16-b915-3843a772b665 > > # mount -o subvolid=0 UUID=4e47c0ba-f6ab-4b16-b915-3843a772b665 /mnt/btrfs > # vm-btrfs ~ # ls -al /mnt/btrfs > total 16 > drwxr-xr-x 1 root root 22 Feb 14 17:26 . > drwxr-xr-x 1 root root 132 Feb 15 02:55 .. > drwxr-xr-x 1 root root 132 Feb 15 02:55 @ > drwxr-xr-x 1 root root 10 Feb 15 02:55 @home > > # cat /proc/cmdline > crypt_root=UUID=ce7959ef-2d3c-4da8-8dac-fd75b0a700be root=UUID=4e47c0ba-f6ab-4b16-b915-3843a772b665 rootfstype=btrfs rootflags=rw,noatime,compress=lzo,space_cache,subvol=@ My kernel has set 'CONFIG_BTRFS_FS=m' (`zcat /proc/config.gz | grep BTRFS`) which means "/dev/btrfs-control" is not present when genkernel's initramfs will take control. After cryptsetup prompt for my LUKS container (UUID=ce7959ef-2d3c-4da8-8dac-fd75b0a700be), my root (UUID=4e47c0ba-f6ab-4b16-b915-3843a772b665) becomes available. Because of rootfstype=btrfs, mount command will trigger module loading for btrfs module (my setup even works without rootfstype hint, i.e. determine_fs from https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/initrd.scripts?h=v4.1.2#n238 will get the correct information from UDEV). tl;dr I was unable to reproduce the problem at all. I can only assume that you either did something wrong(?) or that only a specific BTRFS setup is failing. So it would be nice if someone who experienced mentioned problem could post setup details like I did. In the end I assume that the recent change to genkernel will fix the problem for all.
I have this issue here using BTRFS RAID0: ➜ zcat /proc/config.gz| grep BTRFS CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set # CONFIG_BTRFS_DEBUG is not set # CONFIG_BTRFS_ASSERT is not set # CONFIG_BTRFS_FS_REF_VERIFY is not set ➜ lsblk --output NAME,KNAME,FSTYPE,PARTUUID,UUID NAME KNAME FSTYPE PARTUUID UUID zram0 zram0 nvme0n1 nvme0n1 ├─nvme0n1p1 nvme0n1p1 vfat b7e4a3eb-b01c-4c51-bb61-020c60e0cd0b 80CD-FEB1 ├─nvme0n1p2 nvme0n1p2 vfat fb0f1fee-b532-41de-8550-dc5ae51141d2 8217-5D52 └─nvme0n1p3 nvme0n1p3 btrfs ff2c16d2-695b-4056-af17-c6ccaf437b6f 1e291ec4-f38b-4dbb-b05a-6e6e1a70978d nvme1n1 nvme1n1 └─nvme1n1p1 nvme1n1p1 btrfs f4bc8b6c-2dab-4824-a13a-2e3f05ea90c6 1e291ec4-f38b-4dbb-b05a-6e6e1a70978d ➜ btrfs subvolume list / ID 258 gen 141326 top level 5 path @ ID 259 gen 141320 top level 5 path @home ID 260 gen 9 top level 5 path @snapshots ID 266 gen 140202 top level 258 path srv ID 267 gen 817 top level 258 path var/lib/portables ID 268 gen 818 top level 258 path var/lib/machines ➜ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-5.10.16-gentoo-x86_64 root=UUID=1e291ec4-f38b-4dbb-b05a-6e6e1a70978d ro rootflags=subvol=@ init=/usr/lib/systemd/systemd rootfstype=btrfs dobtrfs When the system boots, I get the error described herein about /dev/btrfs-control not being found. If I enter the rescue shell, suddenly btrfs-control exists. So I literally enter the rescue shell and then immediately exit it. Then I enter my root device manually and hit enter and it boots w/o further issue. It's the same process described by Mike DeSimone but I don't even do the 'scan' step. I'm not using LUKS.
Thank you. I was able to reproduce the problem with current stable genkernel and can confirm that the fix from the weekend will resolve the problem.
Released with genkernel-4.2.0!
