Hello, > On 10 Jul 2022, at 12:13, Peter Müller 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? > > 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 > 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 > 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 >>>>> --- >>>>> 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