Can you elaborate more on what this patch is supposed to fix?
On 12 May 2022, at 18:41, Peter Müller peter.mueller@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@ipfire.org Signed-off-by: Peter Müller peter.mueller@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
Isn’t specifying the release and “—-regenerate-all” a conflict?
-Michael
case "$(uname -m)" in armv*)
mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfirerm /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-ipfirerm /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