My apologies for not using plain text mode. On Tue, May 13, 2025 at 4:08 PM Chengen Du <chengen.du@xxxxxxxxxxxxx> wrote: > > Hi, > > Apologies for including everyone in this message, but I’d like to bring your attention to a fix [1], which may require your input. > The issue concerns a potential hang during the boot process when the system is waiting for the encrypted swap device node. > This is caused by systemd-makefs skipping block device access locking for device-mapper devices. > > A more detailed explanation and proposed solution are documented here [2]. > > In brief, systemd-udevd probes block devices for filesystem superblock and partition table information as they appear. > If another process modifies a superblock or partition table concurrently, the probing can be affected. > This, in turn, may lead to unintended behavior in programs that rely on udev events. > > To mitigate such issues, systemd-udevd normally acquires a LOCK_SH|LOCK_NB using flock on the main block device before processing. > However, commit #e918a1b5a94f (udev: exclude device-mapper from block device ownership event locking) disabled this behavior for device-mapper devices, which appears to be the root cause of the boot hang with encrypted swap. > > The commit appears somewhat ambiguous to me, as my understanding is that device-mapper devices should not be deactivated while a udev rule is being processed. > I’ve reached out to the original author for clarification but haven’t received a response yet. > I’ve also reviewed related projects such as multipath-tools and lvm2, but couldn’t find similar examples of deactivating devices during udev remove events. > > As I may not be an expert in this specific area, I would greatly appreciate it if you could share your insights on the matter. > In particular, could you help confirm whether holding a flock lock on a block device while handling udev events might introduce any regressions? > If this issue falls outside your scope, please kindly disregard this message—and I apologize for the disturbance. > > Since the bug is related to a boot hang, we are eager to resolve it promptly. > Please don’t hesitate to raise any concerns or suggestions. > > Thank you very much for your support. > > Best regards, > Chengen Du > > [1] https://github.com/systemd/systemd/pull/37080 > [2] https://github.com/systemd/systemd/blob/main/docs/BLOCK_DEVICE_LOCKING.md
