As far as I can tell, I don't think we can "delay" the fsck service due to how the systemd-fstab-generator works on /etc/fstab entries
For entries with a no-zero value for fsck (6th column), then the generator will write out a .mount file that looks like this: ubuntu@ubuntu:/run/systemd/generator$ cat btrfs.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=local-fs.target Requires=systemd-fsck@dev-disk-by\x2duuid-d8e33db0\x2d9a54\x2d11e7\x2dbd8f\x2d525400123456.service After=systemd-fsck@dev-disk-by\x2duuid-d8e33db0\x2d9a54\x2d11e7\x2dbd8f\x2d525400123456.service [Mount] What=/dev/disk/by-uuid/d8e33db0-9a54-11e7-bd8f-525400123456 Where=/btrfs Type=btrfs This will want to run fsck on the device, and then mount it, and all *before* local-fs.target cloud-init cannot run until *after* local-fs.target is reached. Asking fsck service to run later is always going to be in-conflict with fsck+mount from the generator. I'm not sure we can reliably interrupt these services; the .mount unit is going to require a fsck; if we stop the fsck, then the mount won't happen. This is going to require some more thought and discussion. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1691489 Title: fstab entries written by cloud-config may not be mounted To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1691489/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
