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: Sun, 10 Jul 2022 10:13:39 +0000	[thread overview]
Message-ID: <b1058306-d4bc-1d3a-742f-6562b9e9acde@ipfire.org> (raw)
In-Reply-To: <83713DF0-29F4-4604-8804-C0D7C350BA92@gmail.com>

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

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?

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
>>
> 
> 

       reply	other threads:[~2022-07-10 10:13 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 [this message]
2022-07-12 10:35   ` Michael Tremer
2022-07-12 11:00     ` Adolf Belka
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=b1058306-d4bc-1d3a-742f-6562b9e9acde@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