Bug 2102907

Summary: ppc64le Server DVD ISOs do not boot since we switched to createiso_use_xorrisofs
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: pungiAssignee: Lubomír Sedlář <lsedlar>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: admiller, dan, hlin, jkeating, kevin, lsedlar, onosek, w
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard: openqa AcceptedFreezeException
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-08-03 00:03:33 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: 1071880, 2009538    
Attachments:
Description Flags
screenshot of the boot failure (in qemu) none

Description Adam Williamson 2022-07-01 00:16:31 UTC
As part of https://fedoraproject.org/wiki/Changes/BIOSBootISOWithGrub2 , we had to change the pungi configuration for Fedora Rawhide composes to use `createiso_use_xorrisofs = True` - that was required for having x86_64 ISOs built by pungi just re-use the bootloader bits from the base boot.iso (built by lorax) that they work from.

I just noticed (sorry I didn't spot this earlier) that, since making that change, the ppc64le Server DVD ISOs do not boot. All other ppc64le ISOs do boot. I believe all the other ISOs are built directly by lorax; the Server DVD ISO is the only one that's built by pungi based from an initial image produced by lorax.

Unfortunately, since I didn't notice it in time, the logs from the most recent compose that still worked "the old way" have been garbage collected (unless nirik can reconstruct them from anywhere). But this is the most recent failed task: https://koji.fedoraproject.org/koji/taskinfo?taskID=88911314 . https://kojipkgs.fedoraproject.org//work/tasks/1314/88911314/root.log has all the xorriso logs.

The boot failure looks like the attached screenshot, on a qemu VM: the firmware complains "failed to load CHRP boot loader.failed to load CHRP boot loader."

This is an automatic FE for F37 Beta per https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Automatic_freeze_exceptions "Complete failure of any non-release-blocking image to boot at all under any circumstance - "DOA" image", marking as such.

Comment 1 Adam Williamson 2022-07-01 00:17:26 UTC
Created attachment 1893783 [details]
screenshot of the boot failure (in qemu)

Comment 2 Adam Williamson 2022-07-01 00:24:47 UTC
I *think* with the changes we're using the same `xorriso -boot_image any replay` approach on ppc64le as we are on x86_64, and the base image *does* boot, so this could possibly be a xorriso bug. Or maybe we need some additional args or something for ppc64le?

Comment 3 Adam Williamson 2022-07-01 01:10:02 UTC
Image that boots OK: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220630.n.0/compose/Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20220630.n.0.iso
Image built from it that doesn't boot OK: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220630.n.0/compose/Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20220630.n.0.iso

the `xorriso -indev foo.iso -report_el_torito as_mkisofs` output for both is very similar, but of course if this is a bug in xorriso itself that would make sense...

Comment 4 Lubomír Sedlář 2022-07-01 07:49:28 UTC
The process for building the DVD is the same across all arches.
Pungi runs `xorriso -dialog on` and feeds it with this file:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220630.n.0/work/ppc64le/tmp-Server/xorriso-140602191507232.txt
The image listed as -indev is the same as the netinst linked above, just not renamed yet.

Comment 5 Adam Williamson 2022-07-01 16:15:25 UTC
Yep, I know all that. The question is, why does the new image turn out unbootable?

Comment 6 Adam Williamson 2022-08-03 00:02:32 UTC
*** Bug 2109095 has been marked as a duplicate of this bug. ***

Comment 7 Adam Williamson 2022-08-03 00:03:22 UTC
This is now fixed per https://pagure.io/pungi/pull-request/1613#comment-174372 and subsequent comments.