From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] Core Update 169: Regenerate initrds and save space on ARM Date: Thu, 07 Jul 2022 13:49:15 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1935684484032196394==" List-Id: --===============1935684484032196394== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > Hello, >=20 >> On 7 Jul 2022, at 15:30, Peter M=C3=BCller wr= ote: >> >> Hello Michael, >> >> thanks for your reply. >> >>> 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, syste= m being rebooted too early) >> >> So I guess the first newly introduced line ("dracut --regenerate-all --for= ce") of >> my patch is obsolete then, as the initrds are already there - we just need= the directives >> for ARM. >=20 > Those should be shipped, too. Adding more size to the updater when shipping= the same stuff multiple times. >=20 >> To my understanding, if dracut fails due to space/memory issues, the upgra= de would have >> failed either way. >=20 > My point was that extracting the update would consume less memory. Disk spa= ce constraints still apply unless there is not enough temporary space. >=20 >> 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? >=20 > We should either ship everything, or generate everything. I don=E2=80=99t t= hink a mix is good idea. agreed. Then, this boils down to an "rm" statement on 32-bit ARM, and I will omit reg= enerating 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=C3=BCller >=20 >> Thanks, and best regards, >> Peter M=C3=BCller >> >>> I do not really have much of a preference. The only thing I want to say i= s 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 eas= ily >>>> rebuild those on the systems anyway. I would prefer the latter, since th= at >>>> keeps the update smaller. >>>> >>>> This was also raised somewhere in the community a while ago, but I am un= able >>>> 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-169= /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/cor= e/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}-ipfir= e.img /boot/uInit-${KVER}-ipfire >>>>> + # dont remove initramfs because grub need this to boot. >>>>> + ;; >>>>> +esac >>>>> + >>>>> # Start services >>>>> telinit u >>>>> /etc/init.d/firewall restart >=20 --===============1935684484032196394==--