On 14/11/22 6:56 pm, Philipp Rudo wrote:
Hi Hari,
it totally makes sense to have some functionality like this. What I'm
not sure about is if it would make more sense to include it into
60-kdump.install. With that the patch would reduce to something like
this
--- a/60-kdump.install
+++ b/60-kdump.install
@@ -22,6 +22,8 @@ else
KDUMP_INITRD="initramfs-${KERNEL_VERSION}kdump.img"
fi
+KDUMP_INITRD_BAK=".initramfs-${KERNEL_VERSION}.img.default"
+
ret=0
case "$COMMAND" in
add)
@@ -29,7 +31,8 @@ case "$COMMAND" in
# and managed by kdump service
;;
remove)
- rm -f -- "$KDUMP_INITRD_DIR_ABS/$KDUMP_INITRD"
+ rm -f -- "$KDUMP_INITRD_DIR_ABS/$KDUMP_INITRD" || exit
+ rm -f -- "$KDUMP_INITRD_DIR_ABS/$KDUMP_INITRD_BAK"
ret=$?
;;
esac
Does that work for you? Or is there a reason KDUMP_INITRD_DIR_ABS must
not be anything else than /boot?
Yeah. I don't see fadump supported in any other case than /boot
One more thing I noticed was the handling of INITRD_CHECKSUM_LOCATION.
First I thought this should be removed as well. But then I noticed that
there is only one instance for the last kernel which gets overwritten
when a new kernel is installed. For example assume the following
1. install kernel1
2. boot kernel1 and enable fadump
3. install kernel2
4. boot kernel2 and enable fadump
5. boot kernel1 and disable fadump
In this scenario step 4 will create a backup initrd for kernel2 and
overwrites INITRD_CHECKSUM_LOCATION without removing the backup initrd
for kernel1. Consequently step 5 will try to restore the backup initrd
for kernel1 but will fail as the checksum no longer matches. Is that
correct? Or am I missing something?
If I'm correct I think it would make sense to make
INITRD_CHECKSUM_LOCATION version specific and remove it together with
the backup initrd.
Right. This sequence breaks the restore logic for older kernel version
Will repost fixing this..
Coiby, I will follow-up on this . Meanwhile, can you consider picking
patch#2
Thanks
Hari