Please just send a patch to the list :) > On 7 Jul 2022, at 15:54, Peter Müller wrote: > > Hello Michael, > >> Hello, >>> On 7 Jul 2022, at 15:49, Peter Müller wrote: >>> >>> Hello Michael, >>> >>>> Hello, >>>>> On 7 Jul 2022, at 15:30, Peter Müller 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 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 >>>>>>>> --- >>>>>>>> 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