Início / unix / Perguntas / 487895
Accepted
Roxy
Asked: 2018-12-14 16:36:36 +0800 CST

Como criar um ISO do FreeBSD com mkisofs que inicializará no VirtualBox sob UEFI?

  • 772

Estou tentando escrever um script que irá descompactar e reempacotar um ISO do FreeBSD para que eu possa fazer uma instalação com ele. O objetivo é uma instalação autônoma.

Eu tenho o seguinte script escrito, mas não funciona. Enquanto o ISO original inicializará no VirtualBox no modo UEFI, o ISO recém-criado não.

#!/bin/sh

inst_cfg="$1"
src_iso="$2"
dst_iso="$3"

iso_mnt=$(mktemp -d /tmp/freebsd-mnt-XXXXXX)
iso_wrk=$(mktemp -d /tmp/freebsd-wrk-XXXXXX)

vol_id=$(isoinfo -d -i "${src_iso}" | sed -n -e 's/^Volume id: \(.*\)$/\1/p')

md_name=$(mdconfig -a -t vnode -f "${src_iso}")
mount -t cd9660 "/dev/${md_name}" "${iso_mnt}"

cp -a -v "${iso_mnt}/" "${iso_wrk}"
cp "${inst_cfg}" "${iso_wrk}/etc/installerconfig"
mkisofs -J -R -no-emul-boot -V "${vol_id}" -b boot/cdboot -o "${dst_iso}" "${iso_wrk}"

umount "${iso_mnt}" # cd9660
mdconfig -d -u "${md_name}"

rm -rf "${iso_mnt}"
rm -rf "${iso_wrk}"

O sistema de arquivos criado parece bom. Eu diferenciei os arquivos dos ISOs originais e personalizados e as únicas diferenças são o installerconfigarquivo adicionado e boot.catalog(o que eu entendo mkisofsacrescenta, mas por quê? Poderia ser esse o problema?)

Eu tentei várias combinações de opções para mkisofs, incluindo -R -U, -L -D -R, -J -R, mas nada faz diferença.

Além disso, o Manual do FreeBSD curiosamente tem o seguinte comentário:

Portanto, se /tmp/myboot contém um sistema FreeBSD inicializável com a imagem de inicialização em /tmp/myboot/boot/cdboot, este comando produziria /tmp/bootable.iso:

mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot

Isso não produz um ISO que inicializa no VirtualBox no modo UEFI.

Alguém tem ideia do que está errado?

freebsd iso

3 respostas

  1. Em vez de descompactar e compactar a iso, é muito mais fácil adicionar os arquivos extras criando outra sessão cd9660 em cima da imagem padrão:

    cp FreeBSD-12.0-RELEASE-amd64-bootonly.iso new.iso
volid=$(isoinfo -d -i new.iso | awk '/Volume id/{print$3}')
growisofs -M new.iso -d -l -r -V "$volid" -graft-points \
   /etc/installerconfig=/path/to/your_installerconfig \
   [other files ...]

    Isso deve "herdar" a imagem de inicialização da sessão anterior, e novos arquivos com o mesmo caminho substituirão os que já estão no disco (mas apenas se forem mais recentes, ao usar o padrão mkisofs/ genisoimage).

    Observe que, a menos que o Volume Id da nova sessão seja igual ao anterior (como acima), o instalador do FreeBSD não montará o cd automaticamente, mas solicitará uma especificação fs com mountroot>.

    Eu testei o acima no qemu usando o firmware OVMF UEFI daqui , usando a seguinte linha de comando:

    qemu-system-x86_64 -enable-kvm -m 2G -serial none \
    -bios ovmf-x64/OVMF-pure-efi.fd -cdrom new.iso

    Se você realmente precisa criar um cd inicializável UEFI do zero, então você pode encontrar mais informações no wiki do FreeBSD (em "CD/DVD Boot under UEFI") e aqui .

    Os growisofs quebrados do FreeBSD

    Por causa de um bug, growisofsirá travar no FreeBSD quando usado com um arquivo normal ao invés de um dispositivo; para evitar isso, você deve aplicar este diff a growisofs.c(aplicar com patch -l):

    --- growisofs.c~        2018-12-14 07:32:38.814189935 +0200
+++ growisofs.c 2018-12-14 07:32:43.602431986 +0200
@@ -3471,7 +3471,8 @@
     CLOSEONEXEC(in_fd);
     CLOSEONEXEC(out_fd);
 #if !(defined(__APPLE__) && defined(__MACH__))
-    CLOSEONEXEC(ioctl_fd);
+    if(ioctl_handle != INVALID_HANDLE)
+       CLOSEONEXEC(ioctl_fd);
 #endif
 #undef CLOSEONEXEC
    • 4
  2. Best Answer

    O problema não está no conteúdo do sistema de arquivos, mas nos registros e partições de inicialização:

    
