dracut
dracut copied to clipboard
dracutdevs
fix(dmsquash-live): add support for NFS
Checklist
- [X] I have tested it locally
- [X] I have reviewed and updated any documentation if relevant
- [X] I am providing new code and test(s) for it
Fixes #1904
Moved out overlayfs mount into its own dedicated file so that we can call into it directly for NFS support.
Added a new test case for overlayfs on top of NFS (which is now passing :-))
To facilitate PR reviews (and help to prioritize), I wanted to express that from my contributor perspective, this one PR has by far the biggest impact on the dracut project.
This PR adds a functionality that many would use.
I understand review resources are very limited, so just wanted to communicate that getting feedback on this PR is more important (and likely more impactful) on the project than my other PR.
This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thanks for working on the overlayfs module and adding support for using it with NFS. In my old Debian implementation, I've mounted a tmpfs on top of the rad-only NFS mount to make this writeable. How can I do this with the new implementation? I can't see anything similar in the code.
@Mrfai
In my old Debian implementation, I've mounted a tmpfs on top of the rad-only NFS mount to make this writeable. How can I do this with the new implementation? I can't see anything similar in the code.
From mount-overlayfs.sh
mount -t overlay ... upperdir=/run/overlayfs ...
/run is a tmpfs that is already created earlier in the dracut boot process.
Is there a way for you to test this dracut module in your Debian environment as well in addition to the CI tests ?
I've been playing with all of these rd.live options for the past few days and while I admit I haven't reviewed the actual code, it seems to me it either doesn't work or the docs are woefully lacking. I've been using identical copies of a 4GiB rootfs with both of the methods listed at the top of the section "Booting live images" for Squashfs in dracut.cmdline docs.
On the squashfs overlay image (all files in squashfs root) the rd.live.overlay.size option has no effect on the size of the overlay. No effect on the snapshot image either. With the rootfs.img within squashfs method (DM-snapshots) rd.live.overlay.readonly seems to indicate it would use the dm-snap device as the read-only bottom of an overlay but it has no effect.
rd.live.ram=1 works fine on the former case, but it causes a fail to boot with the latter. rd.writable.fsimg=1 will copy the /LiveOS/rootfs.img inside an SFS to /run/initramfs successfully IF /run's default size will fit the uncompressed rootfs.img. Right now this doesn't work out the box for files larger than 1GiB or so since /run seems to default to 2GiB on my system (8GiB). The size option does not help.
Maybe I am not using this stuff right though.
These also don't support my original use case of booting a read-only ext4/btrfs/erofs filesystem protected by dm-verity as the lowerdir of a forgetful overlayfs root for kiosks/stability and to appease users who want security and a 'normal arch experience'. The rd.live options seem to only work on squashfs and ext4 filesystem images not partitions. Basically it would be great if this code could do overlay mounts with tmpfs upperdir on the root filesystem residing on arbitrary devices.
Thanks @TylerHelt0 .
Lot to unbundle. Appreciate that you're sharing the use-cases with details. I think lack of understanding of all the use-cases is an area to improve. Control over the size of overlay is certainly a good point.
The rd.live options seem to only work on squashfs and ext4 filesystem images not partitions.
I would start with this first. We have tests for partitions that seem to be passing -https://github.com/dracutdevs/dracut/commit/027eee902d0d7af4db45fcb7835d49990c9fafa1 .
Are you using upstream latest dracut ? Which distro ?
I'm on Dracut 56-1 from the arch repos. I haven't actually tried using these options with an ext4 partition so they may work with the latest upstream. Also to note, both of the SFS images I used booted fine with default directory hierarchies and filenames expected by dracut and using only root=live:LABEL= syntax. The overlay image is easily resized by remounting /run. The dm-snapshot image is locked to the size of the ext4 filesystem (I have not tried modifying the underlying dm devices)
Kept the priority of the mount to 01 for overlayfs, as changing the mount priority is out of scope for this PR.
@TylerHelt0
I'm on Dracut 56-1 from the arch repos.
Lot has changed in this area upstream since v56. You should try to build from this upstream repo and try again. If building from upstream sounds too scary, you will likely able to just grab the modules.d directory from upstream instead of the a full dracut build.
Arch has dracut-git that is built from github. I installed this and it solved an issue with lvm messages printing to console during boot but I haven't had a chance to test the rd.live options. I'm mainly interested in those for creating Live USBs. I wonder how fedora handles Copy to Ram. I bet they just use rootfs.img inside squashfs method. Could be wrong. I'll report back if I have time to test them using latest dracut-git.
in your second commit (https://github.com/dracutdevs/dracut/commit/38eab1aab9cc1a2d235ef3ab1e658f7fcae9e2a9) the mount is tried even with systemd present, just with a previous check
Thanks for pointing this out. Yes, this was done intentionally.
Since there is a longer term desire to separate systemd dracut modules into its own modules, we should keep systemd dependency out of overlayfs module. Perhaps at a later time we can introduce a systemd-overlayfs module, but that is not in scope for this PR.
To address the specific concern, I added an extra check to only pull in overlayfs as a dependency for dmsquash-live only if systemd is not installed.
To address the specific concern, I added an extra check to only pull in overlayfs as a dependency for dmsquash-live only if systemd is not installed.
Thanks for your clarification. If this was done intentionally and it's already approved by @Conan-Kudo and @johannbg, maybe you don't need to add this extra check. I just wanted to be sure that everyone is aware.
@aafeijoo-suse Is there anything else you'd like to change on this PR ? Thanks !