From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] Core Update 169: Regenerate initrds and save space on ARM
Date: Tue, 12 Jul 2022 13:00:56 +0200 [thread overview]
Message-ID: <75a06c3f-29dd-6e69-0eff-e45396047dd2@ipfire.org> (raw)
In-Reply-To: <30DC4452-39ED-4B09-A6B2-F40A617AC21C@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 4851 bytes --]
Hi All,
On 12/07/2022 12:35, Michael Tremer wrote:
> Hello,
>
>> On 10 Jul 2022, at 12:13, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>
>> Hello Jon,
>>
>> thanks for your reply.
>>
>>> Peter / Michael,
>>>
>>>
>>>> * It is not entirely error-proof (out of disk space, out of memory, system being rebooted too early)
>>> Is it possible to add a Disk Space check before doing an upgrade?
>> Um, I thought we do that in the update.sh of every Core Update that involves a kernel update?
>>
>>> I’ve been bit twice by running out of disk space mid-upgrade. I was remotely upgrading a family member's system from CU 163 to CU 167 and got stuck ½ way.
>> When multiple Core Updates are available, Pakfire will currently download them all before applying
>> them sequentially. On systems with very tight disk space, this can indeed cause trouble, since the
>> more Core Updates they lag behind, the greater is the amount of disk space necessary for upgrading.
>>
>> I guess it makes sense to raise this issue and the general question whether we should ship initial
>> ramdisks or generate them on the target systems (the former has quite some impact on Core Update
>> sizes) in the August telephone conference.
>>
>> Any thoughts?
> I can live with both: Shipping or building locally.
>
> But I would want to only do one. Never mix and match. Whatever we do, we will go with it.
>
> Since we are tight on space, why don’t we generate them?
That seems a good approach to me. As you say, space is always being talked about. Presumably generating them will take a bit longer for the update but I doubt that it will be a very big impact.
So I support to generate them.
Regards,
Adolf
>> Thanks, and best regards,
>> Peter Müller
>>
>>> Here is my recent oops:
>>>
>>> ```
>>> Message from syslogd(a)ipfire4 at Fri May 13 14:59:33 2022 ...
>>> ipfire4 ipfire: core-update-164: ERROR cannot update because not enough free space on root.
>>> May 13 14:59:33 ipfire4 pakfire: PAKFIRE ERROR: Returncode: 2. Sorry. Please search our forum to find a solution for this problem.
>>> May 13 14:59:55 ipfire4 sshd[31097]: Received signal 15; terminating.
>>> ```
>>>
>>> Jon
>>>
>>>
>>>
>>>
>>>
>>>> On Jul 7, 2022, at 8:19 AM, Michael Tremer <michael.tremer(a)ipfire.org<mailto:michael.tremer(a)ipfire.org>> wrote:
>>>>
>>>> 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)
>>>>
>>>> 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<mailto: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<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
next prev parent reply other threads:[~2022-07-12 11:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <83713DF0-29F4-4604-8804-C0D7C350BA92@gmail.com>
2022-07-10 10:13 ` Peter Müller
2022-07-12 10:35 ` Michael Tremer
2022-07-12 11:00 ` Adolf Belka [this message]
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
2022-07-07 13:54 ` Michael Tremer
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=75a06c3f-29dd-6e69-0eff-e45396047dd2@ipfire.org \
--to=adolf.belka@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