So remastern Sie ein Ubuntu Live ISO, um grub.cfg für die automatische Installation aus lokalen Cloud-Init-Benutzerdaten zu überarbeiten

Question

Ich arbeite an Intel- und M1-Macs und führe Ubuntu Server in VMWare Fusion VMs aus. Ich verwende derzeit die neuesten Versionen ubuntu-23.10-live-server-amd64.iso und ubuntu-23.10-live-server-arm64.iso. Ich kann alles wie gewünscht für Intel-basierte Systeme zum Laufen bringen, aber wenn ich arm64.iso verwende, enthält es kein /boot.catalogund /boot/grub/i386-pc/eltorito.img. Daher kann ich nach meinen Überarbeitungen an grub.cfg kein bootfähiges ISO neu erstellen.

Ich habe Informationen aus verschiedenen Quellen zusammengetragen, beginnend hier:https://ubuntu.com/server/docs/install/autoinstall-quickstart, aber ich habe nicht genug gefunden oder verstanden, um dieses letzte Puzzleteil für meine arm64-Plattform zu ergänzen. Außerdem konnte ich livefs-edit nicht verwenden, da es von „losetup“ abhängt, das unter macOS nicht verfügbar ist; xorriso hat das Problem jedoch auf Intel zu 100 % gelöst und ich stelle mir vor … löst es größtenteils auf den M1s, wenn ich das Problem mit dem Boot-Image lösen kann.

Für amd64.iso funktioniert dies:

1. Extrahieren Sie die ursprüngliche ISO-Datei
2. Benutzerdaten- und Metadatendateien erstellen
3. Überarbeiten Sie die grub.cfg, um ein Autoinstall-Menüelement hinzuzufügen
4. Verpacken Sie das ISO mit Folgendem neu:

    xorriso -as mkisofs \
    --modification-date='2021101314195100' \
    --grub2-mbr \
    --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt:"${ORIGINAL_ISO_PATH}" \
    --protective-msdos-label \
    -partition_cyl_align off \
    -partition_offset 16 \
    --mbr-force-bootable \
    -append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b \
    --interval:local_fs:2470124d-2478587d::"${ORIGINAL_ISO_PATH}" \
    -part_like_isohybrid \
    -iso_mbr_part_type a2a0d0ebe5b9334487c068b6b72699c7 \
    -c '/boot.catalog' \
    -b '/boot/grub/i386-pc/eltorito.img' \
    -no-emul-boot \
    -boot-load-size 4 \
    -boot-info-table \
    --grub2-boot-info \
    -eltorito-alt-boot -e \
    '--interval:appended_partition_2_start_617531s_size_8464d:all::' \
    -no-emul-boot \
    -boot-load-size 8464 \
    -isohybrid-gpt-basdat \
    -o ubuntu-autoinstall.iso \
    -V 'Ubuntu autoinstall' ${EXTRACTED_ISO_PATH}

Aktualisieren Ich habe den Vorschlag auf Anraten von Thomas Schmitt abgefragt und überarbeitet, um Folgendes zu verwenden:

xorriso -as mkisofs \
--modification-date='2023101104561500' \
-partition_cyl_align off \
-partition_offset 16 \
-append_partition 2 0xef --interval:local_fs:4615776d-4629311d::"${ORIGINAL_ISO_PATH}" \
-G --interval:local_fs:0s-15s:zero_mbrpt:"${ORIGINAL_ISO_PATH}" \
-iso_mbr_part_type 0xcd \
-c '/boot/boot.cat' \
-e '--interval:appended_partition_2_start_1153944s_size_13536d:all::' \
-no-emul-boot \
-boot-load-size 13536 \
-output ubuntu-autoinstall.iso \
extracted-iso/

Das Ergebnis war:

GNU xorriso 1.5.6 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'stdio:ubuntu-autoinstall.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 1415g free
Added to ISO image: directory '/'='/extracted-iso'
xorriso : UPDATE :     980 files added in 1 seconds
xorriso : UPDATE :     980 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 32768 bytes from file '--interval:local_fs:0s-15s:zero_mbrpt:ubuntu-23.10-live-server-amd64.iso'
libisofs: NOTE : Automatically adjusted MBR geometry to 1020/159/32
xorriso : UPDATE :  3.18% done
xorriso : UPDATE :  54.15% done
xorriso : UPDATE :  87.88% done
ISO image produced: 1300424 sectors
Written to medium : 1300424 sectors at LBA 0
Writing to 'stdio:ubuntu-autoinstall.iso' completed successfully.

Der einzige Unterschied, den ich beim Überprüfen der extrahierten ISOs sowohl des Originals, das bootfähig ist, als auch des neuen, das es nicht ist, erkenne:

Und der Bootversuch führt zu folgendem Ergebnis:

Ich habe auch versucht:

