From owner-freebsd-current@freebsd.org Wed Dec 20 05:10:57 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 246E4E94B12 for ; Wed, 20 Dec 2017 05:10:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D83F87D17D for ; Wed, 20 Dec 2017 05:10:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id o130so10347697itg.0 for ; Tue, 19 Dec 2017 21:10:56 -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=66iUtA7EjRro/X0r/trabdaSLEbHvAJ/XxU45/KRItQ=; b=byov64lambkshbjM5d9/fny8tcAbgD5TZuTFRkTlCK7t6uqhxC2pbZ+Ir7KtUwQalB kdfgX8oJTC7/DsjRpU78dPkbVZ3pRvKf6oRXdbzZgCvVrvXYIgGgNZo7f/kySAYHJx/R j2j4P+4zMj5GAYF4BauPakwZ5SErL43Y7Mm4okLmRKy9GMeGBjPUW4/ARkgmBeRaXg5s C7nwmhEo662ZwD4veaGZTyIY77yV5R3qJAxVD1EygJLtbwE4C1H9g+z9cFCpMtyd/aeK SnlYre/0mxaWzdN3YJqiJuQeCs7cmtmwpwml0Dsy6XsunJ8yT9Su4Xbm5qrXnqXOKdgu aL1g== 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=66iUtA7EjRro/X0r/trabdaSLEbHvAJ/XxU45/KRItQ=; b=VTFCYkHOVsZi5ZbWF8+8RXxKA5W4/vdgW9KvrNv5JNKUHGdKFYM06Cd/FjVSfP7kq9 U2XDRLOsJNZzU/nkyruNrKOYrQ1XouzeQ7NQfjZsRwfovsC23Xl5uB+K0MFG/dx/iS3R uplaGRHf6rNVb12yVvGX1uH5mFipMDei5xptwcZ99pukCZsLjVLXqdBrCjoi5/CUBRMR K9EWVBWS6wFAruHfxxdIvryAphStu1/e6s0BYzq5Av0Q5goT+bdQKDdpO1hxWkDT4CGT 3ciq4ftFB+K9ElSyiQr3SG7CVkdf6c7GdPOS809FWa4qbU7A5wQeGkhGVOPnX7p/M0nW DOJg== X-Gm-Message-State: AKGB3mKupWwW+hvv/aiI9cgLpemKc2NjGQbrPiu8Dra05KNbIZ/lClTq Ymf3/bODqZD5U/DuGB+uIc8QND/802zQDnEgU3p/Gg== X-Google-Smtp-Source: ACJfBosZ2ONdQOgZHW9sokVHP83+dRgtWghXE8iMn+sQi0BjlXp1j8hUFtGVCEt0NKDXC2fR1wAJ4iaL3XcmhwZ4Fxc= X-Received: by 10.36.147.193 with SMTP id y184mr5949294itd.64.1513746655838; Tue, 19 Dec 2017 21:10:55 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 21:10:55 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net> References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net> From: Warner Losh Date: Tue, 19 Dec 2017 22:10:55 -0700 X-Google-Sender-Auth: jJerIq6oz1EA9ObODVosODfT5nA 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 05:10:57 -0000 On Tue, Dec 19, 2017 at 9:06 PM, Mark Millard 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 wrote: > > > On Dec 19, 2017 4:26 PM, "Mark Millard" 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 > > > >