From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adolf Belka <adolf.belka@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 21:53:48 +0200
Message-ID: <5aa2b8de-0c1d-4540-fff5-e64dc9b67f1c@ipfire.org>
In-Reply-To: <3154bd2f-76b2-16dc-90cb-823e18495a3e@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5025102485701165835=="
List-Id: <development.lists.ipfire.org>

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

Hi Peter,

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 d=
o 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 ava=
ilable 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 t=
he next fully released CU.

When a Testing release is issued I create a clone of the running stable CU an=
d 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 "m=
aster",
> presumed your systems ran on Core Update 167 from the "stable" channel befo=
re.
>
> 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 t=
hat 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 <peter.mueller(a)ipfire.o=
rg> 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/=
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-${KVE=
R}-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-${K=
VER}-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.1=
5.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
>>

--===============5025102485701165835==--