Please just send a patch to the list :)
On 7 Jul 2022, at 15:54, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
Hello,
On 7 Jul 2022, at 15:49, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
Hello,
On 7 Jul 2022, at 15:30, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your reply.
Hello, Indeed we don’t need to ship them, we can generate them instead. But that has of course some downsides, too:
- It is slow
- It is not entirely error-proof (out of disk space, out of memory, system being rebooted too early)
So I guess the first newly introduced line ("dracut --regenerate-all --force") of my patch is obsolete then, as the initrds are already there - we just need the directives for ARM.
Those should be shipped, too. Adding more size to the updater when shipping the same stuff multiple times.
To my understanding, if dracut fails due to space/memory issues, the upgrade would have failed either way.
My point was that extracting the update would consume less memory. Disk space constraints still apply unless there is not enough temporary space.
Do you want me to submit a v2 of this patch without the dracut directive? Or should I commit this straight to next, and you cherry-pick it into master?
We should either ship everything, or generate everything. I don’t think a mix is good idea.
agreed.
Then, this boils down to an "rm" statement on 32-bit ARM, and I will omit regenerating the initds - that's how Core Update 169 has been thus far, and there were no complaints whatsoever.
I will push this straight to next and get back to you shortly...
We probably don’t want this in next. That already has c170.
true, but I cannot push to "master". Is it feasible for you to cherry-pick 5ead33d796b9537bddbc4e2d5d27029de4df001a?
Thanks, and best regards, Peter Müller
Thanks, and best regards, Peter Müller
Thanks, and best regards, Peter Müller
I do not really have much of a preference. The only thing I want to say is that ARM needs to get their shit together and being able to load a regular image instead of asking for extra commands here - or build that into dracut. -Michael > On 7 Jul 2022, at 07:48, Peter Müller peter.mueller@ipfire.org wrote: > > Hello *, > > to my understanding, we do not need to ship "linux-initrd" if we can easily > rebuild those on the systems anyway. I would prefer the latter, since that > keeps the update smaller. > > This was also raised somewhere in the community a while ago, but I am unable > to find the correspondent thread at the moment. > > How do we proceed here? > > Thanks, and best regards, > Peter Müller > > >> https://community.ipfire.org/t/again-with-the-file-system-full-core-169/8186 >> >> Signed-off-by: Peter Müller peter.mueller@ipfire.org >> --- >> config/rootfiles/core/169/update.sh | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/config/rootfiles/core/169/update.sh b/config/rootfiles/core/169/update.sh >> index 3902e2d45..50f0bd8a4 100644 >> --- a/config/rootfiles/core/169/update.sh >> +++ b/config/rootfiles/core/169/update.sh >> @@ -150,6 +150,19 @@ ldconfig >> # Apply sysctl changes >> /etc/init.d/sysctl start >> >> +# Regenerate all initrds >> +dracut --regenerate-all --force >> +case "$(uname -m)" in >> + armv*) >> + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >> + rm /boot/initramfs-${KVER}-ipfire.img >> + ;; >> + aarch64) >> + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >> + # dont remove initramfs because grub need this to boot. >> + ;; >> +esac >> + >> # Start services >> telinit u >> /etc/init.d/firewall restart