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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"
