Message ID | 3e57aa59-ee6f-bff4-68b4-0ac078d76cee@ipfire.org |
---|---|
State | Superseded |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4LdllV71d2z3xqm for <patchwork@web04.haj.ipfire.org>; Thu, 7 Jul 2022 05:46:30 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4LdllS3LcZzyC; Thu, 7 Jul 2022 05:46:28 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4LdllS2KZcz2y0C; Thu, 7 Jul 2022 05:46:28 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4LdllR30Xmz2xPJ for <development@lists.ipfire.org>; Thu, 7 Jul 2022 05:46:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4LdllN1qJPzbk for <development@lists.ipfire.org>; Thu, 7 Jul 2022 05:46:23 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1657172787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=U5NqNh05FBgQiOz0vkSAOeMGlsJH3XRDRyNAqwSTVkU=; b=xEoXzNQq4fW5a+eySxqlz6I69m8zs22W0SvP69+tiT9++z5NVI9buRMY9Vkvn3sa4pMWNx MU+D+S34Y1G8rsDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1657172787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=U5NqNh05FBgQiOz0vkSAOeMGlsJH3XRDRyNAqwSTVkU=; b=IoGx+JTrLFvx+tzn1uSsMAcY5lYY3Gnloznyti1pfkQNjtlYblplH8mP32Lbo8hWw0zCzC FrL0ubnextTOpOkc98lbqk5uVdaVQPfA5Y72N7dqT+M+7xstlHItp7PLYZLr0lAGWO69/f COhjb1jTTMzakXO4NEJlbGHWJLahzfpnR5lQI4liw+KmOWPLmdbsvhtDtpXJjBSJP2zHJx xwjop6KfeGRku+CgBfjYfsijGkScBmlioS1fv4F9T1N8cI4NNTjpzo6UtaXOQf78klVSGF r28BDL38LihjSF14VqY9qmSkqjGKReaEUE2oWTWAdp1T3KXr9wNp8pIXDCA5lg== Message-ID: <3e57aa59-ee6f-bff4-68b4-0ac078d76cee@ipfire.org> Date: Thu, 7 Jul 2022 05:46:18 +0000 MIME-Version: 1.0 Content-Language: en-US To: "IPFire: Development" <development@lists.ipfire.org> From: =?utf-8?q?Peter_M=C3=BCller?= <peter.mueller@ipfire.org> Subject: [PATCH] Core Update 169: Regenerate initrds and save space on ARM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
Core Update 169: Regenerate initrds and save space on ARM
|
|
Commit Message
Peter Müller
July 7, 2022, 5:46 a.m. UTC
https://community.ipfire.org/t/again-with-the-file-system-full-core-169/8186
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
---
config/rootfiles/core/169/update.sh | 13 +++++++++++++
1 file changed, 13 insertions(+)
Comments
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 <peter.mueller@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
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@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 >> >> Signed-off-by: Peter Müller <peter.mueller@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
Hello Michael, thanks for your reply. > 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) So I guess the first newly introduced line ("dracut --regenerate-all --force") of my patch is obsolete then, as the initrds are already there - we just need the directives for ARM. To my understanding, if dracut fails due to space/memory issues, the upgrade would have failed either way. 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? Thanks, and best regards, Peter Müller > > 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@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 >>> >>> Signed-off-by: Peter Müller <peter.mueller@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 >
Hello, > On 7 Jul 2022, at 15:30, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Michael, > > thanks for your reply. > >> 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) > > So I guess the first newly introduced line ("dracut --regenerate-all --force") of > my patch is obsolete then, as the initrds are already there - we just need the directives > for ARM. Those should be shipped, too. Adding more size to the updater when shipping the same stuff multiple times. > To my understanding, if dracut fails due to space/memory issues, the upgrade would have > failed either way. My point was that extracting the update would consume less memory. Disk space constraints still apply unless there is not enough temporary space. > 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? We should either ship everything, or generate everything. I don’t think a mix is good idea. > Thanks, and best regards, > Peter Müller > >> 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@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 >>>> >>>> Signed-off-by: Peter Müller <peter.mueller@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
Hello Michael, > Hello, > >> On 7 Jul 2022, at 15:30, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> Hello Michael, >> >> thanks for your reply. >> >>> 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) >> >> So I guess the first newly introduced line ("dracut --regenerate-all --force") of >> my patch is obsolete then, as the initrds are already there - we just need the directives >> for ARM. > > Those should be shipped, too. Adding more size to the updater when shipping the same stuff multiple times. > >> To my understanding, if dracut fails due to space/memory issues, the upgrade would have >> failed either way. > > My point was that extracting the update would consume less memory. Disk space constraints still apply unless there is not enough temporary space. > >> 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? > > We should either ship everything, or generate everything. I don’t think a mix is good idea. agreed. Then, this boils down to an "rm" statement on 32-bit ARM, and I will omit regenerating 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üller > >> Thanks, and best regards, >> Peter Müller >> >>> 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@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 >>>>> >>>>> Signed-off-by: Peter Müller <peter.mueller@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 >
Hello, > On 7 Jul 2022, at 15:49, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Michael, > >> Hello, >>> On 7 Jul 2022, at 15:30, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> Hello Michael, >>> >>> thanks for your reply. >>> >>>> 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) >>> >>> So I guess the first newly introduced line ("dracut --regenerate-all --force") of >>> my patch is obsolete then, as the initrds are already there - we just need the directives >>> for ARM. >> Those should be shipped, too. Adding more size to the updater when shipping the same stuff multiple times. >>> To my understanding, if dracut fails due to space/memory issues, the upgrade would have >>> failed either way. >> My point was that extracting the update would consume less memory. Disk space constraints still apply unless there is not enough temporary space. >>> 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? >> We should either ship everything, or generate everything. I don’t think a mix is good idea. > > agreed. > > Then, this boils down to an "rm" statement on 32-bit ARM, and I will omit regenerating > 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... We probably don’t want this in next. That already has c170. > > Thanks, and best regards, > Peter Müller > >>> Thanks, and best regards, >>> Peter Müller >>> >>>> 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@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 >>>>>> >>>>>> Signed-off-by: Peter Müller <peter.mueller@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
Hello Michael, > Hello, > >> On 7 Jul 2022, at 15:49, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> Hello Michael, >> >>> Hello, >>>> On 7 Jul 2022, at 15:30, Peter Müller <peter.mueller@ipfire.org> wrote: >>>> >>>> Hello Michael, >>>> >>>> thanks for your reply. >>>> >>>>> 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) >>>> >>>> So I guess the first newly introduced line ("dracut --regenerate-all --force") of >>>> my patch is obsolete then, as the initrds are already there - we just need the directives >>>> for ARM. >>> Those should be shipped, too. Adding more size to the updater when shipping the same stuff multiple times. >>>> To my understanding, if dracut fails due to space/memory issues, the upgrade would have >>>> failed either way. >>> My point was that extracting the update would consume less memory. Disk space constraints still apply unless there is not enough temporary space. >>>> 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? >>> We should either ship everything, or generate everything. I don’t think a mix is good idea. >> >> agreed. >> >> Then, this boils down to an "rm" statement on 32-bit ARM, and I will omit regenerating >> 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... > > We probably don’t want this in next. That already has c170. true, but I cannot push to "master". Is it feasible for you to cherry-pick 5ead33d796b9537bddbc4e2d5d27029de4df001a? Thanks, and best regards, Peter Müller > >> >> Thanks, and best regards, >> Peter Müller >> >>>> Thanks, and best regards, >>>> Peter Müller >>>> >>>>> 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@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 >>>>>>> >>>>>>> Signed-off-by: Peter Müller <peter.mueller@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 >
Please just send a patch to the list :) > On 7 Jul 2022, at 15:54, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Michael, > >> Hello, >>> On 7 Jul 2022, at 15:49, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> Hello Michael, >>> >>>> Hello, >>>>> On 7 Jul 2022, at 15:30, Peter Müller <peter.mueller@ipfire.org> wrote: >>>>> >>>>> Hello Michael, >>>>> >>>>> thanks for your reply. >>>>> >>>>>> 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) >>>>> >>>>> So I guess the first newly introduced line ("dracut --regenerate-all --force") of >>>>> my patch is obsolete then, as the initrds are already there - we just need the directives >>>>> for ARM. >>>> Those should be shipped, too. Adding more size to the updater when shipping the same stuff multiple times. >>>>> To my understanding, if dracut fails due to space/memory issues, the upgrade would have >>>>> failed either way. >>>> My point was that extracting the update would consume less memory. Disk space constraints still apply unless there is not enough temporary space. >>>>> 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? >>>> We should either ship everything, or generate everything. I don’t think a mix is good idea. >>> >>> agreed. >>> >>> Then, this boils down to an "rm" statement on 32-bit ARM, and I will omit regenerating >>> 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... >> We probably don’t want this in next. That already has c170. > > true, but I cannot push to "master". Is it feasible for you to cherry-pick 5ead33d796b9537bddbc4e2d5d27029de4df001a? > > Thanks, and best regards, > Peter Müller >>> >>> Thanks, and best regards, >>> Peter Müller >>> >>>>> Thanks, and best regards, >>>>> Peter Müller >>>>> >>>>>> 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@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 >>>>>>>> >>>>>>>> Signed-off-by: Peter Müller <peter.mueller@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
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? 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. Here is my recent oops: ``` Message from syslogd@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@ipfire.org <mailto:michael.tremer@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@ipfire.org <mailto:peter.mueller@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@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 >
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@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@ipfire.org <mailto:michael.tremer@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@ipfire.org <mailto:peter.mueller@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@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 >> > >
Hello, > On 10 Jul 2022, at 12:13, Peter Müller <peter.mueller@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? > > Thanks, and best regards, > Peter Müller > >> >> Here is my recent oops: >> >> ``` >> Message from syslogd@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@ipfire.org<mailto:michael.tremer@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@ipfire.org<mailto:peter.mueller@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@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
Hi All, On 12/07/2022 12:35, Michael Tremer wrote: > Hello, > >> On 10 Jul 2022, at 12:13, Peter Müller <peter.mueller@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@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@ipfire.org<mailto:michael.tremer@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@ipfire.org<mailto:peter.mueller@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@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
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