Created attachment 107360 [details] The test program which reproduces bug in systemd-gpt-auto-generator I boot without initrd, my root partition is btrfs on GPT. At boot I see the following message: systemd-gpt-auto-generator[84]: Failed to determine block device of root file system: No such file or directory And systemd-gpt-auto-generator fails with error code 1. I've made some debugging and found out that in function get_btrfs_block_device() (in file src/gpt-auto-generator/gpt-auto-generator.c) on line 633 we try to stat /dev/root, but /dev/root does not exist at the moment, and it leads to failure: if (stat((char*) di.path, &st) < 0) If someone runs this code when booting with initrd, it stats /dev/sda2 and runs successfully. But when I boot without initrd, my root filesystem is shown in /etc/mtab as /dev/root (instead of /dev/sda2), because it was mounted from kernel (not from userspace like in case of initrd), and systemd=gpt-auto-generator fails. Also if someone runs this code after fsck'ing and remounting root, it also runs successfully, because after remount root filesystem is shown as /dev/sda2 in /etc/mtab. I'm attaching a test program, it contains two functions copied from systemd (get_block_device and get_btrfs_block_device) with some debug output added. When I run it as init, it shows the following: /dev/root on / type btrfs (ro,relatime,space_cache) devtmpfs on /dev type devtmpfs (rw,relatime,size=1029996k,nr_inodes=220674,mode=755) proc on /proc type proc (rw,relatime) lstat major statfs open ioctl ioctl in loop stat in loop: '/dev/root' -2 And when I run in from booted system (after remounting /), it shows the following: /dev/sda2 on / type btrfs (rw,noatime,compress=lzo,space_cache,autodefrag) devtmpfs on /dev type devtmpfs (rw,relatime,size=1029996k,nr_inodes=220674,mode=755) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) tmpfs on /tmp type tmpfs (rw) /dev/sda3 on /build type btrfs (rw,noatime,compress=lzo,space_cache,autodefrag) /dev/sda4 on /home type btrfs (rw,noatime,compress=lzo,space_cache,autodefrag) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=206044k,mode=700) lstat major statfs open ioctl ioctl in loop stat in loop: '/dev/sda2' S_ISBLK in loop major in loop good in loop 1 I'm on Gentoo, my systemd version is 216. The desired effect: systemd-gpt-auto-generator should not fail when the system is booted without initrd.
Hmmm, yuck. Seems on initrd less boots /dev/root really is what the root disk is mounted off... Not entirely sure what we can do in this case though...
This was a longterm problem for me until I found googling: #!/bin/bash R=$(stat -c '%04D' / ) for f in $(find /dev -type b 2>/dev/null) ; do C=$(stat -c '%02t%02T' $f ) [ "$C" = "$R" ] && ROOTDEVICE="$f" && break done echo $ROOTDEVICE #--- But watching your nluug/2014-11-20 about capabilities that script I use to find root would not work in a container which has no capability to see /dev/RAW devices?
Hmm, so this appears to be a btrfs kernel bug. it should not return the useless "/dev/root" string as a volume device when asked via the BTRFS_IOC_DEV_INFO ioctl. it should instead return a proper device name, that we can actually make use of from userspace. Could you please file a bug against btrfs/kernel, so that they fix what the ioctl returns? Thanks!
(In reply to Lennart Poettering from comment #3) > Hmm, so this appears to be a btrfs kernel bug. it should not return the > useless "/dev/root" string as a volume device when asked via the > BTRFS_IOC_DEV_INFO ioctl. it should instead return a proper device name, > that we can actually make use of from userspace. > > Could you please file a bug against btrfs/kernel, so that they fix what the > ioctl returns? > > Thanks! Reported here: https://bugzilla.kernel.org/show_bug.cgi?id=89721 Though "/dev/root" is really device name used to mount root (and it resolves to 8:4 by blkdev_get_by_path on my system), even /proc/mounts contain /dev/sda4 as root device name, so it's wrong to report "/dev/root" instead of "/dev/sda4".
I am affected by this issue. Is there a workaround? Given that my system boots up even if I get this message, I would think it would be possible to provide systemd with the correct information on beforehand or during boot, so as to avoid this message.
(In reply to Erik Quaeghebeur from comment #5) > I am affected by this issue. Some more info; excerpts from the journal: mrt 17 21:23:15 hostname systemd-gpt-auto-generator[108]: Failed to determine block device of root file system: No such file or directory [...] mrt 17 21:23:15 hostname systemd[100]: /lib64/systemd/system-generators/systemd-gpt-auto-generator failed with exit status 1. [...] mrt 17 21:23:15 hostname kernel: BTRFS info (device sda3): device fsid d9bb1e6b-6c6e-4eeb-99b7-2167a21c84ec devid 1 moved old:/dev/root new:/dev/sda3 So BTRFS does seem to correct this at some point, but too late. Could systemd wait until after BTRFS is done doing this, or retry? It seems the situation has changed since the 2014 reports, so reopening.
yep it definitely seems to have a mini workaround built in now. so presumably it just needs some more work on the systemd side and it's solved
Please leave this closed. Bug tracking has long since moved to github. If you can reproduce the issue on one of the two most recent systemd versions please file an issue there, but do not reopen or create new bugs on this old bugzilla instance. Thank you for understanding. https://github.com/systemd/systemd/issues
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.