From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] Core Update 168: Hard-code kernel version to 5.15.35
Date: Thu, 12 May 2022 19:33:59 +0000
Message-ID: <3154bd2f-76b2-16dc-90cb-823e18495a3e@ipfire.org>
In-Reply-To: <3FDE9848-6782-4CBF-934A-B158C4C3EBF1@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0014269848442140310=="
List-Id: <development.lists.ipfire.org>

--===============0014269848442140310==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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), an=
d as soon
as a patch lands there _and_ the nightly builds ran successfully, it is avail=
able 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 th=
e "stable"
channel before (and has been rebooted at least once ever since) can, to my kn=
owledge,
update to Core Update 168 without all the hiccups Adolf and Rob observed. (Pl=
ease do
let me know if this is wrong.)

Therefore, you do not necessarily have to wait for this patch to land in "mas=
ter",
presumed your systems ran on Core Update 167 from the "stable" channel before.

Thanks, and best regards,
Peter M=C3=BCller


> Peter,
>=20
> How do I tell when this makes it into the CU 168 testing build?  (The one t=
hat Pakfire will pickup & install)
>=20
> I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S
>=20
>=20
> Jon
>=20
>=20
>> On May 12, 2022, at 12:41 PM, Peter M=C3=BCller <peter.mueller(a)ipfire.or=
g> 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(a)ipfire.org>
>> Signed-off-by: Peter M=C3=BCller <peter.mueller(a)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/1=
68/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
>>          armv*)
>> -                mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-${KV=
ER}-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
>> --=20
>> 2.35.3
>=20

--===============0014269848442140310==--