You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The service introduced in #172 seems to assume that once the device for a filesystem is available, the filesystem will be able to be mounted. This is not true in some cases, and the one I'm hitting is with bcachefs. For encrypted bcachefs, a separate systemd service is used to unlock the device, after which it's able to be mounted. create-needed-for-boot-dirs is not waiting for this unlock to happen, so it fails on every boot.
The text was updated successfully, but these errors were encountered:
You could solve this by ordering the service after the unlock service, but I think it would be better to order the service after the persistence directory mount unit with RequiresMountsFor= and before all the bind mount units, so that you don't have to do your own mounting and device parsing or any of that stuff.
This can actually be extremely important e.g. in the case of a multi-device bcachefs file system that uses the x-systemd.requires= fs option to order the mount unit after more than one device. By trying to order after the device yourselves, you're not ordering after other necessary devices. Ordering after the actual mount units takes all the ambiguity out of the equation and says "I need the persistence dir to be mounted, however that's meant to happen".
The service introduced in #172 seems to assume that once the device for a filesystem is available, the filesystem will be able to be mounted. This is not true in some cases, and the one I'm hitting is with bcachefs. For encrypted bcachefs, a separate systemd service is used to unlock the device, after which it's able to be mounted.
create-needed-for-boot-dirs
is not waiting for this unlock to happen, so it fails on every boot.The text was updated successfully, but these errors were encountered: