Comment 22 for bug 1691489

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.