So, everything done was correct, aside from generating the initrd image. The one at /boot/ is used for booting. For crashing, it's used the one from /var/lib/kdump/. You should remove it and reload kdump:
rm /var/lib/kdump/initrd.img-`uname -r` kdump-config reload ** Changed in: makedumpfile (Ubuntu Groovy) Status: New => Invalid ** Changed in: makedumpfile (Ubuntu Focal) Status: New => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1875826 Title: Kdumping on an Ubuntu 20.04 guest with an encrypted root partition drops user to initramfs console Status in Ubuntu on IBM z Systems: New Status in makedumpfile package in Ubuntu: Invalid Status in makedumpfile source package in Focal: Invalid Status in makedumpfile source package in Groovy: Invalid Bug description: Kdump log ---Problem Description--- The expectation for Secure Execution is that users encrypt their root device as part of the setup process. However, Kdumping on an Ubuntu 20.04 guest with an encrypted root partition drops user to initramfs console. When attempted on a non-secure, but encrypted guest, results came out to be the same. ---uname output--- Linux T257KVX 5.4.0-21-generic #25-Ubuntu SMP Sat Mar 28 13:10:00 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = Type: 8562 Model: A00, LT2 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Create a guest with an encrypted root partition. Encryption was done using the process available within the install. virt-install --name ali-kdump-enc --vcpu 2 --memory 4096 --disk size=8,path=/guestimages/ali-kdump-enc.qcow2,driver.iommu=on --network network=default,model=virtio,driver.iommu=on --controller type=virtio- serial,driver.iommu=on --controller type=scsi,driver.iommu=on --memballoon none --boot hd --cdrom http://cdimage.ubuntu.com/ubuntu- server/daily-live/current/focal-live-server-s390x.iso 2. Install linux-crashdump apt install linux-crashdump 3. Proceed through to converting the guest into a secure one, taking extra steps to make the crashkernel large enough to accommodate the swiotlb (I used 1G) sudo genprotimg -r /boot/initrd.img -p parmfile -i /boot/vmlinuz --no-verify -o /boot/secure-linux -V -k T257.crt 4. zipl and reboot into the now secured guest 5. Verify that kdump is ready - kdump-config show - kdump-config status - cat /sys/kernel/kexec_crash_size 6. Trigger a dump sudo sysctl -w kernel.sysrq=1 echo c > /proc/sysrq-trigger However, when this happens, I get the results presented in the kdump- sec-enc.log file. I suspected it was due to the root partition being encrypted and expecting a password on startup (as this happened on an encrypted, non-secure guest, but not on their non-encrypted counterparts), so I attempted to setup a keyfile on a new guest that I created before the installation of linux-crashdump, and conversion into a secure guest using the following set of steps. 1. Create the key file in the unencrypted /boot partition # dd if=/dev/urandom of=/boot/keyfile bs=1024 count=4 2. Set permissions # chmod 0400 /boot/keyfile 3. Add the new file as unlock key to the encrypted volume # cryptsetup -v luksAddKey /dev/vda2 /boot/keyfile Enter any passphrase: Enter your old/existing passphrase here. Expected output: Key slot 0 unlocked. Command successful. 4. Update /etc/crypttab with the line: vda2_crypt UUID=684af433-487f-4c81-b310-81338a49588d /boot/keyfile luks 5. Update /etc/cryptsetup-initramfs/conf-hook to allow enable your keyfile at boot, e.g.: KEYFILE_PATTERN=/boot/keyfile 6. Update initramfs with the following: update-initramfs -u This will bypass the request for a password on boot, however, I still ran into the same errors presented in the log file (kdump-sec- enc.log). -Post a private note with access information to the machine that the bug is occuring on. Guest Log Guest's qemu log file The kernel version for the guest that this was executed on is as follows: xxxxx-kdump-sec-enc:~$ uname -r 5.4.0-26-generic The host is slightly behind, but the bug takes place in context of the guest's starting and stopping Canonical, please advice on how to enable dumping onto an encrypted volume to maintain confidentiality. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1875826/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp