Change Details

This fixed a problem for me when working with Parallels Desktop 18's UEFI. To give some background: Old VM consisting of three HDDs, originally using legacy gptzfsboot. Two disks zpool, one disk swap. For reasons, disks can't be modified in size and the bootloader won't fit the original boot partitions anymore. Since Parallels seems to have issues with FreeBSD 12+ legacy boot (or vice versa) and moved to using EFI. Unfortunately, EFI boot wouldn't detect my root device automatically, but I could boot when setting it explicitly ``` set currdev=zfs:tank/root: load boot/kernel/kernel load boot/kernel/zfs.ko boot ``` Therefore I looked for a way to be able to set this variable somewhere else. Based on the sources and some search results, modifying `/efi/freebsd/loader.env` sounded promising, so I did this configuration: ```name=loader.env rootdev=zfs:tank/root: ``` Unfortunately, this didn't work. After adding some debug code to `loader.efi`, I learned that the `stat` call on the file fails (even though the loader seems to look at the correct partition). Also, looking at the partition's content from within the boot loader didn't work (`ls` said something like `/ file not found`). The EFI partition was formatted using FAT32, not sure if this is related or not (I didn't have time to test other formats yet). Next, I discovered that I can create boot loader entries in Parallels Desktop's boot menu, so I did: {nav Add boot option > Select Partition > <efi> > BOOT > BOOTX64.efi} and set the following fields: ``` Input the description: FreeBSD Input optional data: rootdev=zfs:tank/root: ``` Again, this failed, even though the boot loader clearly echoed them back: ``` Command line arguments: rootdev=zfs:tank/root: ``` Looking at the code revealed that only arguments `[1..argc]` are parsed, which lead me to this little patch. I don't know enough about UEFI to understand if this is correct behavior or if this is actually a bug in Parallels Desktop. In case of the latter, this patch is moot.

This fixed a problem for me when working with Parallels Desktop 18's UEFI. To give some background: Old VM consisting of three HDDs, originally using legacy gptzfsboot. Two disks zpool, one disk swap. For reasons, disks can't be modified in size and the bootloader won't fit the original boot partitions anymore. Since Parallels seems to have issues with FreeBSD 12+ legacy boot (or vice versa) and moved to using EFI. Unfortunately, EFI boot wouldn't detect my root device automatically, but I could boot when setting it explicitly ``` set currdev=zfs:tank/root: load boot/kernel/kernel load boot/kernel/zfs.ko boot ``` Therefore I looked for a way to be able to set this variable somewhere else. Based on the sources and some search results, modifying `/efi/freebsd/loader.env` sounded promising, so I did this configuration: ```name=loader.env rootdev=zfs:tank/root: ``` Unfortunately, this didn't work. After adding some debug code to `loader.efi`, I learned that the `stat` call on the file fails (even though the loader seems to look at the correct partition). Also, looking at the partition's content from within the boot loader didn't work (`ls` said something like `/ file not found`). The EFI partition was formatted using FAT32, not sure if this is related or not (I didn't have time to test other formats yet). NOTE: When setting up the partition, I used the instructions from https://wiki.freebsd.org/UEFI which recommend `newfs_msdos -F 32 -c 1`. When simply using `newfs_msdos /dev/...`, the change in `loader.env` actually did the trick (and I could also list files on the resulting FAT16 partition). Next, I discovered that I can create boot loader entries in Parallels Desktop's boot menu, so I did: {nav Add boot option > Select Partition > <efi> > BOOT > BOOTX64.efi} and set the following fields: ``` Input the description: FreeBSD Input optional data: rootdev=zfs:tank/root: ``` Again, this failed, even though the boot loader clearly echoed them back: ``` Command line arguments: rootdev=zfs:tank/root: ``` Looking at the code revealed that only arguments `[1..argc]` are parsed, which lead me to this little patch. I don't know enough about UEFI to understand if this is correct behavior or if this is actually a bug in Parallels Desktop. In case of the latter, this patch is moot.

This fixed a problem for me when working with Parallels Desktop 18's UEFI. To give some background: Old VM consisting of three HDDs, originally using legacy gptzfsboot. Two disks zpool, one disk swap. For reasons, disks can't be modified in size and the bootloader won't fit the original boot partitions anymore. Since Parallels seems to have issues with FreeBSD 12+ legacy boot (or vice versa) and moved to using EFI. Unfortunately, EFI boot wouldn't detect my root device automatically, but I could boot when setting it explicitly ``` set currdev=zfs:tank/root: load boot/kernel/kernel load boot/kernel/zfs.ko boot ``` Therefore I looked for a way to be able to set this variable somewhere else. Based on the sources and some search results, modifying `/efi/freebsd/loader.env` sounded promising, so I did this configuration: ```name=loader.env rootdev=zfs:tank/root: ``` Unfortunately, this didn't work. After adding some debug code to `loader.efi`, I learned that the `stat` call on the file fails (even though the loader seems to look at the correct partition). Also, looking at the partition's content from within the boot loader didn't work (`ls` said something like `/ file not found`). The EFI partition was formatted using FAT32, not sure if this is related or not (I didn't have time to test other formats yet). NOTE: When setting up the partition, I used the instructions from https://wiki.freebsd.org/UEFI which recommend `newfs_msdos -F 32 -c 1`. When simply using `newfs_msdos /dev/...`, the change in `loader.env` actually did the trick (and I could also list files on the resulting FAT16 partition). Next, I discovered that I can create boot loader entries in Parallels Desktop's boot menu, so I did: {nav Add boot option > Select Partition > <efi> > BOOT > BOOTX64.efi} and set the following fields: ``` Input the description: FreeBSD Input optional data: rootdev=zfs:tank/root: ``` Again, this failed, even though the boot loader clearly echoed them back: ``` Command line arguments: rootdev=zfs:tank/root: ``` Looking at the code revealed that only arguments `[1..argc]` are parsed, which lead me to this little patch. I don't know enough about UEFI to understand if this is correct behavior or if this is actually a bug in Parallels Desktop. In case of the latter, this patch is moot.