$ xorriso -indev FreeBSD-12.0-RELEASE-amd64-bootonly.iso -report_el_torito plain -report_system_area plain
...
libisofs: WARNING : Found hidden El-Torito image. Its size could not be figured out, so image modify or boot image patching may lead to bad results.
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 20 * 2048 , 1600 * 512
...
Boot record  : El Torito , MBR protective-msdos-label cyl-align-off GPT
...
El Torito catalog  : 19  1
El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4         420
El Torito boot img :   2  UEFI  y   none  0x0000  0x00   1600          20
El Torito img blks :   1  1204
El Torito img blks :   2  400
System area options: 0x00000201
System area summary: MBR protective-msdos-label cyl-align-off GPT
ISO image size/512 : 675508
Partition offset   : 0
MBR heads per cyl  : 0
MBR secs per head  : 0
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x00  0xee            1       676107
GPT                :   N  Info
GPT backup problems:      Not a GPT 1.0 header of 92 bytes for 128 bytes per entry
GPT disk GUID      :      7ce0bf52def9e8118c360cc47ad8b808
GPT entry array    :      2  2  separated
GPT lba range      :      3  676105  676107
GPT partition name :   1  
GPT partition GUID :   1  6de0bf52def9e8118c360cc47ad8b808
GPT type GUID      :   1  28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags:   1  0x0000000000000000
GPT start and size :   1  80  1600
GPT partition name :   2  
GPT partition GUID :   2  73e0bf52def9e8118c360cc47ad8b808
GPT type GUID      :   2  9d6bbd83417fdc11be0b001560b84f0f
GPT partition flags:   2  0x0000000000000000
GPT start and size :   2  3  29

    Tanto a imagem de inicialização do BIOS quanto a partição do sistema EFI não são arquivos no ISO, mas sim áreas de bloco sem nome.

    Se você não seguir o caminho de anexar uma sessão por crescimento fixo ou por

    
cp FreeBSD-12.0-RELEASE-amd64-bootonly.iso new.iso
xorriso -boot_image any keep \
        -dev new.iso \
        -map /path/to/your_installerconfig /etc/installerconfig
        [other -map commands for files or directory trees ...]

    então você precisa extrair essas áreas

    
dd if=FreeBSD-12.0-RELEASE-amd64-bootonly.iso bs=512 skip=80 count=1600 \
   of=efi_part.img
dd if=FreeBSD-12.0-RELEASE-amd64-bootonly.iso bs=512 skip=1680 count=4816 \
   of=bios_boot.img

    (El Torito fornece LBAs em blocos de 2048, mas tamanhos em blocos de 512. 4 * 420 = 1680. O tamanho da imagem do BIOS de 1204 blocos de 2048 bytes é estimado pelo menor LBA de objeto do sistema de arquivos que está acima de 420. Possivelmente, é menor, mas qualquer tamanho grande não deve prejudicar.)

    Depois, há o código MBR para inicialização do BIOS a partir do pendrive:

    
dd if=FreeBSD-12.0-RELEASE-amd64-bootonly.iso bs=1 count=446 \
   of=mbr_code.img

    Se você não planeja inicializar pelo BIOS, bios_boot.img e mbr_code.img não são necessários.

    Construindo um novo ISO a partir da árvore descompactada e mainpululada $HOME/files_for_iso e os arquivos de imagem extraídos

    
xorriso -as mkisofs \
        -o new.iso \
        -d -l -r \
        -V "12_0_RELEASE_AMD64_BO" \
        -G mbr_code.img \
        -b /bios_boot.img \
           -no-emul-boot -boot-load-size 4 \
        -eltorito-alt-boot \
        -append_partition 2 0xef efi_part.img \
        -e '--interval:appended_partition_2:all::' \
           -no-emul-boot \
        bios_boot.img $HOME/files_for_iso

    Isso não produzirá GPT, mas sim uma tabela de partição MBR com duas partições do tipo 0x83 para o sistema de arquivos ISO e 0xef para a partição do sistema EFI.

    (Se o BIOS inicializa a partir do pendrive USB teria que ser testado. Muitos MBRs precisam de informações corrigidas para encontrar o próximo estágio dos programas de inicialização.)

    • 4

  3. O problema com muitos documentos sobre a criação de ISOs inicializáveis ​​é que eles tendem a assumir inicialização não UEFI por padrão.

    Aqui está uma boa referência que contém informações sobre a inicialização UEFI da mídia de CD/DVD: https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt

    Portanto, parece que, se você quiser usar uma imagem de inicialização El Torito separada com UEFI (como costumava fazer com o BIOS), precisará garantir que a imagem de inicialização seja incorporada com um byte de ID de plataforma correto para UEFI. Para BIOS x86, o ID da plataforma era 0. Os PowerPCs usavam 1; o valor 2 foi designado para Macs; e UEFI especifica um valor de 0xef ou 239 em decimal.

    Portanto, parece-me que você teria que ter alguma maneira de especificar o valor do ID da plataforma: diretamente ou usando alguma opção para especificar que a imagem de inicialização deve ser uma imagem de inicialização UEFI . Suponho que este documento do Fedora vinculado por mosvy faça isso usando a opção -epara especificar a localização em efiboot.imgvez de usar -bcomo nas imagens de inicialização tradicionais do BIOS.

    Portanto, verifique se sua imagem de inicialização UEFIboot/cdboot é válida e tente usar na linha de comando em vez de .-e boot/cdbootmkisofs-b boot/cdboot

    E aqui está uma descrição de como pode ser o conteúdo de uma imagem de inicialização UEFI:

    Acontece que eu tenho uma imagem ISO do RHEL 8.0 beta 1 em mãos e acabei de confirmar que é de fato inicializável usando o VirtualBox no modo UEFI. A imagem de inicialização UEFI que ele usa está disponível no sistema de arquivos iso9660 principal das imagens como images/efiboot.img, e aparentemente contém apenas uma imagem do sistema de arquivos FAT, sem qualquer tipo de tabela de partição.

    Dentro do sistema de arquivos do efiboot.img, existe apenas um diretório \EFI\BOOTcom os bootloaders UEFI apropriados: neste caso, ambos BOOTX64.EFIe BOOTIA32.EFI, que parecem ser shims de inicialização segura, e versões correspondentes do GRUB como grubx64.efie grubia32.efirespectivamente, e quaisquer arquivos auxiliares exigidos por aqueles: o GRUB arquivo de configuração, o arquivo de fonte GRUB e o MOKManager para o shim Secure Boot.

    • 0

relate perguntas