public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] Core Update 169: Regenerate initrds and save space on ARM
Date: Thu, 07 Jul 2022 13:54:21 +0000	[thread overview]
Message-ID: <1fecd52f-bfd0-39f1-52a6-d063d090495c@ipfire.org> (raw)
In-Reply-To: <88A4CF3B-FB6E-426D-A547-13B08EB57107@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 4172 bytes --]

Hello Michael,

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

  reply	other threads:[~2022-07-07 13:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07  5:46 Peter Müller
2022-07-07  5:48 ` Peter Müller
2022-07-07 13:19   ` Michael Tremer
2022-07-07 13:30     ` Peter Müller
2022-07-07 13:43       ` Michael Tremer
2022-07-07 13:49         ` Peter Müller
2022-07-07 13:53           ` Michael Tremer
2022-07-07 13:54             ` Peter Müller [this message]
2022-07-07 13:54               ` Michael Tremer
2022-07-07 13:58                 ` [PATCH v2] Core Update 169: Delete unused initrd on 32-bit ARM to save space in /boot Peter Müller
2022-07-07 14:02                   ` Michael Tremer
2022-07-07 14:05                     ` Peter Müller
2022-07-07 14:11                       ` Michael Tremer
     [not found] <83713DF0-29F4-4604-8804-C0D7C350BA92@gmail.com>
2022-07-10 10:13 ` [PATCH] Core Update 169: Regenerate initrds and save space on ARM Peter Müller
2022-07-12 10:35   ` Michael Tremer
2022-07-12 11:00     ` Adolf Belka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1fecd52f-bfd0-39f1-52a6-d063d090495c@ipfire.org \
    --to=peter.mueller@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox