Hello Michael,

> Hello,
> 
>> On 7 Jul 2022, at 15:30, Peter Müller <peter.mueller(a)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...

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(a)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(a)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
>