From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka 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 Message-ID: <75a06c3f-29dd-6e69-0eff-e45396047dd2@ipfire.org> In-Reply-To: <30DC4452-39ED-4B09-A6B2-F40A617AC21C@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7282943782073058078==" List-Id: --===============7282943782073058078== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, On 12/07/2022 12:35, Michael Tremer wrote: > Hello, > >> On 10 Jul 2022, at 12:13, Peter M=C3=BCller w= rote: >> >> Hello Jon, >> >> thanks for your reply. >> >>> Peter / Michael, >>> >>> >>>> * It is not entirely error-proof (out of disk space, out of memory, syst= em 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 involv= es a kernel update? >> >>> I=E2=80=99ve been bit twice by running out of disk space mid-upgrade. I w= as remotely upgrading a family member's system from CU 163 to CU 167 and got = stuck =C2=BD 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 whethe= r 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 wi= ll go with it. > > Since we are tight on space, why don=E2=80=99t we generate them? That seems a good approach to me. As you say, space is always being talked ab= out. Presumably generating them will take a bit longer for the update but I d= oubt that it will be a very big impact. So I support to generate them. Regards, Adolf >> Thanks, and best regards, >> Peter M=C3=BCller >> >>> 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 f= ree space on root. >>> May 13 14:59:33 ipfire4 pakfire: PAKFIRE ERROR: Returncode: 2. Sorry. Ple= ase 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 > wrote: >>>> >>>> Hello, >>>> >>>> Indeed we don=E2=80=99t 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, syst= em 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=C3=BCller > wrote: >>>>> >>>>> Hello *, >>>>> >>>>> to my understanding, we do not need to ship "linux-initrd" if we can ea= sily >>>>> rebuild those on the systems anyway. I would prefer the latter, since t= hat >>>>> keeps the update smaller. >>>>> >>>>> This was also raised somewhere in the community a while ago, but I am u= nable >>>>> to find the correspondent thread at the moment. >>>>> >>>>> How do we proceed here? >>>>> >>>>> Thanks, and best regards, >>>>> Peter M=C3=BCller >>>>> >>>>> >>>>>> https://community.ipfire.org/t/again-with-the-file-system-full-core-16= 9/8186 >>>>>> >>>>>> Signed-off-by: Peter M=C3=BCller >>>>>> --- >>>>>> config/rootfiles/core/169/update.sh | 13 +++++++++++++ >>>>>> 1 file changed, 13 insertions(+) >>>>>> >>>>>> diff --git a/config/rootfiles/core/169/update.sh b/config/rootfiles/co= re/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}-ipfi= re.img /boot/uInit-${KVER}-ipfire >>>>>> + # dont remove initramfs because grub need this to boot. >>>>>> + ;; >>>>>> +esac >>>>>> + >>>>>> # Start services >>>>>> telinit u >>>>>> /etc/init.d/firewall restart --===============7282943782073058078==--