This is a tracking bug for Change: BIOS boot.iso with GRUB2 For more details, see: https://fedoraproject.org/wiki/Changes/BIOSBootISOWithGrub2 Modify lorax-generic-templates to use GRUB2 when booting the boot.iso on BIOS systems, instead of syslinux. Upstream syslinux development is dead, and the Fedora maintainer would like to drop the package from the distribution. GRUB2 works as a replacement in most situations and continues to have upstream support. If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.
PR is here - https://github.com/weldr/lorax/pull/1226
FEDORA-2022-ea87ad9c90 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ea87ad9c90
FEDORA-2022-8b09e9411b has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8b09e9411b
FEDORA-2022-8b09e9411b has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Re-opening for the purposes of the Changes process. Set to ON_QA since the update has landed.
This appears to have thrown a wrench into Rawhide nightly composes, which have been stuck doomed since 20220602.n.0: (I believe) the templates are being picked up from the wrong version of Lorax compared to the system being built, so are assuming the continued presence of the isolinux binaries. livemedia-creator output [1] referenced from today's livemedia-Workstation compose output [2] notes the following: ``` 2022-06-06 07:58:39,359 INFO pylorax.ltmpl: running x86.tmpl 2022-06-06 07:58:39,359 DEBUG pylorax.ltmpl: template line 1: mkdir LiveOS 2022-06-06 07:58:39,359 DEBUG pylorax.ltmpl: template line 2: install images/install.img LiveOS/squashfs.img 2022-06-06 07:58:40,341 DEBUG pylorax.ltmpl: template line 3: treeinfo stage2 mainimage LiveOS/squashfs.img 2022-06-06 07:58:40,341 DEBUG pylorax.ltmpl: template line 4: mkdir isolinux 2022-06-06 07:58:40,341 DEBUG pylorax.ltmpl: template line 5: install usr/share/syslinux/isolinux.bin isolinux 2022-06-06 07:58:40,341 ERROR pylorax.ltmpl: template command error in x86.tmpl: 2022-06-06 07:58:40,342 ERROR pylorax.ltmpl: install usr/share/syslinux/isolinux.bin isolinux 2022-06-06 07:58:40,342 ERROR pylorax.ltmpl: OSError: nothing matching /var/tmp/lorax.imgutils.qc0h2la8/usr/share/syslinux/isolinux.bin in / 2022-06-06 07:58:40,342 DEBUG pylorax.ltmpl: Traceback (most recent call last): 2022-06-06 07:58:40,342 DEBUG pylorax.ltmpl: File "/usr/lib/python3.10/site-packages/pylorax/ltmpl.py", line 432, in install 2022-06-06 07:58:40,343 DEBUG pylorax.ltmpl: for src in rglob(self._in(srcglob), fatal=True): 2022-06-06 07:58:40,343 DEBUG pylorax.ltmpl: File "/usr/lib/python3.10/site-packages/pylorax/ltmpl.py", line 103, in rglob 2022-06-06 07:58:40,343 DEBUG pylorax.ltmpl: raise IOError("nothing matching %s in %s" % (pathname, root)) 2022-06-06 07:58:40,343 DEBUG pylorax.ltmpl: OSError: nothing matching /var/tmp/lorax.imgutils.qc0h2la8/usr/share/syslinux/isolinux.bin in / 2022-06-06 07:58:41,361 DEBUG pylorax.imgutils: remove tmp mountdir /var/tmp/lorax.imgutils.qc0h2la8 2022-06-06 07:58:41,361 ERROR livemedia-creator: nothing matching /var/tmp/lorax.imgutils.qc0h2la8/usr/share/syslinux/isolinux.bin in / ``` I don't have a higher degree of certainty as my brief digging hasn't yet indicated what versions of the templates are being picked up, but this misbehaviour seems consistent with packages from the last successful compose, which included lorax at 37.2-1.fc37. This therefore looks like some manual intervention is required to allow composes to succeed --- manually pulling 37.5-1 into a "successful" compose, I suppose --- or otherwise reverting to a configuration compatible with 37.2-1, and then taking an alternate path towards flensing syslinux from the live images. [1]: https://kojipkgs.fedoraproject.org/work/tasks/1264/87931264/livemedia-out.log [2]: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220606.n.0/logs/aarch64-ppc64le-x86_64/livemedia-Workstation-Workstation.aarch64-ppc64le-x86_64.log
(In reply to Jashank Jeremy from comment #6) > This appears to have thrown a wrench into Rawhide nightly composes, which > have been stuck doomed since 20220602.n.0: (I believe) the templates are > being picked up from the wrong version of Lorax compared to the system being > built, so are assuming the continued presence of the isolinux binaries. It looks like it isn't using the new version of lorax, but the Fedora kickstarts has been updated to drop syslinux. I'm not sure exactly how those dependencies are handled in koji, but the new kickstart should depend lorax-generic-templates-37.3-1 or later.
The best place to follow this live is #fedora-releng on libera.chat (Fedora Release Engineering on chat.fedoraproject.org), and the failed-composes tracker: https://pagure.io/releng/failed-composes Composes with the latest lorax are failing because pungi is still assuming isolinux: https://pagure.io/releng/failed-composes/issue/3634#comment-800603 so we (nirik) untagged the lorax builds with the grub2 switch to try and get an old-style compose run over the weekend, but forgot we'd updated comps and kickstarts to drop syslinux, so that didn't work either. This is the state you're seeing above. Now it's a new week and we're all at work the plan is to figure out an appropriate change to pungi and then re-tag the newer loraxes and hope we finally get a compose that way.
So I did some more digging into this, which is written up at https://pagure.io/pungi/issue/1608#comment-800726 . From the point of view of the Change process, we have an odd situation here. Turns out (if I'm right, anyway) some of our bootable ISO deliverables are created by lorax, and some directly by pungi. As this Change is written and currently implemented, the ones created by lorax - the netinst and live images - will be switched to grub2, but the ones created directly by pungi - the Server DVD image, and I think probably the Silverblue and Kinoite installer DVD images - will still use syslinux/isolinux. I'm not sure if that was the intended outcome of the Change, or if the Change owners did not know about this wrinkle. If the intent was to not have any images that use syslinux any more, I don't think the implementation planned so far is sufficient to achieve that outcome. I guess it's up to the Change owners if they want to add "make pungi use grub2 as well" to the scope of the Change? It looks quite non-trivial to implement, it's not something I can just whack together a PR for in an hour, anyway. For the immediate future I'm just going to try and fix things so that pungi still uses syslinux, but it actually works.
Ugh, this got wrinklier: https://pagure.io/pungi/issue/1608#comment-800746 unless I got something wrong, I don't think this Change is viable as-is. It looks like we can't port lorax to using grub2 without *also* porting pungi to using it, because pungi relies on lorax's output: pungi is expecting to find syslinux bits in the compose tree that were written there by lorax, or at least taken from lorax's output. With lorax changed to using grub2, those bits are no longer in the tree, and that's why pungi is blowing up. So this Change has to include pungi in its scope somehow - either by porting pungi to using grub2 as well, or at least making pungi somehow capable of building images with syslinux even when lorax doesn't use it. For now we're gonna have to revert lorax back to using syslinux, I think, until this is figured out.
OK, this should all be fixed now. We ported pungi to use grub2 (actually it uses xorriso to just reuse whatever boot bits lorax wrote). Composes are working, at least. We need to check whether images still boot in all expected configurations.
Was it intended/expected that we lose the "Boot from hard disk" (or whatever it's called) entry from the troubleshooting menu as part of this change? I use it *all the time*, it's a bit annoying having to shut down VMs and disconnect the optical drive all the time just to boot from the local disk.
(In reply to Adam Williamson from comment #12) > Was it intended/expected that we lose the "Boot from hard disk" (or whatever > it's called) entry from the troubleshooting menu as part of this change? I > use it *all the time*, it's a bit annoying having to shut down VMs and > disconnect the optical drive all the time just to boot from the local disk. Not on purpose, but we've never had a generic 'Boot from local drive' in the grub menu. In syslinux we used 'localboot' which apparently reported a bootloader failure to the BIOS in the hopes it would boot the next thing. https://wiki.syslinux.org/wiki/index.php?title=SYSLINUX#LOCALBOOT_type From my reading of the grub2 chainload command you need to setup root first, so I'm not sure if you can do the same thing in a generic way.
So yeah, on this: "We need to check whether images still boot in all expected configurations." ...I just found out that, for me at least, current Rawhide images written to a USB stick with dd don't seem to boot in native UEFI mode: https://bugzilla.redhat.com/show_bug.cgi?id=2103785
F37 Beta ISO to USB fails to boot on my BIOS-only laptop: https://bugzilla.redhat.com/show_bug.cgi?id=2140385
F37 was released today, so I am closing this tracker. If this Change was not completed, please notify me ASAP.