bcachefs: unlock-bcachefs-*.service fails with device = "UUID=..."

[ElvishJerricco]

When you specify the device with UUID=..., the unlock-bcachefs- service attempts to wait on a device called UUID=.... This doesn't work, because systemd does not translate this into a device path; it just expects a literal file named UUID=.... This has been fixed specifically for the What= directive in mount units, but this fix does not apply to device unit names.

The result is that you end up waiting on a device that will never exist to run a service that you might not even need if you're not using encryption (which is normally fine because of the ExecCondition).

We've really gotta rethink everything about how we're mounting bcachefs file systems, especially given the problems with multi-device ones.

[JohnRTitor]

A workaround here: #316695 (comment)

Apparently this is a systemd bug: #316695 (comment) (Upstream issue: systemd/systemd#28989)

CC: @lheckemann

I feel like a lot of issues like #316396 these keep popping up due to slow moving systemd and incompatibility with our current mounting methods.

[ElvishJerricco]

That workaround does work, because it switches from UUID= to an absolute device path. However that systemd bug is not at all relevant in this issue. It's entirely our own fault with how we generate our unlock-bcachefs-* services.

I think I should have been more clear with exactly what bug I'm describing. I'll update the description

[ElvishJerricco]

I may have gone a little overboard and created this thing to solve this: https://github.com/ElvishJerricco/bcachefs-fstab-generator

TL;DR: It's a systemd generator that parses fstab to generate the unlock service, rather than having Nix expressions create services for it. It's not fundamentally all that different from what NixOS is doing, except it can also do gpt-auto-root. But it can also parse UUID=... style devices correctly too :P