From owner-freebsd-current@freebsd.org Tue Dec 19 23:26: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 1708AE82649 for ; Tue, 19 Dec 2017 23:26:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-134.reflexion.net [208.70.210.134]) (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 CDEB771029 for ; Tue, 19 Dec 2017 23:26:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17912 invoked from network); 19 Dec 2017 23:26:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Dec 2017 23:26:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 19 Dec 2017 18:26:40 -0500 (EST) Received: (qmail 30608 invoked from network); 19 Dec 2017 23:26:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Dec 2017 23:26:40 -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 76897EC814E; Tue, 19 Dec 2017 15:26:39 -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 15:26:38 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: 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: Tue, 19 Dec 2017 23:26:48 -0000 On 2017-Dec-19, at 1:49 PM, Warner Losh wrote: >=20 >=20 > On Dec 19, 2017 10:58 AM, "Mark Millard" = wrote: >> On 2017-Dec-18, at 2:37 PM, Warner Losh 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