Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upmkfs.btrfs on encrypted devices causes systemd-cryptsetup restart loop #5955
Comments
|
https://github.com/systemd/systemd/blob/master/rules/99-systemd.rules.in#L20 Note that the rule is not limited to add but also change action, which will be triggered when you mkfs/wipefs. Since you were using udev might be able to notice the "blank stage" of the mappers after |
|
Intuitively I think the dm devices should simply be left alone once they have been opened. In any case, the raw devices should not vanish no matter their contents. That's the wrong direction to go in the depencency chain. In particular, having no FS on a dm should not mean it is unplugged. That should depend on the underlying device, not the user contents in the mapper. Systemd really makes some complicated things simpler, but it makes some simple things so complicated (SCNR). |
|
Well, let say you have the encrypted partition opened by crypttab/systemd-cryptsetup service, but then you I am not sure about the point of the udev rule. At the very least, it should be limited to add action I suppose. P.S. I've been having concern over BindsTo= recently, for the fact that it also implies a Requires=, especially when start job does not really make sense to devices... |
systemd 232 (openSUSE Tumbleweed).
Initial state - existing btrfs on three encrypted devices:
Of course two devices still "do not exist" because we helpfully mark them as "not ready".
Now create new filesystem on the same device.
Oops. Two of three devices are gone. systemd goes amok stopping and starting cryptsetup services until it finally manages to somehow stabilize.