When I set 'rootdev' environment variable in loader prompt, loader ignores the 'rootdev' environment variable and boots the OS according to the 'currdev' environment variable. I want to use rEFInd as follows. menuentry FreeBSD-release { loader /EFI/freebsd/loader.efi options "rootdev=disk0p5" icon /EFI/refind/icons/os_freebsd-release.png } menuentry FreeBSD-current { loader /EFI/freebsd/loader.efi options "rootdev=disk0p13" icon /EFI/refind/icons/os_freebsd-current.png }
loader.efi assumes rootdev is never set and always generates its own. That's bogus, as you point out.
Created attachment 195171 [details] patch for loader.efi 'rootdev' environment variable After applying this patch, setting the 'rootdev' environment variable starts OS from the 'rootdev' disk. And rEFInd works well with this loader.efi.
(In reply to Masachika ISHIZUKA from comment #2) And I confirmed that I can start zfs as follows using rEFInd. menuentry FreeBSD-zfs { loader /EFI/freebsd/loader.efi options "rootdev=zfs:tank/ROOT/default:" icon /EFI/refind/icons/os_freebsd-zfs.png }
I don't think your patch is quite right. https://reviews.freebsd.org/D16322 is better. It overrides our location of the default currdev if rootdev is in the env. Does this work for you?
A commit references this bug: Author: imp Date: Wed Jul 18 22:45:27 UTC 2018 New revision: 336463 URL: https://svnweb.freebsd.org/changeset/base/336463 Log: If rootdev is set, use it as currdev. Setting rootdev in the enviornment should specify things completely. If it is set, then have it override everything else. PR: 229770 Differential Review: https://reviews.freebsd.org/D16322 Changes: head/stand/efi/loader/main.c
(In reply to Warner Losh from comment #4) Thank you very much. It works perfect for me and I agree this patch is better.
Are there plans to include this patch with any FreeBSD release? I just tested the following: menuentry FreeBSD-11.3{ loader /efi/boot/fbsd_11.3.efi options "rootdev=disk0p13" } and menuentry FreeBSD-12.1{ loader /efi/boot/fbsd_12.1.efi options "rootdev=disk0p13:" } to no avail. fbsd_11.3.efi and fbsd_12.1.efi are the boot1.efi files included in 11.3-RELEASE and 12.1-RELEASE respectively. Tested with the file included with 12.0-RELEASE), did not work either. 'currdev' enviornmanet variable ends up being set to a default value in all cases: currdev=disk0p10: By the way, also tested with: menuentry FreeBSD-12.1{ loader /efi/boot/fbsd_12.1.efi options "currdev=disk0p13:" } same results. Setting currdev manually indeed does the trick.
Doesn't work in FreeBSD 13.0-release-p11 either. Tested with entries like these menuentry "FreeBSD 12" { icon /EFI/refind/icons/os_freebsd.png loader /EFI/freebsd/loader.efi options "rootdev=disk0p7" } in /boot/efi/EFI/refind/refind.conf. The entries show up in rEFInd, and I have verified that rEFInd picks up the rootdev variable (it does). Also tried with "rootdev=disk0p7:" doesn't change anything. A cursory check seems to indicate that loader should have support for rootdev root@kg-quiet:~ # strings /boot/efi/EFI/freebsd/loader.efi | grep rootdev uefi_rootdev rootdev Setting currdev to configured rootdev %s root@kg-quiet:~ # strings /boot/loader.efi | grep rootdev uefi_rootdev rootdev Setting currdev to configured rootdev %s root@kg-quiet:~ # strings /boot/loader_lua.efi | grep rootdev uefi_rootdev rootdev Setting currdev to configured rootdev %s but it doesn't work. Setting currdev manually works of course. Details: root@kg-quiet:~ # freebsd-version -ku 13.0-RELEASE-p11 13.0-RELEASE-p11 root@kg-quiet:~ # uname -a FreeBSD kg-quiet.kg4.no 13.0-RELEASE-p11 FreeBSD 13.0-RELEASE-p11 #0: Tue Apr 5 18:54:35 UTC 2022 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 root@kg-quiet:~ # ll /boot/efi/EFI/freebsd/loader.efi /boot/*.efi -r-xr-xr-x 1 root wheel 114176 Apr 9 2021 /boot/boot1.efi* -rwxr-xr-x 1 root wheel 896000 May 8 11:24 /boot/efi/EFI/freebsd/loader.efi* -r-xr-xr-x 1 root wheel 109056 Apr 9 2021 /boot/gptboot.efi* -r-xr-xr-x 2 root wheel 896000 Apr 9 2021 /boot/loader.efi* -r-xr-xr-x 1 root wheel 809984 Apr 9 2021 /boot/loader_4th.efi* -r-xr-xr-x 2 root wheel 896000 Apr 9 2021 /boot/loader_lua.efi* -r-xr-xr-x 1 root wheel 750080 Apr 9 2021 /boot/loader_simp.efi*
(In reply to Torfinn Ingolfsen from comment #8) Please see https://reviews.freebsd.org/D36457 1. In order for loader.env to work, it seems like the partition needs to be created using `newfs_msdos` and NOT `newfs_msdos -F32 -c 1` like https://wiki.freebsd.org/UEFI recommends. 2. loader.efi skips the first argument passed into it, so simply specifying the option a second time should make it catch on (and still work once the bug is fixed): menuentry "FreeBSD 13" { icon /EFI/refind/icons/os_freebsd.png loader /EFI/freebsd/loader.efi options "rootdev=disk0p7: rootdev=disk0p7:" }
(In reply to Michael Gmelin from comment #9) >1. In order for loader.env to work, it seems like the partition needs > to be created using `newfs_msdos` and NOT `newfs_msdos -F32 -c 1` > like https://wiki.freebsd.org/UEFI recommends. It turns out it's not quite as simple as that. I'm looking for a good way to reproduce this bug. It's a bug in msdos.c and independent of loader.env entirely. Once we have that, a new bug will be opened.
(In reply to Warner Losh from comment #10) >1. In order for loader.env to work, it seems like the partition needs > to be created using `newfs_msdos` and NOT `newfs_msdos -F32 -c 1` > like https://wiki.freebsd.org/UEFI recommends. See https://reviews.freebsd.org/D36482, it's basically a bug that only affects FAT32, but not all the time.