@vgaetera Thanks for your prompt reply! Do you want to turn these into an OpenWrt package? Do you want to be a maintainer if I create a package from your scripts from wiki and send PR for it to OpenWrt repo? If not, what kind of credits do I need to include with the package I can create?
3 Likes
I believe, it would be best to launch the resizing script at the preinit stage, when the root filesystem is not yet mounted, so neither rebooting nor setting up a loopback device should be necessary, while the second best option is converting the uci-defaults scripts to a procd service.
Both ways require packaging, but I have no plans to become a maintainer for the time being, although I can help with initial testing if someone decides to take the role.
If you create this package, it would be enough to mention my GitHub nickname and the link to the expand root script in the PR message or the commit description.
So is it enough to place the script in /lib/preinit/ with the priority higher (smaller value) than 80 and reboots are not necessary then? Anything else needs to be changed in the script besides no reboot?
We may need to reconsider the idea with preinit and implement a service instead, as when the root filesystem is not yet mounted, resize2fs is likely not available and we cannot access the lock files which makes problematic to determine whether resizing has already been done or not.
Why do you think packaging it as a service is a preferred solution to just packaging uci-defaults scripts?
To tell the truth, uci-defaults is not really designed for this task and requires some hacks to make it work properly, specifically non-zero error codes and preemptive overlay mounts, but those can be safely discarded with a procd service.
I see. Before I dedicate time to a PROCD-script, would it make sense to ask for core devs help/feedback with the pre-init-compatible script tho?
1 Like