UEFI booting survey

[Mark Millard]

On 2017-Dec-19, at 1:49 PM, Warner Losh <imp at bsdimp.com> wrote:

> 
> 
> On Dec 19, 2017 10:58 AM, "Mark Millard" <markmi at dsl-only.net> wrote:
>> On 2017-Dec-18, at 2:37 PM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> > . . .
>> >
>> > Or the following pseudo-code with all the weird special cases removed for clarity
>> >
>> > load loader.efi from ESP
>> > if BootXXXX uefi variable holds a second path, use that for root/kernel
>> > otherwise if an override variable holds a kernel/root path, use that
>> > otherwise scan for a usable ZFS pool, use that if it exists
>> > otherwise use the same partition loader.efi was booted from for root/kernel if it's usable
>> > otherwise use the first UFS partition on the ESP that's usable.
>> >
>> > A partition is usable if /boot/loader.rc exists on that path.
>> 
>> What will be the role of /etc/fstab in establishing
>> were the kernel is loaded from? Where world is
>> loaded from? Where/how does use of /etc/fstab for
>> specifying the root file system mount fit in the
>> above pseudo-code?
> 
> Same as today: it is what the boot loader passes to the kernel as the Unix name of /. I have no plans to change that. It's of almost no use to the boot loader, since it can't know what BIOS device da3 is, for example, if that's in fstab. Or even more complex examples like /dev/mirror/primary. Efibootmgr can take Unix devices and paths and turn them into UEFI paths so we know what devices to use for what. In the absence of those, or an equivalent fallback, we are quite limited in what we can do since we don't have the context needed to translate.
> 
> Warner 

Okay.

It sounds different then the results I get with ubldr.bin
on a rpi2 V1.1 . With the usdcard having a UFS / with
basically only:

/etc/fstab (redirecting to a USB SSD stick)
/boot/* (with /boot/kernel/ empty and /boot/dtb/ empty)

the result is that all 3 of the following come from the
USB SSD stick based on the "/" line from the /etc/fstab
from the usdcard:

/boot/kernel
/boot/dtb/bcm2836-rpi-2-b.dtb
/ (mounted root file system)

In other words: it appears that for ubldr.bin on
a rpi2 V1.1 /etc/fstab is read and used before
finding the kernel that is to be loaded. (It or
another /etc/fstab may be read again later.)

/usr/src/stand/common/boot.c does show an explicit
attempt to find a /etc/fstab:

# grep -r /etc/fstab /usr/src/stand/
. . .
/usr/src/stand/common/boot.c: * Try to find the /etc/fstab file on the filesystem (rootdev),
/usr/src/stand/common/boot.c:    sprintf(lbuf, "%s/etc/fstab", rootdev);
. . .

That is from getrootmount(char *rootdev):

int
getrootmount(char *rootdev)
{
    char        lbuf[128], *cp, *ep, *dev, *fstyp, *options;
    int         fd, error;

    if (getenv("vfs.root.mountfrom") != NULL)
        return(0);
            
    error = 1;
    sprintf(lbuf, "%s/etc/fstab", rootdev);
    if ((fd = open(lbuf, O_RDONLY)) < 0)
        goto notfound;
. . .

Supporting detail for the example rpi2
boot context:

With /mnt being the / from the usdcard:

# find /mnt -print | more
/mnt
/mnt/.snap
/mnt/boot
/mnt/boot/defaults
/mnt/boot/defaults/loader.conf
/mnt/boot/dtb
/mnt/boot/firmware
/mnt/boot/kernel
/mnt/boot/modules
/mnt/boot/zfs
/mnt/boot/msdos
/mnt/boot/entropy
/mnt/boot/menu.rc.sample
/mnt/boot/ubldr
/mnt/boot/ubldr.bin
/mnt/boot/brand-fbsd.4th
/mnt/boot/logo-beastie.4th
/mnt/boot/logo-beastiebw.4th
/mnt/boot/logo-fbsdbw.4th
/mnt/boot/logo-orb.4th
/mnt/boot/logo-orbbw.4th
/mnt/boot/loader.conf
/mnt/boot/loader.efi
/mnt/boot/boot1.efi
/mnt/boot/boot1.efifat
/mnt/boot/beastie.4th
/mnt/boot/brand.4th
/mnt/boot/color.4th
/mnt/boot/check-password.4th
/mnt/boot/delay.4th
/mnt/boot/frames.4th
/mnt/boot/loader.4th
/mnt/boot/loader.help
/mnt/boot/menu.4th
/mnt/boot/menu-commands.4th
/mnt/boot/menusets.4th
/mnt/boot/screen.4th
/mnt/boot/shortcuts.4th
/mnt/boot/support.4th
/mnt/boot/version.4th
/mnt/boot/loader.rc
/mnt/boot/efi.4th
/mnt/boot/pcibios.4th
/mnt/boot/menu.rc
/mnt/etc
/mnt/etc/fstab
/mnt/COPYRIGHT
/mnt/lost+found

# more /mnt/etc/fstab
/dev/da0p1      /               ufs     rw,noatime      1 1
/dev/da0p2      none            swap    sw              0 0

May be this is somehow special to the rpi2 or to
ubldr.bin operation. (I've never managed to identify
accidents from deliberately working status in this
area.)


>> (For my particular interest the context uses UFS, not
>> ZFS.)
>> 
>> > What is being deleted is one final step: "otherwise use the first UFS partition on any drive in a random order that's usable." which used to be at the end of the boot1.efi psuedo code. It's my belief that no such installations actually use this due to the random factor today (plug in a new USB drive and it might take over). If my belief is wrong, it's my belief that efibootmgr will solve it, and failing that, the fallback mechanism (for platforms that use u-boot + EFI where UEFI variables don't work) will allow the two or three people that are doing this today.
>> 
> 

===
Mark Millard
markmi at dsl-only.net