stage-1: Add support for rootfs on loop device #42
Conversation
|
New plan for the future: do what OpenWrt does. Instead of mounting the loop device directly, we can mount it read-only and then overlay tmpfs on top of it, so that we are not limited by the size of the img file. |
| inherit (lib) mkMerge mkOrder; | ||
|
|
||
| waitForRootfs = | ||
| lib.optionalString (elem "loop" rootfs.options) '' |
There was a problem hiding this comment.
Should this maybe happen unconditionally? I think it would make sense for block devices carrying the root filesystem too.
There was a problem hiding this comment.
I think regular devices are better covered by udevadm-settle (which currently doesn’t work for unknown reasons).
There was a problem hiding this comment.
Oh, wait, yeah, I see what you are talking about. Yes, it’s probably not a bad idea to wait unconditionally.
There was a problem hiding this comment.
Although with "real" block devices I guess we could use udev event like I also suggested in #35 (comment)
| lib.optionalString (elem "loop" rootfs.options) '' | ||
| while [ ! -f "${rootfs.device}" ]; do | ||
| echo "Waiting for the rootfs image at '${rootfs.device}'..." | ||
| sleep 5 |
There was a problem hiding this comment.
This delay could be shorter for a faster boot. To avoid spamming the console, we could print a . without a newline each on each loop rather than repeating the "Waiting" message.
|
Hi! 👋 Thanks for the contribution! We might need documentation, or script, for pushing the image to ram. Additionally, looking into documenting or making it possible to load from unencrypted storage, maybe loaded from an SD card even. Though, as it is, the only requirement here to continue with this (in addition to the other comments) would be documentation, or a script, so it is obvious how to push to device properly. |
|
I’m not sure where to put this documentation, but here it is:
|
No description provided.