Re: [PATCH] Core Update 168: Hard-code kernel version to 5.15.35

[Adolf Belka <adolf.belka@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]

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(a)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(a)ipfire.org>
>>> Signed-off-by: Peter Müller <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="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
>>