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(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
>>>