xorriso -as mkisofs \
--modification-date='2023101104561500' \
-partition_cyl_align off \
-partition_offset 16 \
-append_partition 2 0xef --interval:local_fs:4615776d-4629311d::"${ORIGINAL_ISO_PATH}" \
-iso_mbr_part_type 0xcd \
-c '/boot/boot.cat' \
-e '--interval:appended_partition_2_start_1153944s_size_13536d:all::' \
-no-emul-boot \
-output ubuntu-autoinstall.iso \
extracted-iso/

Ich reiße mir die Haare aus und klammere mich an jeden Strohhalm. Vieles davon verstehe ich nicht ganz, aber ich sehe, dass -cder Boot-Katalog platziert wurde. Um das neue ISO näher an das Original zu bringen, habe ich `c '/boot.catalog' verwendet, was mich nun zu einem Unterschied in einer Originaldatei führt, der so aussieht:

Ich vermute, dass es etwas gibt, das ich NICHT sehen kann, vielleicht im tatsächlichen MBR? Ich spekuliere nur über Dinge, mit denen ich nicht sehr vertraut bin, während ich nach weiteren Informationen suche.

GelöstDank der Hilfe von Thomas Shchmitt. Die nächsten Schritte wären, ORIGINAL_EXTRACTED_ISO_DIR durch ein überarbeitetes Ziel, neue Cloud-Init-Benutzerdaten, grub.cfg usw. zu ersetzen.

case "$ARCHITECTURE" in
    "m1")
        echo "Running on M1 Mac."
        xorriso -as mkisofs \
        --modification-date='2023081005071100' \
        -partition_cyl_align off \
        -partition_offset 16 \
        -append_partition 2 0xef --interval:local_fs:4030464d-4042271d::"${ORIGINAL_ISO_FILE}" \
        -G --interval:local_fs:0s-15s:zero_mbrpt:"${ORIGINAL_ISO_FILE}" \
        -iso_mbr_part_type 0xcd \
        -c '/boot/boot.cat' \
        -e '--interval:appended_partition_2_start_1007616s_size_11808d:all::' \
        -no-emul-boot \
        -boot-load-size 11808 \
        -output ${AUTOINSTALL_ISO_FILE} \
        ${ORIGINAL_EXTRACTED_ISO_DIR}/
        ;;
    "intel")
        echo "Running on Intel Mac."
        xorriso -as mkisofs \
        --modification-date='2023081005062500' \
        --grub2-mbr --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt:"${ORIGINAL_ISO_FILE}" \
        --protective-msdos-label \
        -partition_cyl_align off \
        -partition_offset 16 \
        --mbr-force-bootable \
        -append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b --interval:local_fs:4156048d-4166115d::"${ORIGINAL_ISO_FILE}" \
        -appended_part_as_gpt \
        -iso_mbr_part_type a2a0d0ebe5b9334487c068b6b72699c7 \
        -c '/boot.catalog' \
        -b '/boot/grub/i386-pc/eltorito.img' \
        -no-emul-boot \
        -boot-load-size 4 \
        -boot-info-table \
        --grub2-boot-info \
        -eltorito-alt-boot \
        -e '--interval:appended_partition_2_start_1039012s_size_10068d:all::' \
        -no-emul-boot \
        -boot-load-size 10068 \
        -output ${AUTOINSTALL_ISO_FILE} \
        ${ORIGINAL_EXTRACTED_ISO_DIR}/
        ;;
    *)
        echo "Unsupported architecture: $ARCHITECTURE"
        exit 1
        ;;
esac

Answer 1

danke fürs Fliegen, xorriso. :)

/boot/grub/i386-pc/eltorito.img ist für das x86 Legacy-PC-BIOS. Es wird in einem ISO für arm64 nicht benötigt. Dasselbe gilt für den GRUB2 MBR. Der EFI-Kram ist für alle drei Architekturen recht ähnlich.

Ich bitte xorriso um einen Vorschlag zur Neuerstellung der Boot-Ausrüstung des Original-ISO:

$ xorriso -indev ubuntu-23.10-live-server-arm64.iso -report_el_torito as_mkisofs
...
-V 'Ubuntu-Server 23.10 arm64'
--modification-date='2023101104561500'
-partition_cyl_align off
-partition_offset 16
-append_partition 2 0xef --interval:local_fs:4615776d-4629311d::'ubuntu-23.10-live-server-arm64.iso'
-G --interval:local_fs:0s-15s:zero_mbrpt:'ubuntu-23.10-live-server-arm64.iso'
-iso_mbr_part_type 0xcd
-c '/boot/boot.cat'
-e '--interval:appended_partition_2_start_1153944s_size_13536d:all::'
-no-emul-boot
-boot-load-size 13536

Die Option -G ist in diesem Fall nicht wirklich notwendig. Sie wird vorgeschlagen, weil eine Partitionstabelle vorhanden ist. Ihre Wirkung wird durch die Erstellung der neuen Partitionstabelle außer Kraft gesetzt. Die Option -boot-load-size sollte weggelassen werden, wenn das Risiko besteht, dass sich die Größe der EFI-Partition geändert hat.