Description of problem: Iit's z/VM guest being installed both from CMS or by adding an entry to zipl.conf and rebooting to it (the RTT automated way). It happens close to the end of installation when bootloader is actually installed. Version-Release number of selected component: anaconda-28.22.3 The following was filed automatically by anaconda: anaconda 28.22.3 exception report Traceback (most recent call first): File "/usr/lib64/python3.6/site-packages/pyanaconda/bootloader.py", line 2280, in install raise BootLoaderError("could not find IPL device") File "/usr/lib64/python3.6/site-packages/pyanaconda/bootloader.py", line 986, in write self.install() File "/usr/lib64/python3.6/site-packages/pyanaconda/bootloader.py", line 2473, in writeBootLoaderFinal storage.bootloader.write() File "/usr/lib64/python3.6/site-packages/pyanaconda/bootloader.py", line 2552, in writeBootLoader writeBootLoaderFinal(storage, payload, instClass, ksdata) File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 438, in run_task self._task(*self._task_args, **self._task_kwargs) File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 472, in start self.run_task() File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 304, in start item.start() File "/usr/lib64/python3.6/site-packages/pyanaconda/installation_tasks.py", line 304, in start item.start() File "/usr/lib64/python3.6/site-packages/pyanaconda/installation.py", line 361, in doInstall installation_queue.start() File "/usr/lib64/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py", line 291, in run threading.Thread.run(self) pyanaconda.bootloader.BootLoaderError: could not find IPL device Additional info: addons: com_redhat_kdump, com_redhat_docker blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: ro ramdisk_size=40000 cio_ignore=all,!condev rd.dasd=200-207 vnc ip=10.16.104.70::10.16.111.254:21:devel7.s390.bos.redhat.com:enc800:none rd.znet=qeth,0.0.0800,0.0.0801,0.0.0802,layer2=0,portno=0 repo=https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180410.n.1/compose/Everything/s390x/os/ root=live:https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180410.n.1/compose/Everything/s390x/os/images/install.img nameserver=10.11.5.19 executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.16.0-0.rc4.git0.1.fc28.s390x product: Fedora release: Cannot get release name. type: anaconda version: 28
Created attachment 1420414 [details] File: anaconda-tb
Created attachment 1420415 [details] File: anaconda.log
Created attachment 1420416 [details] File: dbus.log
Created attachment 1420417 [details] File: dnf.librepo.log
Created attachment 1420418 [details] File: environ
Created attachment 1420419 [details] File: hawkey.log
Created attachment 1420420 [details] File: lorax-packages.log
Created attachment 1420421 [details] File: lsblk_output
Created attachment 1420422 [details] File: lvm.log
Created attachment 1420423 [details] File: nmcli_dev_list
Created attachment 1420424 [details] File: os_info
Created attachment 1420425 [details] File: program.log
Created attachment 1420426 [details] File: storage.log
Created attachment 1420427 [details] File: syslog
Created attachment 1420428 [details] File: ifcfg.log
Created attachment 1420429 [details] File: packaging.log
Seems I forgot to update kernel/initrd when installing from CMS, will recheck.
Same problem even with the up-to-date boot kernel/initrd.
Proposed as a Freeze Exception for 28-final by Fedora user sharkcz using the blocker tracking app because: It fails to install the bootloader rendering the system unbootable after the installation.
I've rechecked the F-28 Beta compose (Fedora-28-20180328.1) and is it OK. I've also checked previous branched composes and the problem exists even in Fedora-28-20180331.n.1 This one contains all the accumulated changes from the beta freeze, details in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UDJJS6LNQFFI6575PNTCVJ5YIXT6QOGF/.
The exception is raised, because zipl fails with a message: Error: Internal error: Size mismatch of FBA stage 0 loader Reassigning to s390utils.
FWIW, I just upgraded one of my s390x KVM guests from F27 to F28, and after the update, I get the same error when running zipl: # zipl Error: Internal error: Size mismatch of FBA stage 0 loader # zipl -h Error: Internal error: Size mismatch of FBA stage 0 loader # zipl -v Error: Internal error: Size mismatch of FBA stage 0 loader # rpm -qf /usr/sbin/zipl s390utils-base-2.3.0-2.fc28.s390x
Thanks to you both. It should be https://src.fedoraproject.org/rpms/s390utils/c/7b458c246c1e7fd182ff03b511c66993b9b4b208?branch=master breaking it then, looking ...
Yes, seems so - I manually downgraded to s390utils-2.3.0-1.fc28.s390x.rpm and then zipl is working again.
So it's a problem with PIE on the data describing the bootloader stage[012] binary images (data.o built in the boot/ directory).
s390utils-2.3.0-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2a7895e9f2
https://github.com/ibm-s390-tools/s390-tools/pull/30 opened for a proper upstream investigation and fix
s390utils-2.3.0-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2a7895e9f2
Discussed during the 2018-04-16 blocker review meeting: [1] The decision to classify this bug as an AcceptedFreezeException was made: "This is an install time issue (so can't be fully fixed with updates) and is quite serious, would be a blocker on release-blocking arches, so is obviously accepted as an FE" [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-04-16/f28-blocker-review.2018-04-16-16.00.log.txt
s390utils-2.3.0-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.