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 168: Hard-code kernel version to 5.15.35 Date: Thu, 12 May 2022 20:00:29 +0000 Message-ID: In-Reply-To: <5aa2b8de-0c1d-4540-fff5-e64dc9b67f1c@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0862403486542202067==" List-Id: --===============0862403486542202067== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=C3=BCller > Hi Peter, >=20 > On 12/05/2022 21:33, Peter M=C3=BCller 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 av= ailable to >> the "testing" channel of upcoming Core Updates. >> >> However, I do not feel sufficiently confident with this patch, which is wh= y 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 wi= th the current stable CU, currently CU167. It will only ever get updated with= the next fully released CU. >=20 > 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 stab= le vm. >=20 > That is how I have been doing it for a long time now. >=20 > Regards, >=20 > Adolf. >=20 >> 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 bef= ore. >> >> Thanks, and best regards, >> Peter M=C3=BCller >> >> >>> 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=C3=BCller 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 >>>> Signed-off-by: Peter M=C3=BCller >>>> --- >>>> 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=3D"5.15.35-ipfire" --regenerate-all --force >>>> case "$(uname -m)" in >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 armv*) >>>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-${= KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >>>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 rm /boot/initramfs-${KVER}-ipfire.img >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.= 15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 rm /boot/initramfs-5.15.35-ipfire.img >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ;; >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 aarch64) >>>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-= ${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-= 5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 # dont remove initramfs because grub need this to bo= ot. >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ;; >>>> esac >>>> --=20 >>>> 2.35.3 >>> --===============0862403486542202067==--