Bug 1782026

Summary: Qemu -KVM: BOOT_IMAGE not populated on kernel command line for s390x
Product: Red Hat Enterprise Linux 8 Reporter: Prashanth Sundararaman <psundara>
Component: s390utilsAssignee: Dan Horák <dhorak>
Status: CLOSED WONTFIX QA Contact: Vilém Maršík <vmarsik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.1CC: dgilmore, dhorak, dzheng, javierm, jhlavac, juzhang, qzhang, rbalakri, rvr, smitterl, thuth, virt-maint
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.2   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-11 07:30:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Prashanth Sundararaman 2019-12-11 01:59:37 UTC
Description of problem:
On booting a Redhat coreos qemu VM using the coreos-assembler, found that BOOT_IMAGE is not populated in the kernel command line.

Version-Release number of selected component (if applicable):
8.1

How reproducible:
100%

Steps to Reproduce:
Build a Redhat Coreos image using the redhat coreos-assembler and the redhat coreos-config and use `coreos-assembler run` to create a qemu VM.

Actual results:
Kernel command line does not have boot image populated:

[core@coreos ~]$ cat /proc/cmdline
options $ignition_firstboot rhcos.root=crypt_rootfs console=ttysclp0 ignition.platform.id=qemu rd.luks.options=discard ostree=/ostree/boot.1/rhcos/cec59ded8cab77eedca7f74c9f191e21c951a60f5fc1aca8bf9884e7d94c6bb5/0 ignition.firstboot rd.neednet=1 ip=dhcp
[core@coreos ~]$ 


Expected results:
Expect BOOT_IMAGE to be populated in the kernel command line

Additional info:

This the qemu command used to create the VM:
["qemu-system-s390x" "-machine" "s390-ccw-virtio,accel=kvm" "-cpu" "host" "-m" "2048" "-smp" "1" "-uuid" "2d14be63-0ecf-4072-a5b2-120969d320c8" "-display" "none" "-chardev" "file,id=log,path=tmp/kola/2d14be63-0ecf-4072-a5b2-120969d320c8/console.txt" "-serial" "chardev:log" "-object" "rng-random,filename=/dev/urandom,id=rng0" "-device" "virtio-rng-ccw,rng=rng0" "-add-fd" "fd=3,set=1" "-drive" "if=none,id=d3,format=qcow2,file=/dev/fdset/1,auto-read-only=off" "-device" "virtio-blk-ccw,drive=d3,serial=primary-disk" "-netdev" "user,id=eth0,hostfwd=tcp:127.0.0.1:0-:22" "-device" "virtio-net-ccw,netdev=eth0"]

Comment 1 Dan Horák 2019-12-11 08:19:03 UTC
BOOT_IMAGE is set by the zipl bootloader (https://github.com/ibm-s390-tools/s390-tools/tree/master/zipl/boot) for z/VM guests and LPARs, but seems it's not set by the qemu/kvm bootloader (https://github.com/qemu/qemu/tree/master/pc-bios/s390-ccw). BOOT_IMAGE is also set by other bootloaders on non-s390x arches.

Comment 2 smitterl 2019-12-12 15:04:40 UTC
Reproduce with:
qemu-kvm-2.12.0-92.module+el8.2.0+5014+5115d99d.s390x
guest kernel 4.18.0-160.el8.s390x

Precondition:
VM only 1 kernel version available

Steps:
1. virsh start --console vm
2. login
3. cat /proc/cmdline|grep BOOT_IMAGE

Actual result: output empty
Expected result: output not-empty
(on LPAR output contains BOOT_IMAGE=0 under same preconditions)

Comment 3 Thomas Huth 2019-12-13 15:52:31 UTC
Hi Prashanth, I've now had a first look at this issue, and indeed, the s390-ccw bios from QEMU does not set this parameter yet. However, it looks like it is going to bit hairy to get this done right, since there are still some "unarchitected" code parts of the zipl stage3 bootloader involved in the boot flow, too, so let me ask a question first to get things really right:

For what purpose do you exactly need the BOOT_IMAGE parameter? Do you expect it to behave the same way as grub2 is using it on x86 (where it contains the filename of the kernel)? Or do you rather expect it to behave the same way as zipl provides it on an s390x LPAR or z/VM system (i.e. where it just contains the number of the boot entry)? Also, is this rather an important feature for you, or rather just cosmetics (i.e. please also set the "Severity" field of this BZ)?

Comment 4 Prashanth Sundararaman 2019-12-13 16:23:46 UTC
Hi Thomas,

I found this bug when running a fips test on an rhcos qemu VM that i had provisioned. The problem is, dracut uses the BOOT_IMAGE parameter to find the path to the kernel and also the hmac to verify kernel integrity. https://github.com/dracutdevs/dracut/blob/cc6792a01e0e86e9c7d39d57087553288d664bbd/modules.d/01fips/fips.sh#L115. 

After finding this error and searching BZs i found this topic related to BOOT_IMAGE https://bugzilla.redhat.com/show_bug.cgi?id=1415032 which also has a fix for finding the boot image on s390x because it is just a number. But the problem is rhcos uses ostree , so the boot image is not in the default /boot/.vmlinuz..hmac path. That is also mentioned in the bug that if the image is elsewhere this wouldn't work for s390x.

That being said - to answer your question - I don't think this is highly critical, but it would be good to fix this. 
As for a fix , that is a good question because even if we populate it with the boot record number, there will have to be another step of translating that to the path and maybe that change would be in dracut - i'm not sure. But it would be nice to have it consistent to how z/VM, LPARs provide it because this problem has to be fixed there anyway. Having it as a path would just fix it for qemu , but not the others anyway - so i would rather we be consistent.

Thanks.

Comment 5 Thomas Huth 2019-12-16 16:08:00 UTC
Ok, after suggesting a "quick-n-dirty" fix for the s390-ccw bios for KVM guests ( see https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg02999.html ), I've got the feedback that this can not be solved in a clean way in the s390-ccw bios ( see https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03046.html ).
This issue should be fixed at the zipl level instead, e.g. in a way where zipl writes the BOOT_IMAGE to disk already when the Linux userspace "zipl" program gets run - that way, additional information that might be required here (like the kernel file name on the boot partition) could maybe be added to the parameter, too. Thus, I'm moving this BZ now to the "s390utils" component since zipl is part of that package.

Comment 6 Dan Horák 2019-12-17 09:47:31 UTC
moved to s390-tools tracker ...

Comment 7 Thomas Huth 2019-12-17 12:54:57 UTC
Prashanth, if you want the BOOT_IMAGE parameter to contain e.g. the kernel file name on s390x, too, could you please add that information to the github issue that Dan just opened? Thanks!

Comment 8 Prashanth Sundararaman 2019-12-17 15:10:41 UTC
Hi Thomas - updated the upstream github issue with my comments. Thanks.

Comment 11 RHEL Program Management 2021-06-11 07:30:43 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.