Message ID | db645393-1655-b2c8-f00c-f1cd7ef798bf@ipfire.org |
---|---|
State | Rejected |
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 4KzfGb5ng0z3x1v for <patchwork@web04.haj.ipfire.org>; Thu, 12 May 2022 17:41:43 +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 4KzfGY52YJz454; Thu, 12 May 2022 17:41:41 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4KzfGY3sLpz2yjZ; Thu, 12 May 2022 17:41:41 +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 4KzfGX6GKCz2yWZ for <development@lists.ipfire.org>; Thu, 12 May 2022 17:41:40 +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 4KzfGX0qYzzZ2 for <development@lists.ipfire.org>; Thu, 12 May 2022 17:41:39 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1652377300; 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=g7Q4ghUf8/JXi78Bps8umUi3+8xfb2wdsmrZGL7g3nI=; b=3MHABDP3GbU/xyaKBKhnEfL+3SoZ0bO0c2ROkmaKsa4wy9wHHpSTYbiLUYRlTK7ZHHZnAw QeD28elit/HZzfCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1652377300; 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=g7Q4ghUf8/JXi78Bps8umUi3+8xfb2wdsmrZGL7g3nI=; b=ltw71BzrX1weYP67Tyox3dZc/5NrlZbySDjS9Tiw3keoGDG8B71Oe5RSnR1mCyL7K7VQhL sXNtm76GLO9YtzvAUvpSC49OtL0tHslQ79wpkhSUjhz/3qYF46ByQLFvA/9Iflqj5PUw8n FeE6KfaqIHGPtq/21tdpqUSXLB0JF1BrzcvsaptG8j8QygTGwx7gysjqDCBcL0ytNfwl2B +P9j6G2IHNQFBn/psMuV8AIkvdCJXqydDoiMgnHj0Icz2mez73mbtC0ICIIvhQs5ViW9gU 79YIG/hxYgUfETI1Kr9QxUvaGi5eFf4/Sy/IgtcEiVKwrfsZtC8ezxukMTAvbw== Message-ID: <db645393-1655-b2c8-f00c-f1cd7ef798bf@ipfire.org> Date: Thu, 12 May 2022 17:41:37 +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 168: Hard-code kernel version to 5.15.35 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 168: Hard-code kernel version to 5.15.35
|
|
Commit Message
Peter Müller
May 12, 2022, 5:41 p.m. UTC
On systems that have previously running on testing, kernel 5.15.32 might
still be installed. dracut being called with ${KVER} will then build an
inital ramdisk for the wrong kernel, as 5.15.32 might still be running,
albeit 5.15.35 has been installed due to the Pakfire procedure when
upgrading on testing.
Due to lack of hardware, this patch is untested on ARM.
https://lists.ipfire.org/pipermail/development/2022-May/013433.html
Reported-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
---
config/rootfiles/core/168/update.sh | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Comments
Peter, How do I tell when this makes it into the CU 168 testing build? (The one that Pakfire will pickup & install) I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S Jon > On May 12, 2022, at 12:41 PM, Peter Müller <peter.mueller@ipfire.org> wrote: > > On systems that have previously running on testing, kernel 5.15.32 might > still be installed. dracut being called with ${KVER} will then build an > inital ramdisk for the wrong kernel, as 5.15.32 might still be running, > albeit 5.15.35 has been installed due to the Pakfire procedure when > upgrading on testing. > > Due to lack of hardware, this patch is untested on ARM. > > https://lists.ipfire.org/pipermail/development/2022-May/013433.html > > Reported-by: Stefan Schantl <stefan.schantl@ipfire.org> > Signed-off-by: Peter Müller <peter.mueller@ipfire.org> > --- > config/rootfiles/core/168/update.sh | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh > index d21f648dd..7cc8800b2 100644 > --- a/config/rootfiles/core/168/update.sh > +++ b/config/rootfiles/core/168/update.sh > @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d > chmod -v 640 /etc/sudoers.d/* > > # Rebuild initial ramdisk to apply microcode updates > -dracut --regenerate-all --force > +dracut --kver="5.15.35-ipfire" --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 > + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire > + rm /boot/initramfs-5.15.35-ipfire.img > ;; > aarch64) > - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire > + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire > # dont remove initramfs because grub need this to boot. > ;; > esac > -- > 2.35.3
Hello Jon, thanks for your reply. Usually, I do push fixes to Core Updates straight into "next". However, I do not have permission to push into "master" (Michael or Arne need to do this for me), and as soon as a patch lands there _and_ the nightly builds ran successfully, it is available to the "testing" channel of upcoming Core Updates. However, I do not feel sufficiently confident with this patch, which is why I sent it to the mailing list, and wait for feedback on it before amending. On a general notice: Any IPFire installation that ran Core Update 167 from the "stable" channel before (and has been rebooted at least once ever since) can, to my knowledge, update to Core Update 168 without all the hiccups Adolf and Rob observed. (Please do let me know if this is wrong.) Therefore, you do not necessarily have to wait for this patch to land in "master", presumed your systems ran on Core Update 167 from the "stable" channel before. Thanks, and best regards, Peter Müller > Peter, > > How do I tell when this makes it into the CU 168 testing build? (The one that Pakfire will pickup & install) > > I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S > > > Jon > > >> On May 12, 2022, at 12:41 PM, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> On systems that have previously running on testing, kernel 5.15.32 might >> still be installed. dracut being called with ${KVER} will then build an >> inital ramdisk for the wrong kernel, as 5.15.32 might still be running, >> albeit 5.15.35 has been installed due to the Pakfire procedure when >> upgrading on testing. >> >> Due to lack of hardware, this patch is untested on ARM. >> >> https://lists.ipfire.org/pipermail/development/2022-May/013433.html >> >> Reported-by: Stefan Schantl <stefan.schantl@ipfire.org> >> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >> --- >> config/rootfiles/core/168/update.sh | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh >> index d21f648dd..7cc8800b2 100644 >> --- a/config/rootfiles/core/168/update.sh >> +++ b/config/rootfiles/core/168/update.sh >> @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d >> chmod -v 640 /etc/sudoers.d/* >> >> # Rebuild initial ramdisk to apply microcode updates >> -dracut --regenerate-all --force >> +dracut --kver="5.15.35-ipfire" --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 >> + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >> + rm /boot/initramfs-5.15.35-ipfire.img >> ;; >> aarch64) >> - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >> + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >> # dont remove initramfs because grub need this to boot. >> ;; >> esac >> -- >> 2.35.3 >
Hi Peter, On 12/05/2022 21:33, Peter Müller wrote: > Hello Jon, > > thanks for your reply. > > Usually, I do push fixes to Core Updates straight into "next". However, I do not have > permission to push into "master" (Michael or Arne need to do this for me), and as soon > as a patch lands there _and_ the nightly builds ran successfully, it is available to > the "testing" channel of upcoming Core Updates. > > However, I do not feel sufficiently confident with this patch, which is why I sent it > to the mailing list, and wait for feedback on it before amending. > > On a general notice: Any IPFire installation that ran Core Update 167 from the "stable" > channel before (and has been rebooted at least once ever since) can, to my knowledge, > update to Core Update 168 without all the hiccups Adolf and Rob observed. (Please do > let me know if this is wrong.) > I am afraid that I am going to be disappointing you. I have a running vm with the current stable CU, currently CU167. It will only ever get updated with the next fully released CU. When a Testing release is issued I create a clone of the running stable CU and then do the upgrade and evaluation on that vm. When the CU is released as a full stable one then I delete that Testing vm and update the existing stable vm. That is how I have been doing it for a long time now. Regards, Adolf. > Therefore, you do not necessarily have to wait for this patch to land in "master", > presumed your systems ran on Core Update 167 from the "stable" channel before. > > Thanks, and best regards, > Peter Müller > > >> Peter, >> >> How do I tell when this makes it into the CU 168 testing build? (The one that Pakfire will pickup & install) >> >> I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S >> >> >> Jon >> >> >>> On May 12, 2022, at 12:41 PM, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> On systems that have previously running on testing, kernel 5.15.32 might >>> still be installed. dracut being called with ${KVER} will then build an >>> inital ramdisk for the wrong kernel, as 5.15.32 might still be running, >>> albeit 5.15.35 has been installed due to the Pakfire procedure when >>> upgrading on testing. >>> >>> Due to lack of hardware, this patch is untested on ARM. >>> >>> https://lists.ipfire.org/pipermail/development/2022-May/013433.html >>> >>> Reported-by: Stefan Schantl <stefan.schantl@ipfire.org> >>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>> --- >>> config/rootfiles/core/168/update.sh | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh >>> index d21f648dd..7cc8800b2 100644 >>> --- a/config/rootfiles/core/168/update.sh >>> +++ b/config/rootfiles/core/168/update.sh >>> @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d >>> chmod -v 640 /etc/sudoers.d/* >>> >>> # Rebuild initial ramdisk to apply microcode updates >>> -dracut --regenerate-all --force >>> +dracut --kver="5.15.35-ipfire" --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 >>> + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>> + rm /boot/initramfs-5.15.35-ipfire.img >>> ;; >>> aarch64) >>> - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >>> + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>> # dont remove initramfs because grub need this to boot. >>> ;; >>> esac >>> -- >>> 2.35.3 >>
Hello Adolf, thanks for your reply. This changes things then, and this patch can be dropped. As for your issue, the only thing I can think of so far is the linux-firmware update. I will go through the delta and look for anything suspicious, since I am not going to be able to do some VM-based testing myself before next week. Which VM setup are you running on? VirtualBox? Thanks, and best regards, Peter Müller > Hi Peter, > > On 12/05/2022 21:33, Peter Müller wrote: >> Hello Jon, >> >> thanks for your reply. >> >> Usually, I do push fixes to Core Updates straight into "next". However, I do not have >> permission to push into "master" (Michael or Arne need to do this for me), and as soon >> as a patch lands there _and_ the nightly builds ran successfully, it is available to >> the "testing" channel of upcoming Core Updates. >> >> However, I do not feel sufficiently confident with this patch, which is why I sent it >> to the mailing list, and wait for feedback on it before amending. >> >> On a general notice: Any IPFire installation that ran Core Update 167 from the "stable" >> channel before (and has been rebooted at least once ever since) can, to my knowledge, >> update to Core Update 168 without all the hiccups Adolf and Rob observed. (Please do >> let me know if this is wrong.) >> > I am afraid that I am going to be disappointing you. I have a running vm with the current stable CU, currently CU167. It will only ever get updated with the next fully released CU. > > When a Testing release is issued I create a clone of the running stable CU and then do the upgrade and evaluation on that vm. When the CU is released as a full stable one then I delete that Testing vm and update the existing stable vm. > > That is how I have been doing it for a long time now. > > Regards, > > Adolf. > >> Therefore, you do not necessarily have to wait for this patch to land in "master", >> presumed your systems ran on Core Update 167 from the "stable" channel before. >> >> Thanks, and best regards, >> Peter Müller >> >> >>> Peter, >>> >>> How do I tell when this makes it into the CU 168 testing build? (The one that Pakfire will pickup & install) >>> >>> I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S >>> >>> >>> Jon >>> >>> >>>> On May 12, 2022, at 12:41 PM, Peter Müller <peter.mueller@ipfire.org> wrote: >>>> >>>> On systems that have previously running on testing, kernel 5.15.32 might >>>> still be installed. dracut being called with ${KVER} will then build an >>>> inital ramdisk for the wrong kernel, as 5.15.32 might still be running, >>>> albeit 5.15.35 has been installed due to the Pakfire procedure when >>>> upgrading on testing. >>>> >>>> Due to lack of hardware, this patch is untested on ARM. >>>> >>>> https://lists.ipfire.org/pipermail/development/2022-May/013433.html >>>> >>>> Reported-by: Stefan Schantl <stefan.schantl@ipfire.org> >>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>> --- >>>> config/rootfiles/core/168/update.sh | 8 ++++---- >>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh >>>> index d21f648dd..7cc8800b2 100644 >>>> --- a/config/rootfiles/core/168/update.sh >>>> +++ b/config/rootfiles/core/168/update.sh >>>> @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d >>>> chmod -v 640 /etc/sudoers.d/* >>>> >>>> # Rebuild initial ramdisk to apply microcode updates >>>> -dracut --regenerate-all --force >>>> +dracut --kver="5.15.35-ipfire" --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 >>>> + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>>> + rm /boot/initramfs-5.15.35-ipfire.img >>>> ;; >>>> aarch64) >>>> - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >>>> + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>>> # dont remove initramfs because grub need this to boot. >>>> ;; >>>> esac >>>> -- >>>> 2.35.3 >>>
Hi Peter, On 12/05/2022 22:00, Peter Müller wrote: > Hello Adolf, > > thanks for your reply. > > This changes things then, and this patch can be dropped. > > As for your issue, the only thing I can think of so far is the linux-firmware update. > I will go through the delta and look for anything suspicious, since I am not going to > be able to do some VM-based testing myself before next week. > > Which VM setup are you running on? VirtualBox? Yes it is VirtualBox. Regards, Adolf. > > Thanks, and best regards, > Peter Müller > >> Hi Peter, >> >> On 12/05/2022 21:33, Peter Müller wrote: >>> Hello Jon, >>> >>> thanks for your reply. >>> >>> Usually, I do push fixes to Core Updates straight into "next". However, I do not have >>> permission to push into "master" (Michael or Arne need to do this for me), and as soon >>> as a patch lands there _and_ the nightly builds ran successfully, it is available to >>> the "testing" channel of upcoming Core Updates. >>> >>> However, I do not feel sufficiently confident with this patch, which is why I sent it >>> to the mailing list, and wait for feedback on it before amending. >>> >>> On a general notice: Any IPFire installation that ran Core Update 167 from the "stable" >>> channel before (and has been rebooted at least once ever since) can, to my knowledge, >>> update to Core Update 168 without all the hiccups Adolf and Rob observed. (Please do >>> let me know if this is wrong.) >>> >> I am afraid that I am going to be disappointing you. I have a running vm with the current stable CU, currently CU167. It will only ever get updated with the next fully released CU. >> >> When a Testing release is issued I create a clone of the running stable CU and then do the upgrade and evaluation on that vm. When the CU is released as a full stable one then I delete that Testing vm and update the existing stable vm. >> >> That is how I have been doing it for a long time now. >> >> Regards, >> >> Adolf. >> >>> Therefore, you do not necessarily have to wait for this patch to land in "master", >>> presumed your systems ran on Core Update 167 from the "stable" channel before. >>> >>> Thanks, and best regards, >>> Peter Müller >>> >>> >>>> Peter, >>>> >>>> How do I tell when this makes it into the CU 168 testing build? (The one that Pakfire will pickup & install) >>>> >>>> I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S >>>> >>>> >>>> Jon >>>> >>>> >>>>> On May 12, 2022, at 12:41 PM, Peter Müller <peter.mueller@ipfire.org> wrote: >>>>> >>>>> On systems that have previously running on testing, kernel 5.15.32 might >>>>> still be installed. dracut being called with ${KVER} will then build an >>>>> inital ramdisk for the wrong kernel, as 5.15.32 might still be running, >>>>> albeit 5.15.35 has been installed due to the Pakfire procedure when >>>>> upgrading on testing. >>>>> >>>>> Due to lack of hardware, this patch is untested on ARM. >>>>> >>>>> https://lists.ipfire.org/pipermail/development/2022-May/013433.html >>>>> >>>>> Reported-by: Stefan Schantl <stefan.schantl@ipfire.org> >>>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>>> --- >>>>> config/rootfiles/core/168/update.sh | 8 ++++---- >>>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh >>>>> index d21f648dd..7cc8800b2 100644 >>>>> --- a/config/rootfiles/core/168/update.sh >>>>> +++ b/config/rootfiles/core/168/update.sh >>>>> @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d >>>>> chmod -v 640 /etc/sudoers.d/* >>>>> >>>>> # Rebuild initial ramdisk to apply microcode updates >>>>> -dracut --regenerate-all --force >>>>> +dracut --kver="5.15.35-ipfire" --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 >>>>> + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>>>> + rm /boot/initramfs-5.15.35-ipfire.img >>>>> ;; >>>>> aarch64) >>>>> - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >>>>> + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>>>> # dont remove initramfs because grub need this to boot. >>>>> ;; >>>>> esac >>>>> -- >>>>> 2.35.3 >>>>
Can you elaborate more on what this patch is supposed to fix? > On 12 May 2022, at 18:41, Peter Müller <peter.mueller@ipfire.org> wrote: > > On systems that have previously running on testing, kernel 5.15.32 might > still be installed. dracut being called with ${KVER} will then build an > inital ramdisk for the wrong kernel, as 5.15.32 might still be running, > albeit 5.15.35 has been installed due to the Pakfire procedure when > upgrading on testing. > > Due to lack of hardware, this patch is untested on ARM. > > https://lists.ipfire.org/pipermail/development/2022-May/013433.html > > Reported-by: Stefan Schantl <stefan.schantl@ipfire.org> > Signed-off-by: Peter Müller <peter.mueller@ipfire.org> > --- > config/rootfiles/core/168/update.sh | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh > index d21f648dd..7cc8800b2 100644 > --- a/config/rootfiles/core/168/update.sh > +++ b/config/rootfiles/core/168/update.sh > @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d > chmod -v 640 /etc/sudoers.d/* > > # Rebuild initial ramdisk to apply microcode updates > -dracut --regenerate-all --force > +dracut --kver="5.15.35-ipfire" --regenerate-all --force Isn’t specifying the release and “—-regenerate-all” a conflict? -Michael > 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 > + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire > + rm /boot/initramfs-5.15.35-ipfire.img > ;; > aarch64) > - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire > + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire > # dont remove initramfs because grub need this to boot. > ;; > esac > -- > 2.35.3
diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh index d21f648dd..7cc8800b2 100644 --- a/config/rootfiles/core/168/update.sh +++ b/config/rootfiles/core/168/update.sh @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d chmod -v 640 /etc/sudoers.d/* # Rebuild initial ramdisk to apply microcode updates -dracut --regenerate-all --force +dracut --kver="5.15.35-ipfire" --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 + mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire + rm /boot/initramfs-5.15.35-ipfire.img ;; aarch64) - mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire + mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire # dont remove initramfs because grub need this to boot. ;; esac