Date: Tue, 19 Dec 2017 20:06:44 -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: <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net> In-Reply-To: <CANCZdfrJZC9cRAQ_5F5ynAy0hJSKrBA=vMMtsfVHbtUrPq%2BEcw@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> <F8D6B6DA-7B88-4238-8865-416F5D28F181@dsl-only.net> <CANCZdfrJZC9cRAQ_5F5ynAy0hJSKrBA=vMMtsfVHbtUrPq%2BEcw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[The usdcard in my rpi2 example does not contain any kernel files,
nor any dtb files. Only the USB SSD stick does. The kernel and dtb
do not come from the usdcard. This is what I'm not sure if it is
generally supported or not.]
On 2017-Dec-19, at 7:26 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Dec 19, 2017 4:26 PM, "Mark Millard" <markmi at dsl-only.net> =
wrote:
>=20
>> . . .
>> 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:
>>=20
>> /etc/fstab (redirecting to a USB SSD stick)
>> /boot/* (with /boot/kernel/ empty and /boot/dtb/ empty)
>>=20
>> 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:
>>=20
>> /boot/kernel
>> /boot/dtb/bcm2836-rpi-2-b.dtb
>> / (mounted root file system)
>>=20
>> 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.)
>>=20
>> It is read. It is literally only used to set the root for userland. =
That is all. Nothing else.=20
>>=20
>> /usr/src/stand/common/boot.c does show an explicit
>> attempt to find a /etc/fstab:
>>=20
>> # 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);
>> . . .
>>=20
>> That is from getrootmount(char *rootdev):
>>=20
>> int
>> getrootmount(char *rootdev)
>> {
>> char lbuf[128], *cp, *ep, *dev, *fstyp, *options;
>> int fd, error;
>>=20
>> if (getenv("vfs.root.mountfrom") !=3D NULL)
>> return(0);
>>=20
>> So if you set vfs.root.mountfrom in /boot/loader.conf, we don't read =
rootdev:/etc/fstab for the value to set vfs.root.mountfrom to.
>>=20
>> error =3D 1;
>> sprintf(lbuf, "%s/etc/fstab", rootdev);
>> if ((fd =3D open(lbuf, O_RDONLY)) < 0)
>> goto notfound;
>> . . .
>>=20
>> Supporting detail for the example rpi2
>> boot context:
>>=20
>> With /mnt being the / from the usdcard:
>>=20
>> # 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
>>=20
>> # more /mnt/etc/fstab
>> /dev/da0p1 / ufs rw,noatime 1 1
>> /dev/da0p2 none swap sw 0 0
>>=20
>> 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.)
>>=20
> So you load /boot/loader and the kernel from the sdcard.
No: There are no kernel files on the usdcard. See the complete
file list of its only UFS partition above. No dtb files either.
[On a rpi2 ubldr.bin is copied to the msdosfs, where it
is actually put to use.]
> /etc/fstab on the card points to the usb drive for /.
True. And that is were the kernel and dtb come from,
not the usdcard.
For reference loader.config has:
# more /mnt/boot/loader.conf
geom_label_load=3D"YES" # File system labels (see glabel(8))
#
kern.cam.boot_delay=3D"10000"
vfs.mountroot.timeout=3D"10"
dumpdev=3D"/dev/da0p2"
(So no vfs.root.mountfrom .)
> This is all standard loader behavior.
I'm not sure avoiding the kernel and dtb being on the usdcard
is standard-supported behavior. It might be a lucky,
limited-context accident rather than a general property as a
technique.
> It won't change. In your case, you aren't even using UEFI, so it =
doubly won't change.
I also have access to an rpi3 and a pine64+ 2GB, which are
UEFI based. But I'd not yet tried a similar configuration
to what I'd recently done on the rpi2 V1.1 .
The list notices made me unsure if I should even try. It
is this part that I'm trying to figure out, both for now
and for after the changes.
> UEFI has more direct ways of doing this, but this setup would work =
there because it is explicit. It doesn't depend on the current boot1.efi =
behavior...
The lack of depending on the "random order" status may well
be true.
But I'm still not sure if the the lack of a kernel and dtb
file on the usdcard puts the technique out of bounds for
the rpi2 and pine64+ 2GB.
> Warner
>>=20
>> >> (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.
>> >>
>> >
>=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?2822699E-DDD5-4604-8567-974AE30659A3>