Automount overlay for /etc

Technical Support
, ,
1

Hi,

am currently trying to create an overlay for /etc to change the rootfs to read-only in the future.
Using a manual mount command work, adding an entry to fstab work with a manual mount -a.
But it is not mounting automatically during boot up.

fstab entry:

overlay /etc overlay defaults,nofail,lowerdir=/etc,upperdir=/home/root/etc/upper,workdir=/home/root/etc/work 0 0

After trying it with fstab, I found a post in the raspberrypi community where a user tries it with systemd.

[Unit]
Description=/etc overlay mount not really working
Documentation=https://github.com/systemd/systemd/issues/8732 (closed)
Before=local-fs.target
Wants=local-fs.target

[Mount]
What=overlay
Where=/etc
Type=overlay
Options=auto,lowerdir=/etc,upperdir=/home/root/etc/upper,workdir=/home/root/etc/work

[Install]
WantedBy=local-fs-pre.target

This doesnt work either. journalctl shows the following error message:

 mount[242]: mount: /etc: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or ot
her error.

Does anybody have a solution for this problem?
If it is possibly without creating a service or script that calls “mount -a”.

2

Hi @gandi ,

Thanks for using the Toradex Community.

I found this forum entry on the ubuntu forum.

https://askubuntu.com/questions/839355/howto-mount-drive-as-read-only-with-fstab

I tried it on my end by editing the file with “vi /etc/fstab” and adding “ro” to the 4th column of the boot partition.

You can give this a try and let me know if it had the desired effect.

Best Regards
Kevin

3

Hi @kevin.tx

thank you for your response. But mounting the rootfs as read-only is not the problem.

After mounting the root partition as read-only, I want to overlay the /etc directory with
a folder on a separate partition. And this does not work at start-up.

BR Martin

4

Hi,

i found a solution thanks to this thread filesystem - How do I use OverlayFS? - Ask Ubuntu
You have to add a requires option for the overlay to wait until the desired upper
directory is ready to mount.

The additional entries in the fstab file looks like this:

/dev/disk/by-label/Settings   /settings   ext4   defaults   0    2
/dev/disk/by-label/Home       /home       ext4   defaults   0    2
overlay /etc   overlay defaults,x-systemd.requires=/settings,lowerdir=/etc,upperdir=/settings/etc/upper,workdir=/settings/etc/working 0 0
5

Hi @gandi ,

thanks for the update.

Glad to hear that it works now.

Best Regards
Kevin

6

Hi

I’m also struggling with RO FS.

Overlay over /etc may break /etc/machine-id. And when machine-id is broken (empty /etc/machine-id after /etc overlay mount), some services may fail to operate. For example, systemd-networkd won’t be able to configure and start network interfaces. Perhaps using connman hides the issue, I don’t know, you always check contents of machine-id.

Will it break or not depends on what is first, rw /etc overlay mount or systemd machine-id commit. If machine-id commit happens first, and it sees read only /etc/machine-id, then it will mount -B over it machine-id form tmpfs. And then, when /etc overlay is mounted, previous bind mount will be hidden by empty /etc/machine-id .

I think it is better to implement service similar to Yocto virtual binds to mount /etc overlay. Service should check presence of bind mount of /etc/machine-id (BTW mountpoint executable checks only fstab items, it doesn’t see temporary mounts). It should take contents of machine-id and either copy contents back to machine-id in overlay (after overlay is mounted), or perhaps unmount /etc/machine-id bind, rw remount for a moment RO root, update machine-id, and remount it back RW. Remounting RW should be better I think, machine-id should be generated once on first boot.

Edward

7

Hi @Edward,

Thank you for your investigation.

I will forward your findings to the BSP team, they will have a look at it and decide about next steps.

As soon as there’s an update on that, I’ll post it here.

Best Regards
Kevin

8

Hello @Edward,
Thank you for sharing your findings. We know that on our BSP Reference Images, it’s impossible to run the rootfs RO. As you already noticed, there are some details on the way some of the software runs today, making it harder to achieve such a goal. In the case of our reference images, having the ability to run them RO would also prevent other features that we implement on them from working and that’s a tradeoff we’re not willing to make.
Our BSP layer currently also doesn’t support the implementation of RO rootfs very easily. This is something that we are going to track and fix internally in due time.

In the meantime, I would also like to point out that Torizon core already implements a RO rootfs and ostree by default, and it could be a good option for some projects.

Best regards,
Rafael