On Mi, 27.01.21 17:19, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > Is it possible for a udev rule to have a timeout? For example: > /usr/lib/udev/rules.d/64-btrfs.rules > > This udev rule will wait indefinitely for a missing device to > appear. Hmm, no, that's a mis understaning. "rules" can't "wait". The activation of the btrfs file system won't happen, but that should then be caught by systemd mount timeouts and put you into recovery mode. udev only does the most basic form of btrfs raid activation. If you want more complex policies (i.e. "boot cleanly if 5 of the 7 hdd's have shown up plus 30s passed") then put that into some storage daemon. udev is not supposed to implement complex policies like that. > It'd be better if it gives up at some point and drops to a dracut > shell. Is that possible? The only alternative right now is the user > has to force power off, and boot with something like > rd.break=pre-mount, although I'm not 100% certain that'll break soon > enough to avoid the hang. That should be the default. But note that once you throw cryptsetup into mix the mount activation timeout is typically automatically turned off, because we cannot distinguish the cases where devices didn't show up because hdd borked from "user didn't type in their pw in time". To give the user any time they want for typing it in the logic thus turns off root fs activation timeouts. > Next, is it possible to enhance udev so that it can report the number > of devices expected for a Btrfs file system? This information is > currently in the Btrfs superblock found on each device in the > num_devices field. > https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627 systemd/udev has no clue about btrfs superblocks. It only talks to libblkid, and to the kernel. It doesn't parase anything on its own. If you want this property to be attached to the udev device, please request this from the libblkid maintainer, since we basically import all props it gives us 1:1 into udev rules. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel