Date: Tue, 19 Dec 2017 22:10:55 -0700 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <markmi@dsl-only.net> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: UEFI booting survey Message-ID: <CANCZdfpb=z27MEOJsV46RWYtZCKQ-jd0yp0fOFs671yvRtYEMg@mail.gmail.com> In-Reply-To: <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net> 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> <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 19, 2017 at 9:06 PM, Mark Millard <markmi@dsl-only.net> wrote:
> [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:
> >
> >> . . .
> >> 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.)
> >>
> >> It is read. It is literally only used to set the root for userland.
> That is all. Nothing else.
> >>
> >> /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);
> >>
> >> 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.
> >>
> >> 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.)
> >>
> > 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.]
OK. Looks like the uboot code has the same bogus 'let's search everything'
code that I'm removing from the UEFI case. Still doesn't get anything from
/etc/fstab. It can't. There's no translation code in the boot loader to try
to guess. It just does a bruit force plow through all the devices and hopes
for the best.
> > /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.
>
Right, but that's not how ubldr finds them.
> For reference loader.config has:
>
> # more /mnt/boot/loader.conf
> geom_label_load="YES" # File system labels (see glabel(8))
> #
> kern.cam.boot_delay="10000"
> vfs.mountroot.timeout="10"
> dumpdev="/dev/da0p2"
>
> (So no vfs.root.mountfrom .)
What does config.txt have?
> 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.
You should try, but you may need one additional line to explicitly declare
things.
> 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.
I think this is more of the same bogus random order behavior that's making
your stuff word accidentally. Since ubldr is being phased out, I have no
plans to change it. But as someone that deploys systems with multiple
partitions that might be right, I hate random :(
Warner
> > Warner
> >>
> >> >> (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
>
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpb=z27MEOJsV46RWYtZCKQ-jd0yp0fOFs671yvRtYEMg>