RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1782026 - Qemu -KVM: BOOT_IMAGE not populated on kernel command line for s390x
Summary: Qemu -KVM: BOOT_IMAGE not populated on kernel command line for s390x
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: s390utils
Version: 8.1
Hardware: s390x
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.2
Assignee: Dan Horák
QA Contact: Vilém Maršík
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-11 01:59 UTC by Prashanth Sundararaman
Modified: 2021-06-11 07:30 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-11 07:30:43 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ibm-s390-tools s390-tools issues 78 0 None open set BOOT_IMAGE in bootmap 2021-01-20 00:34:00 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.