Looking at the lorax PR, I don't see any change to how lorax is called. Pungi may not need any update for actually calling lorax itself. However I do see potential impact on creating bootable DVDs. The options passed to xorriso are changing, and they should probably match between Pungi and lorax.

Something else to explore is xorriso's ability to modify the iso, I've used this to rewrite mkksiso (PR is here https://github.com/weldr/lorax/pull/1228) which may be able to make pungi's modifications more generic.

OK, so, we're running up against this in practice now. It's worth noting this is an official Change for Fedora 37.

@bcl did a build of lorax which builds live images and netinst images with grub2 bootloader, not syslinux. We also changed the lorax package to depend on grub2 rather than syslinux.

When we run a Rawhide compose that way, the Server DVD ISO build fails:

INFO: Running in chroot: ['/bin/sh', '-c', '{ rm -f /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; bash /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/work/x86_64/tmp-Server/createiso-Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso.sh; } < /dev/null 2>&1 | /usr/bin/tee /builddir/runroot.log; exit ${PIPESTATUS[0]}']
Start: chroot ['/bin/sh', '-c', '{ rm -f /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; bash /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/work/x86_64/tmp-Server/createiso-Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso.sh; } < /dev/null 2>&1 | /usr/bin/tee /builddir/runroot.log; exit ${PIPESTATUS[0]}']
+ bash /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/work/x86_64/tmp-Server/createiso-Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso.sh
+ cd /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/compose/Server/x86_64/iso
+++ cut -c3-
++++ which lorax
+++ head -n1 /usr/sbin/lorax
++ /usr/bin/python3 -c 'import pylorax; print(pylorax.find_templates())'
+ TEMPLATE=/usr/share/lorax/templates.d/99-generic
+ /usr/bin/genisoimage -untranslated-filenames -volid Fedora-S-dvd-x86_64-rawh -J -joliet-long -rational-rock -translation-table -input-charset utf-8 -x ./lost+found -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -o Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso -graft-points -path-list /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/work/x86_64/iso/Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso-graft-points
Warning: creating filesystem that does not conform to ISO-9660.
/usr/bin/genisoimage: Uh oh, I cant find the boot catalog directory 'isolinux'!
Finish: chroot ['/bin/sh', '-c', '{ rm -f /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; bash /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/work/x86_64/tmp-Server/createiso-Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso.sh; } < /dev/null 2>&1 | /usr/bin/tee /builddir/runroot.log; exit ${PIPESTATUS[0]}']

As you can see, it's failing because it's trying to pull in bits of syslinux (isolinux) that aren't there. I believe we're in the Pungi createiso phase here, which is its own whole implementation of "make a bootable ISO". So unfortunately we have (at least) two of those - one in lorax, one in pungi - which we use to make different ISOs. lorax makes the netinst and live ISOs, which are now converted to using grub2. pungi makes the Server DVD ISO, which is still trying to use syslinux. I'm not sure what makes the Silverblue and Kinoite installer images, but I'm guessing it's also pungi?

I think the immediate reason why the Server DVD ISO build fails is that pungi doesn't actually do anything to directly ensure the syslinux/isolinux bits are available for the runroot task. It appears to pull in these packages:

coreutils genisoimage isomd5sum lorax which

which are passed on the koji command line:

koji --profile=compose_koji runroot --nowait --task-id --use-shell --channel-override=compose --package=coreutils --package=genisoimage --package=isomd5sum --package=lorax --package=which --mount=/mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0 f37-build x86_64 'rm -f /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; bash /mnt/koji/compose/rawhide/Fedora-Rawhide-20220604.n.0/work/x86_64/tmp-Server/createiso-Fedora-Server-dvd-x86_64-Rawhide-20220604.n.0.iso.sh'

that list seems to come from pungi/phases/createiso.py function run_createiso_command. Note nothing syslinux-y is in it. I think previously this was OK because lorax depended on syslinux and syslinux-nonlinux, but now it doesn't, they don't get pulled in and so the command fails.

So I think the quicker/easier fix here would be to make pungi pull in the syslinux packages it needs here. But then we'd still have an inconsistency between images built by lorax (using grub2) and images built by pungi (using syslinux), which seems against the spirit if not the letter of the Change.

As an additional note, pungi itself seems to have at least two different "build an ISO" code paths: as well as the createiso phase, there's a whole self-contained one in pungi/gather.py, Pungi.doCreateIsos(). I am not sure what, if anything, that's used for in Fedora or RHEL. There's also a rebuild_boot_iso() in pungi/phases/product_img.py which does ISO-building-stuff; again I'm not sure what the point of that is, or when/where it's used.

Ugh, this turns out to be more tricky than I thought. pungi doesn't get the isolinux stuff from a package; it expects to find an isolinux directory in the compose tree, under /compose/[flavor]/[arch]/os.

That seems to be produced by lorax somehow, or at least come from lorax's output, because in an old tree built with lorax using syslinux, that dir exists:

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220601.n.0/compose/Server/x86_64/os/isolinux/

but in a new tree built with lorax using grub2, it doesn't:

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220604.n.0/compose/Server/x86_64/os/isolinux/

that's 404. Instead there's a https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220604.n.0/compose/Server/x86_64/os/boot/ containing grub2 stuff.

So I don't think we can have lorax using grub2 but pungi using syslinux without major surgery, because pungi somehow relies on lorax to be using syslinux too. For lorax to use grub2 we have to port pungi as well, or at least have it somehow get its syslinux bits elsewhere.

For now I think we'll have to revert lorax to using syslinux while the Change owners decide how they want to handle this. I'll work with @kevin and @bcl to implement that.

Yup, this is a legacy minefield. The code in pungi/gather.py can be safely ignored. It's part of the old Pungi 3 and not even packaged in Fedora anymore (it depends on yum…).

I agree trying to get the syslinux related parts of Pungi aligned with GRUB2 is extremely difficult if even possible.

One possible way forward might be to use the ability of xorriso to modify an existing image mentioned by Brian above. I tried putting together a patch that changes how bootable images are created: it will take the boot.iso created by lorax, and just inject all of the other files into it.

I have not been able to test it with Fedora, but with RHEL it seems to produce some ISO (except for ppc64le where I'm getting an error).

The PR is here: https://pagure.io/pungi/pull-request/1613

I believe this is now resolved.