From owner-freebsd-current@freebsd.org Wed Dec 20 03:26:36 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 4B62BE8F710 for ; Wed, 20 Dec 2017 03:26:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10BE079D61 for ; Wed, 20 Dec 2017 03:26:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id v186so15799233iod.7 for ; Tue, 19 Dec 2017 19:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7H5CSoipK2OCJk7WTt9mUpZ2u98gh9wAY8gMdO/Pfwk=; b=bNHkba4X6wS9OKwWo4s32xOWgA40X6zOvDZzDo8G57MbKaGa4Mys7cSHeC7bl2Rs6Q 6qEq61K99b/0Di/JkVPu2nIrX3fJ+YbGO01V5cm4Sc6Y8siuPgLcsr6y5UiBTSmoL5Nk BQCcf8sT52f4keb9lTysyO8gyVNOyKEDvwKBHSUhvfhpA5fY/J2vrX4eUZe1VPX5fLfX 6XabuwNDOB2qk+VUjAtHAtWXxmoly8m95aBNPSWqm3/4HRJpBCQkegDe56URua5yRAN9 vyqJ7xw6JZIQVzas9Hs4nTD68/2xYpeTVeKgTPZfHUAjroF0IpWl4f4yfOl7sna/wIwv TeKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7H5CSoipK2OCJk7WTt9mUpZ2u98gh9wAY8gMdO/Pfwk=; b=nFqdVgOyvicrmoU2rMS+tuV6OP/X9of+ffyuylD5FKMucE5ZJ26IEvQkt1FEdv4AVo Zbj873GPMnVmJLfslpPEl/1uqWBqWF28xN7YYFGZfntcmz3L3Z0Pe1BVikhV2b7cOA3Q e993DT3Gd9KOuoCCMDoycDn5K8OoMkFDN1Q/yNREl0MstZNhZEwzLCCeGPer9MemkaaO J4TJBY71Xa7+MEyuhvw5XIuqKvoQVo6wRwaku9to9dWDFKtripQDOUzvH+kixGQu+47q r1T59JS1kfbvmoQdc+kISzDWjUYYYilmD9qxUvhTPM1S8JN8e78dEJAb+BucPrEaWmOV bOUg== X-Gm-Message-State: AKGB3mKPypjoY+jJST67ZPJvhDnN+5aYe+xmfks6o0GZRAQvV+EPCGA3 f6n2KUIwmCvy4QIFGTFLcvsAmQ4F2XYgmvCgwapCQg== X-Google-Smtp-Source: ACJfBouSLFNHfu4rtcxT1jegh6/F1wmqCdNey2dJSkJJC5Tece8fM5AvWL3FC6z5IEBu3UI6FQO7GfM2oVoyCRaGz/8= X-Received: by 10.107.18.35 with SMTP id a35mr2608727ioj.291.1513740395106; Tue, 19 Dec 2017 19:26:35 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 19:26:34 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:98:d01c:605a:60d4] Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 19:26:34 -0800 (PST) In-Reply-To: References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> From: Warner Losh Date: Tue, 19 Dec 2017 20:26:34 -0700 X-Google-Sender-Auth: Sf8JNpKJmVFb3MIxFCk4ZWHgRMA Message-ID: Subject: Re: UEFI booting survey To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 03:26:36 -0000 On Dec 19, 2017 4:26 PM, "Mark Millard" wrote: On 2017-Dec-19, at 1:49 PM, Warner Losh wrote: > > > On Dec 19, 2017 10:58 AM, "Mark Millard" wrote: >> On 2017-Dec-18, at 2:37 PM, Warner Losh wrote: >> >> > . . . >> > >> > 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. >> >> 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? > > 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. > > Warner 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.) 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. /etc/fstab on the card points to the usb drive for /. This is all standard loader behavior. It won't change. In your case, you aren't even using UEFI, so it doubly won't change. 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... 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