Bug 1746399

Summary: [s390x] Composer, qcow2 image: No zIPL section in IPL2 record.
Product: Red Hat Enterprise Linux 8 Reporter: Alexander Todorov <atodorov>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.1CC: cohuck, dzheng, knoel, smitterl, thuth, wchadwic
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-01-29 07:43:47 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:
Bug Depends On:    
Bug Blocks: 1673744, 1746404    
Attachments:
Description Flags
program.log
none
anaconda.log
none
lvm.log
none
packaging.log
none
storage.log none

Description Alexander Todorov 2019-08-28 11:20:07 UTC 
Description of problem:

I was able to build a qcow2 image with composer-cli on s390x but it fails to boot with qemu-kvm. What I see is:


:: [ 07:08:34 ] :: [  BEGIN   ] :: Running '/usr/libexec/qemu-kvm -m 2048 -boot c -hda 9870594b-6e1a-4d09-98f3-00dafc490f6b-disk.qcow2 -nographic                            -net user,id=nic0,hostfwd=tcp::2222-:22 -net nic &'
STDERR: qemu-kvm: warning: 'apqci' requires 'ap'.
STDERR: qemu-kvm: warning: 'apft' requires 'ap'.
STDOUT: LOADPARM=[        ]
STDOUT: Using virtio-blk.
STDOUT: Using guessed DASD geometry.
STDOUT: Using ECKD scheme (block size  4096), CDL
STDOUT: 
STDOUT: ! No zIPL section in IPL2 record. !


Version-Release number of selected component (if applicable):
lorax-composer-28.14.30-1.el8.s390x

How reproducible:
always

Steps to Reproduce:
1. composer-cli compose start example-http-server qcow2 on an s390x system
2.
3.
Comment 4 Brian Lane 2019-08-28 16:14:25 UTC 
Please attach the anaconda logs from the compose, I'm especially interested in program.log to see what the bootloader install looks like.
Comment 6 Cornelia Huck 2019-09-02 07:16:58 UTC 
Looking at

STDOUT: LOADPARM=[        ]
STDOUT: Using virtio-blk.
STDOUT: Using guessed DASD geometry.
STDOUT: Using ECKD scheme (block size  4096), CDL
STDOUT: 
STDOUT: ! No zIPL section in IPL2 record. !

this smells like a missing zipl invocation somewhere.

Is the code building the qcow2 image calling zipl after the kernel has been installed?
Comment 7 Thomas Huth 2019-09-02 10:04:30 UTC 
FWIW, I've reproduce the problem (with "composer-cli compose start example-atlas qcow2" as described in https://bugzilla.redhat.com/show_bug.cgi?id=1746404#c7 ) and had a closer look at the produced image. Indeed, zipl is missing here - there is no /etc/zipl.conf installed in the image. I had to add that file manually, adjust /boot/loader/entries/*.conf, re-create the initrd with dracut and run "zipl" manually. Then the image was finally bootable.
Comment 10 Alexander Todorov 2019-09-03 12:51:46 UTC 
Created attachment 1611128 [details]
program.log
Comment 11 Alexander Todorov 2019-09-03 12:52:09 UTC 
Created attachment 1611129 [details]
anaconda.log
Comment 12 Alexander Todorov 2019-09-03 12:52:48 UTC 
Created attachment 1611130 [details]
lvm.log
Comment 13 Alexander Todorov 2019-09-03 12:52:59 UTC 
Created attachment 1611131 [details]
packaging.log
Comment 14 Alexander Todorov 2019-09-03 12:53:09 UTC 
Created attachment 1611132 [details]
storage.log
Comment 17 Brian Lane 2019-09-03 16:42:01 UTC 
https://bugzilla.redhat.com/show_bug.cgi?id=1746424 is likely the root cause of this, it wasn't copying the config file.
Comment 19 Brian Lane 2019-11-06 20:40:02 UTC 
Looking at this again I realize that it is different from the live-iso case.

Comment 7 indicates that it is possible to get the image bootable with some manual intervention. These steps should be handled by Anaconda.

After some digging around I discovered that installing the bootload was disabled because of rhbz#1019502, ends up there is a check for s390 image installation in pyanaconda/bootloader/execution.py that has been in place since 2013.

If I disable the check in pyanaconda/bootloader/execution.py the qcow2 image is now bootable, but it isn't a working system.
Once it hits dracut it cannot find the root disk, and it looks like there are no disks attached at all.
Bootup is also very slow, even when passing --rng=/dev/urandom to virt-install, and once you get to the dracut shell there are almost no modules loaded.

I've been booting the disk.qcow2 with:
virt-install --debug --name f32 --memory 2048 --disk /var/lib/lorax/composer/results/UUID/disk.qcow2 --import --rng=/dev/urandom

I'm fairly sure these problems are all things that Anaconda needs to solve (at the least, re-enabling bootloader install to s390 disk images) so I'm moving this bug over there.
Comment 21 Alexander Todorov 2020-02-21 22:02:32 UTC 
I've tested with a current snapshot from February and the image gets build and boots. Fails with a dracut timeout but there is no error about zIPL anymore. Moving to VERIFIED.
Comment 24 Thomas Huth 2021-01-29 07:43:47 UTC 
(In reply to Alexander Todorov from comment #21)
> I've tested with a current snapshot from February and the image gets build
> and boots. Fails with a dracut timeout but there is no error about zIPL
> anymore. Moving to VERIFIED.

Looks like this bug is in VERIFIED since 11 months already - I guess it just has not been auto-closed because there was no errata in this case. Let's close it manually now.