Hi Peter,

On 12/05/2022 22:00, Peter Müller wrote:
> 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?
Yes it is VirtualBox.

Regards,
Adolf.
> 
> 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
>>>>