writable partitions not fsck'd.

The reason for mounting the writable partition in the initramfs is to allow it to be move-mounted over the read-only root I believe, but stgraber may have more information on this.

The actual reason for mounting the writable partition read-write in the initramfs is that we have to bind-mount /writable/system-data/etc/systemd/system to /etc/systemd/system before systemd starts, which means we must be able to ensure that this source directory exists.

I don't think we should add even more code to the initramfs to accommodate this. I would rather we fix the userspace code to ensure the directory's existence, and in the worst case we should use systemctl daemon-reload.

Ah - now it makes sense :-) So fwics, you added that code to handle the job that was previously done in writable-paths (ubuntu-core-config package). Handling the mount in writable-paths didn't work as it was mounted too late for systemd to see it at the point pid 1 started.

I believe pitti was looking at this too, so might have some thoughts on the best systemd approach on bringing the code back into userspace.

Meantime, I think it makes sense to land just the fsck_passno changes for the boot partition from my branch for now.

Looking more closely, I see that in fact all of the writable_paths handling happens in the initramfs. so this isn't specific to the systemd directory. It also means that removing any need for a read-write /writable in the initramfs requires a lot more work, and shouldn't block efforts to fix this problem.

I agree we should at least land the fix for fscking the boot partition. And fscking /writable from the initramfs is probably acceptable in the near term.