On So, 11.10.20 14:57, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > Hi, > > A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set > to mount in /etc/fstab: > > UUID=f89f0a16-<snipped> /srv btrfs defaults,nofail,x-systemd.requires=/ 0 0 > > For some reason, systemd is trying to mount this file system before > all ten devices are ready. Supposedly this rule applies: > https://github.com/systemd/systemd/blob/master/rules.d/64-btrfs.rules.in udev calls the btrfs ready ioctl whenever a new btrfs fs block deice shows up. The ioctl will fail as long as not all devices that make up the fs have shown up. It succeeds once all devices for the fs are there. i.e. for n=10 devices it will return failure 9 times, and sucess the 1 final time. When precisely it returns success or failure is entirely up to the btrfs kernel code. systemd/udev doesn't have any control on that. The udev btrfs builtin is too trivial for that: it just calls the ioctl and that pretty much is it. > x-systemd.automount,noauto,nofail,x-systemd.requires=/ > > In fact, I'm not sure x-systemd.requires is needed because / must be > mounted successfully to read /etc/fstab in the first place; in order > to know to mount this file system at /srv x-systemd.requires=/ is a NOP. the root fs is always mounted, in systemd the unit "-.mount" that wraps it is marked with the "perpetual" flag internally, which all units have set that are always, unconditionally up as long as userspace exists. Thus requiring the root fs is useless, it's always there and implicitly required by all userspace. Also note: in the initrd the host root fs is at /sysroot/ not at /. During the initrd→host transition we do a switch root after all that turns /sysroot/ → /. > Anyway I'm mainly confused why the btrfs udev rule is seemingly not > applied in this case. For historical reasons udev log level is independent from the rest of systemd log level. Thus use udev.log_priority=debug to turn on udev debug logging. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel