Conversation
|
📦 Built packages are ready! Download here. |
grml2usb
Outdated
|
|
||
| # Detect arm64 ISOs and switch to EFI-only mode | ||
| if grml_flavour.endswith("-arm64") or "-arm64-" in grml_flavour: | ||
| if options.bootloader in ("syslinux", "grub"): |
There was a problem hiding this comment.
-
please merge the two if lines
-
can we make this conditional on the files present in the iso instead of matching on the name?
There was a problem hiding this comment.
ok, first one broke ruff :p
tried something(tm) to address 2), while at it
| cp boot/grub/i386-pc/cdboot.img boot/grub/i386-pc/eltorito.img | ||
| GRUB_BIOS_AVAILABLE=true | ||
| elif [ -d "/usr/lib/grub/i386-pc" ] ; then | ||
| # Try to generate GRUB BIOS boot image (requires i386-pc modules) |
There was a problem hiding this comment.
could investigate dropping this fallback
There was a problem hiding this comment.
yeah, not sure about this yet, happy to take any recommendations how to handle/proceed! :)
There was a problem hiding this comment.
i wonder what the code block here tries to do. on the 2025.12 PC ISO, we don't have any /boot/grub/i386-pc/*img.
Maybe we should have? is this something to fix in grml-live?
There was a problem hiding this comment.
But on our current daily ISOs with GRUB-only we have (example from grml-small-daily20260310build642testing-amd64.iso):
/boot/grub/i386-pc/cdboot.img/boot/grub/i386-pc/core.img/boot/grub/i386-pc/eltorito.img
There was a problem hiding this comment.
FTR, 2025.12 wasn't GRUB-only yet (as in: we didn't use GRUB for BIOS boot)
|
📦 Built packages are ready! Download here. |
|
📦 Built packages are ready! Download here. |
|
Not sure what to do about the |
yeah I was wondering if that is a real or an unrelated failure. It might mean the partition 1 is not marked correctly in the partition table, or something else goes wrong. |
Modern Grml ISOs no longer ship isolinux/syslinux files and use GRUB for both BIOS and EFI boot. Update grml2usb to handle this: - Auto-detection now prefers GRUB over syslinux (if grub-install is available) - GRUB installs directly to MBR for simpler + more reliable BIOS boot - Skip legacy mbrldr chainloader when using GRUB - Detect arm64 ISOs by flavour name and auto-switch to EFI-only mode - Gracefully fall back when syslinux files (logo.16) are missing: - To GRUB if grub-install is available - To EFI-only mode otherwise - Deprecate --grub-mbr option (GRUB now always uses MBR) Backwards compatibility: - ISOs with syslinux files still work (--bootloader=syslinux) - Explicit --bootloader= options are honored - All existing command-line options remain functional Support matrix: Host | ISO | ISO has syslinux | Result --------|-------|------------------|--------------------------- amd64 | amd64 | yes | GRUB BIOS+EFI (or syslinux if requested) amd64 | amd64 | no | GRUB BIOS+EFI amd64 | arm64 | no | EFI-only (auto-detected) arm64 | amd64 | yes/no | EFI-only (BIOS N/A on arm64 host) arm64 | arm64 | no | EFI-only See grml/grml-live#483
Recent Grml ISOs no longer ship isolinux/syslinux, as we switched to GRUB also for BIOS boot. Update grml2iso to create hybrid-bootable ISOs using GRUB for BIOS boot when isolinux is unavailable: - Detect available boot method after grml2usb populates the work directory - On arm64 hosts: prefer GRUB over isolinux (isohybrid unavailable) - Fall back to EFI-only boot with helpful warning if BIOS boot impossible - Check source ISO for GRUB boot images before attempting generation - Look for boot.img in ISO first, then system paths for hybrid MBR - Support three BIOS boot methods: 1. isolinux (if syslinux files present and not on arm64 host) 2. GRUB (using existing eltorito.img/cdboot.img from source ISO) 3. GRUB (generating eltorito.img if i386-pc modules available) Backwards compatibility: - ISOs with syslinux files work unchanged on x86 hosts - Older ISOs with isolinux still produce isolinux-based output ISOs Support matrix: Host | Source ISO | syslinux | GRUB BIOS imgs | Output ISO boots via -------|----------------|----------|----------------|---------------------- amd64 | amd64 (old) | yes | - | isolinux BIOS + EFI amd64 | amd64 (new) | no | yes | GRUB BIOS + EFI amd64 | amd64 (new) | no | no | GRUB BIOS + EFI (generated) amd64 | arm64 | no | no | EFI-only arm64 | amd64 (old) | yes | yes | GRUB BIOS + EFI (from ISO) arm64 | amd64 (old) | yes | no | EFI-only (warning) arm64 | amd64 (new) | no | yes | GRUB BIOS + EFI (from ISO) arm64 | amd64 (new) | no | no | EFI-only (warning) arm64 | arm64 | no | no | EFI-only Note: "GRUB BIOS imgs" means eltorito.img or cdboot.img + boot.img in ISO See grml/grml-live#483
xorriso is required for GRUB-based and UEFI boot support added recently, making the mkisofs/genisoimage fallback paths largely non-functional. Simplify by requiring xorriso unconditionally.
xorriso 1.1.6 is ancient (2011), so no need to check for it any longer. This also allows us to drop the check on UEFI_ENABLE, which is no longer needed.
- Remove duplicate VERSION in param loop - Remove extra closing brace in fold marker - Remove now redundant "Using xorriso" output - Remove redundant USE_GRUB=false assignment after it's no longer used - Remove unused ADD_OPTS variable - Replace $(($OPTIND - 1)) spacing with $(( OPTIND - 1 )) - Replace [ -e X -a ! -n Y ] and [ ! -z X ] with modern equivalents - Replace [ ! -n ] with [ -z ] - Replace `which` with `command -v` - Update Grml ISO name (having also new file naming schema)
The MirBSD-derived mbrldr/mbrmgr binaries offer no functional advantage over the syslinux MBR. Replace them with automatic syslinux MBR discovery (checking the same paths previously used by --syslinux-mbr), removing the need for a bundled MBR binary. FTR: - Remove mbr directory - Always use syslinux MBR when bootloader is syslinux - Remove ismirbsdmbr logic from install_mbr, always use the standard active partition flag (0x80) - Deprecate --syslinux-mbr and --mbr-menu as no-ops with warnings to preserve backwards compatibility - Update debian + tarball.sh files accordingly
I looked at this yesterday and that resulted in #102. The |
|
We're continuing with this one in #104 now to keep things together |
Related to grml/grml-live#483:
(Was sitting on this way to long already and I finally need to stop further optimizing/reworking this 8-) Hope I got things right, or at least we're moving into the right direction! :))
Note: note sure how we want to handle the warnings in grml2iso and whether to exit early or warn about those.