From owner-freebsd-current@freebsd.org Wed Dec 20 04:06:48 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D15B6E9174E for ; Wed, 20 Dec 2017 04:06:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F7DC7B543 for ; Wed, 20 Dec 2017 04:06:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12475 invoked from network); 20 Dec 2017 04:06:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Dec 2017 04:06:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 19 Dec 2017 23:06:46 -0500 (EST) Received: (qmail 25739 invoked from network); 20 Dec 2017 04:06:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Dec 2017 04:06:46 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8D2F3EC928E; Tue, 19 Dec 2017 20:06:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: UEFI booting survey From: Mark Millard In-Reply-To: Date: Tue, 19 Dec 2017 20:06:44 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net> References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 04:06:48 -0000 [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 wrote: > On Dec 19, 2017 4:26 PM, "Mark Millard" = 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