Date: Tue, 19 Dec 2017 15:26:38 -0800 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: UEFI booting survey Message-ID: <F8D6B6DA-7B88-4238-8865-416F5D28F181@dsl-only.net> In-Reply-To: <CANCZdfqFFZ-H1dYq0wV%2BGbfuxuXhfWWLVUEnmH2mZQJP7eoOig@mail.gmail.com> References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> <CANCZdfo5=5vKZ2cY8k7K3L%2BbfEPQREr9yB=EsVPiMkAStCq_SA@mail.gmail.com> <DC81F8EE-FE36-4B4B-8A51-B9C0D7D6B727@dsl-only.net> <CANCZdfqFFZ-H1dYq0wV%2BGbfuxuXhfWWLVUEnmH2mZQJP7eoOig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Dec-19, at 1:49 PM, Warner Losh <imp at bsdimp.com> wrote:
>=20
>=20
> 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:
>>=20
>> > . . .
>> >
>> > 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.
>>=20
>> 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?
>=20
> 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.
>=20
> Warner=20
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") !=3D NULL)
return(0);
=20
error =3D 1;
sprintf(lbuf, "%s/etc/fstab", rootdev);
if ((fd =3D 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.)
>>=20
>> > 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.
>>=20
>=20
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8D6B6DA-7B88-4238-8865-416F5D28F181>