Bug 2102907 - ppc64le Server DVD ISOs do not boot since we switched to createiso_use_xorrisofs
Summary: ppc64le Server DVD ISOs do not boot since we switched to createiso_use_xorrisofs
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pungi
Version: rawhide
Hardware: ppc64le
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lubomír Sedlář
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedFreezeException
: 2109095 (view as bug list)
Depends On:
Blocks: PPCTracker BetaFreezeException, F37BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-07-01 00:16 UTC by Adam Williamson
Modified: 2022-08-03 00:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-03 00:03:33 UTC
Type: Bug


Attachments (Terms of Use)
screenshot of the boot failure (in qemu) (40.73 KB, image/png)
2022-07-01 00:17 UTC, Adam Williamson
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.