Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable_overlayfs upper and lower directories are hidden #100

Open
msperl opened this issue Oct 14, 2019 · 5 comments
Open

enable_overlayfs upper and lower directories are hidden #100

msperl opened this issue Oct 14, 2019 · 5 comments

Comments

@msperl
Copy link

msperl commented Oct 14, 2019

First of all: I am very happy that this becomes easily available. - I have done this manually several times...

Is it on purpose that the upper and lower directories are hidden and not visible in df nor accessible?

I really like the way openwrt does it.

This way it is possible to figure out if the upper ramdisk is consuming lots of memory (df) and also what is really consuming the ram in the ramdisk (find /upper - size +100000 or similar)

Makes life easier to detect such situations when you also have monitoring in place...

I believe it should also be possible to chroot to /lower (rw mounted) and then do an os update - followed by an immediate reboot to be 100% synchronized to avoid inconsistencies between merged and changes to lower.
This avoids rebooting twice - once to rw mode, then change and another time back to overlay mode again...

Obviously this also has some drawbacks/issue/potential for questions and people need to know what to expect.

Biggest pitfall I know/see is the risk of modifying the upper work directory directly, which is not reflected in the overlay file system - especially: delete big files after the find mentioned above without going to the mounted overlayfs itself... (been there/done that/rebooted system in the end ...)

@XECDesign
Copy link
Member

I believe it should also be possible to chroot to /lower (rw mounted) and then do an os update - followed by an immediate reboot to be 100% synchronized to avoid inconsistencies between merged and changes to lower.

I was under the impression that would update the underlying files, but upper files would still be applied over the top of it, even if they're older than what was updated? If that's the case, there's a lot that can go wrong there.

I do think it would be good to be able to see the ramdisk usage though.

@msperl
Copy link
Author

msperl commented Jan 13, 2020

From my experience with openwrt or containers I actually do not care too much for lower (but it already has helped me restore an overwritten script without the reboot - this for all practical purposes should not be a writeable mount.

The upper RAM disk available allows you to:

  • find out what has really been changed/overwritten
  • you also gain the ability to know the used size of the ramdisk. As a hidden overlay it is not really available
  • you can also backup your local changes by just taring up the local changes (does not work too well for those delete file marker inodes), which is what docker does when it is packaging a layer...

But also for upper writes should be avoided otherwise you end up with files still in the overlay but not in the upper or lower layer. So by default read only as well may be recommended...

@XECDesign
Copy link
Member

Yeah, those are all reasons I'd want to have access to it as well. I'll take a look.

@lehni
Copy link

lehni commented Jun 10, 2020

For what it's worth, this repo here offers visible upper and lower directories, and works on Buster also:

https://github.com/JasperE84/root-ro

With that, it is possible for example to chroot into a RW version of the file-system while the Pi is in RO overlay mode, and make changes. I prefer this to what's raspi-config is currently offering:

    mount -o remount,rw /mnt/root-ro
    # Enable DNS in chroot because resolvconf service needs to read /run/resolvconf/resolv.conf
    mount -o bind /run /mnt/root-ro/run
    # Make `ps` & co work in `chroot`
    mount -t proc /proc /mnt/root-ro/proc
    chroot /mnt/root-ro sudo -i -u pi

To get back out of chroot and make the file-system RO again, I simply type:

    exit
    umount /mnt/root-ro/run
    umount /mnt/root-ro/proc
    mount -o remount,ro /mnt/root-ro

I have created scripts for both that check if I'm inside chroot or not:

sudo tee /root/mount-writable.sh << END
if ischroot; then
    echo 'You are already in writable chroot.'
else
    mount -o remount,rw /mnt/root-ro
    # Enable DNS in chroot because resolvconf service needs to read /run/resolvconf/resolv.conf
    mount -o bind /run /mnt/root-ro/run
    # Make `ps` & co work in `chroot`
    mount -t proc /proc /mnt/root-ro/proc
    chroot /mnt/root-ro sudo -i -u pi
fi
END

sudo tee /root/mount-readonly.sh << END
if ischroot; then
    echo 'You are still in writable chroot, run `exit` first.'
else
    umount /mnt/root-ro/run
    umount /mnt/root-ro/proc
    mount -o remount,ro /mnt/root-ro
fi
END

@henryptung
Copy link

henryptung commented Jun 25, 2022

For what it's worth, adding the following to local_mount_root() in /etc/initramfs-tools/scripts/overlay does the job:

        mkdir -p "${rootmnt}/overlay/lower"
        mount --bind /lower "${rootmnt}/overlay/lower"
        mkdir -p "${rootmnt}/overlay/upper"
        mount --bind /upper/data "${rootmnt}/overlay/upper"

You can update initramfs with the following as root (assuming mostly default setup):

mount -o remount,rw /boot
update-initramfs -c -k "$(uname -r)"
mv "/boot/initrd.img-$(uname -r)" "/boot/initrd.img-$(uname -r)-overlay"

Then reboot.

If anyone wants to convert the above into an option in raspi-config itself, probably won't be too hard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants