writable partitions not fsck'd.

[James Hunt]

The writable partition, mounted in the initramfs, is not fsck'd. This has now been fixed in initramfs-tools-ubuntu-touch, but not in initramfs-tools-ubuntu-core.

Also, the fstab entry for the boot partition has the fsck field set to "0" when it should be "2".

[James Hunt (jamesodhunt)]

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.

[Steve Langasek (vorlon)]

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.

[James Hunt (jamesodhunt)]

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.

[Steve Langasek (vorlon)]

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.