240.0: Can't boot with bcache mountpoint in fstab. Can't mount bcache FS. #11368
Comments
|
|
|
Could you try the current git snapshot? |
yuwata
added
udev
needs-reporter-feedback ❓
|
I'm using Debian, with relevant packages: dracut, dracut-core (048+80-1); udev, libudev1 (240-4), and am experiencing the same apparent failure to register a volume with bcache, with identical error messages as above. However, the same failure is reported with the PROGRAM invocation from line 14–15 in /usr/lib/dracut/modules.d/90lvm/64-lvm.rules, a dracut specific udev rule: The referenced sysfs paths all exist on later inspection (while the initramfs is running), leaving little room for actual failure within this command. Similarly, bcache-register is a very thin wrapper around writing to sysfs, which works later from within the initramfs. Therefore, I think it's fairly likely that this is an issue in udev itself, or in using sysfs. |
|
With systemd 241, the issue is still recurring here, but now with only the message: Running bcache-register for a different block device /dev/sda2 completes without any message. |
|
hmm, this looks like a problem in bcache-register now, i.e. you might want to check under which conditions bcache_register returns exit code 1 |
|
Per my comment above, bcache-register is a very thin wrapper around writing to sysfs. It exits with code 1 if there is more than one argument, if it fails to open() /sys/fs/bcache/register write only, or if it then fails to dprintf() to the opened fd. udev does not appear to be logging any of the associated messages to stderr to distinguish the cases. The referenced command is successful if later run manually from within dracut, consistent with the sysfs paths existing on later examination per my comment, above. |
|
Could you show the source of the wrapper? |
|
@poettering BTW, currently, spawned external programs by |
|
Thanks. Hmm... so simple. |
|
Are there any relevant logs when booting with From the rule, |
This fixes bugs introduced by 2944849 and d838e14. Previously, RUN and SECLABEL keys are stored in udev_list with its unique flag is false. If the flag is false, then udev_list is just a linked list and new entries are always added in the last. So, we should use OrderedHashmap instead of Hashmap. Fixes systemd#11368.
yuwata
added
has-pr ✨
and removed
needs-reporter-feedback ❓
|
Maybe I found the root of this issue. If possible, please test #11891. |
yuwata
added
the
regression ⚠️
This fixes bugs introduced by 2944849 and d838e14. Previously, RUN and SECLABEL keys are stored in udev_list with its unique flag is false. If the flag is false, then udev_list is just a linked list and new entries are always added in the last. So, we should use OrderedHashmap instead of Hashmap. Fixes systemd#11368.
This fixes bugs introduced by 2944849 and d838e14. Previously, RUN and SECLABEL keys are stored in udev_list with its unique flag is false. If the flag is false, then udev_list is just a linked list and new entries are always added in the last. So, we should use OrderedHashmap instead of Hashmap. Fixes #11368.
This fixes bugs introduced by 2944849 and d838e14. Previously, RUN and SECLABEL keys are stored in udev_list with its unique flag is false. If the flag is false, then udev_list is just a linked list and new entries are always added in the last. So, we should use OrderedHashmap instead of Hashmap. Fixes systemd#11368. (cherry picked from commit 39a15c8)
|
#11891 is merged, and backporting this to v241 is waiting in systemd/systemd-stable#47, though I am not sure archlinux uses the repository or not. |
|
Here is the output from udev in the initramfs (dracut) with udev debug log_priority, clipped to the relevant process when it is processing the bcache device. As you have surmised to be the problem, the RUN lines are occurring in a different order than as specified in the rules file. |
|
@endomandi this is with #11891 ? |
|
Apologies for not including the necessary information. That log was in response to this:
So, that is without #11891. |
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Upgrade to 240.0, reboot.
Reverting to earlier systemd (239.370) fixes the problem:
boot-success-239.log
Archlinux bug report:
https://bugs.archlinux.org/task/61317
The text was updated successfully, but these errors were encountered: