My apologies for not using plain text mode.
On Tue, May 13, 2025 at 4:08 PM Chengen Du <chengen...@canonical.com> 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
