主页 / unix / 问题 / 487895
Accepted
Roxy
Asked: 2018-12-14 16:36:36 +0800 CST

如何使用 mkisofs 创建一个 FreeBSD ISO，它将在 UEFI 下的 VirtualBox 中启动？

  • 772

我正在尝试编写一个脚本来解压缩并重新打包 FreeBSD ISO，以便我可以使用它进行安装。目标是无人值守的安装。

我已经编写了以下脚本，但它不起作用。虽然原始 ISO 将在 UEFI 模式下在 VirtualBox 中启动，但新创建的 ISO 不会。

#!/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}"

创建的文件系统看起来不错。我已经区分了原始 ISO 和自定义 ISO 的文件，唯一的区别是installerconfig添加的文件和boot.catalog（我理解mkisofs添加，但是为什么？这可能是问题吗？）

我尝试了各种选项组合mkisofs，包括-R -U, -L -D -R, -J -R，但没有任何区别。

此外，有趣的是， FreeBSD 手册有以下评论：

因此，如果 /tmp/myboot 拥有一个可引导的 FreeBSD 系统，其引导映像位于 /tmp/myboot/boot/cdboot，则此命令将生成 /tmp/bootable.iso：

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

这不会生成在 UEFI 模式下在 VirtualBox 下启动的 ISO。

有谁知道出了什么问题？

freebsd iso

3 个回答

  1. 通过在标准映像之上创建另一个 cd9660 会话来添加额外的文件，而不是解包和打包回 iso，要容易得多：

    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 ...]

    这应该“继承”上一个会话的引导映像，具有相同路径的新文件将覆盖光盘上已有的文件（但仅当它们较新时，使用标准mkisofs/时genisoimage）。

    请注意，除非新会话的卷 ID 设置为与旧会话相同（如上），否则 FreeBSD 安装程序不会自动挂载 cd，而是会提示输入带有mountroot>.

    我已经在 qemu 上使用OVMF UEFI 固件从这里测试了上述内容，使用以下命令行：

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

    如果您确实需要从头开始创建 UEFI 可启动 cd，那么您可以在 FreeBSD 的wiki（在“UEFI 下的 CD/DVD 启动”下）和此处找到更多信息。

    FreeBSD 的损坏的 growisofs

    由于一个错误，growisofs当与常规文件而不是设备一起使用时，将在 FreeBSD 上崩溃；为避免这种情况，您应该将此差异应用于growisofs.c（适用于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

    问题不在于文件系统内容，而在于引导记录和分区：

    
$ 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

    BIOS 引导映像和 EFI 系统分区都不是 ISO 中的文件，而是未命名的块区域。

    如果您不通过固定的 growisofs 或通过

    
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 ...]

    那么你需要提取这些区域

    
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 以 2048 块为单位提供 LBA，但以 512 块为单位提供大小。4 * 420 = 1680。1204 个 2048 字节块的 BIOS 映像大小由高于 420 的最低文件系统对象 LBA 估计。可能它更小但任何过大不应该有害。）

    然后是从 U 盘启动 BIOS 的 MBR 代码：

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

    如果您不打算通过 BIOS 引导，则不需要 bios_boot.img 和 mbr_code.img。

    从解压和主树 $HOME/files_for_iso 和提取的图像文件构建一个新的 ISO

    
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

    这将不会产生 GPT，而是会产生一个 MBR 分区表，其中包含两个用于 ISO 文件系统的 0x83 类型的分区和用于 EFI 系统分区的 0xef。

    （是否必须测试从 U 盘启动的 BIOS。许多 MBR 需要修补信息才能找到下一阶段的启动程序。）

    • 4

  3. 许多关于创建可引导 ISO 的文档的问题在于，它们倾向于默认采用非 UEFI 引导。

    这是一个很好的参考资料，其中包含有关从 CD/DVD 媒体启动 UEFI 的信息：https ://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt

    因此，如果您想在 UEFI 中使用单独的 El Torito 启动映像（就像您以前使用 BIOS 一样），您需要确保启动映像嵌入了 UEFI 的正确平台 ID字节。对于 x86 BIOS，平台 ID 为 0。PowerPCs used 1；值 2 是为 Mac 指定的；UEFI 指定值 0xef，即十进制的 239。

    因此，在我看来，您必须有某种方法来指定平台 ID 值：直接或通过使用某些选项来指定引导映像应该是UEFI引导映像。我想这个由 mosvy 链接的 Fedora 文档是通过使用选项-e来指定位置efiboot.img而不是-b像传统的 BIOS 引导映像那样使用。

    因此，请验证您boot/cdboot是有效的UEFI启动映像，并尝试-e boot/cdboot在mkisofs命令行中使用而不是-b boot/cdboot.

    以下是 UEFI 启动映像内容的描述：

    我碰巧手头有一个 RHEL 8.0 beta 1 ISO 映像，我刚刚确认它实际上可以在 UEFI 模式下使用 VirtualBox 启动。它使用的 UEFI 引导映像在映像的主 iso9660 文件系统中可用images/efiboot.img，并且它显然只包含一个 FAT 文件系统映像，没有任何类型的分区表。

    在 的文件系统中efiboot.img，只有一个\EFI\BOOT包含适当 UEFI 引导加载程序的目录：在这种情况下，两者BOOTX64.EFI和BOOTIA32.EFI似乎都是安全引导垫片，以及相应版本的 GRUBgrubx64.efi和grubia32.efi，以及这些所需的任何辅助文件：GRUB配置文件、GRUB 字体文件和安全启动 shim 的 MOKManager。

    • 0

相关问题