-
Notifications
You must be signed in to change notification settings - Fork 207
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
Comments
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. |
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:
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... |
Yeah, those are all reasons I'd want to have access to it as well. I'll take a look. |
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 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 |
For what it's worth, adding the following to
You can update initramfs with the following as root (assuming mostly default setup):
Then reboot. If anyone wants to convert the above into an option in raspi-config itself, probably won't be too hard. |
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 ...)
The text was updated successfully, but these errors were encountered: