From owner-freebsd-current@freebsd.org Sun Dec 17 04:24:18 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 6649CEA09F6 for ; Sun, 17 Dec 2017 04:24:18 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 374192171 for ; Sun, 17 Dec 2017 04:24:18 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x235.google.com with SMTP id r4so8862109ybd.12 for ; Sat, 16 Dec 2017 20:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Fg6acsijBM/HNUfOMYap5YhStkq/2+bpcQG0XknqwRo=; b=STma4KWflvuUZZ7KdTb3ObPAfmBS4LXQLWJVy3mytV04Qey/A606tDl2wm1JE8nAp0 IbPHTP0lt4cKhuX6kUA8ZG1cRKiznZ+ovkGk3mVpBlXEju/M7uRzp5RFXnDRLxuATFwe bBDs4uA6JrsTUVCyyV/TNQ+2c/9KB4KLj7TaM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Fg6acsijBM/HNUfOMYap5YhStkq/2+bpcQG0XknqwRo=; b=B7MHa6thqqSB/Vz28U6KI+CBX3itW7bj63LAaNMgI9L44QQhmMOA0WHNT8/ojADk0f TDaUfMzDs+ljVw/OOOYObBUhvH8GGlnzX2584R72z2tkoaJixJIkqnABNcvwI6RjrztI fXIpu3NKEFO48s/qtaI81B4nTRVzvaQZZCEAyjBo2KVOVFp3fSo23l46aPnBH7bBBOkt UOtsM+EMcb/puD/F/aFDC+LzzD6vjgB7EjGLDoeVh4/jJ3zDc9EvLeIQn9Fsiz52QFU3 M9PQMIXbYivOnf3Kj5tfA1++AM4kXJcW84kLPylnpOHdd1eeZhI4vA4t0+AfIumnLExK fwgg== X-Gm-Message-State: AKGB3mJzGYmZeKpeIxBaFLRp4beDMXV4s++uENZU7tzuXEEUttQfLKyt 96BNMsjfzXT6Ojot7VpXz+rLqKDKcBpMiixPZeQ3tg== X-Google-Smtp-Source: ACJfBov1TWbr106NV4+H5u2ceRDxhTWY1YUCI/Kv88w/W4XhTGP9HdSG9w70ZfSFmjfrcMNWesraryHOC58nRIXMXy0= X-Received: by 10.129.122.194 with SMTP id v185mr11202497ywc.204.1513484657178; Sat, 16 Dec 2017 20:24:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.15.66 with HTTP; Sat, 16 Dec 2017 20:23:46 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Sat, 16 Dec 2017 20:23:46 -0800 Message-ID: Subject: Re: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/) To: Mark Millard Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sun, 17 Dec 2017 04:24:18 -0000 On 16 December 2017 at 10:47, Mark Millard wrote: > I got a "swap_pager: indefinite wait buffer" notice and looked > it up. (This was on a rpi2 booted (kernel and world) from a > USB SSD, swap partition in use instead of a swap file. It > was building devel/cmake via poudriere-devel .) > > https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffer > reads like it is for page-out to disk: > > > QUOTE > 5.9. > > What does the error swap_pager: indefinite wait buffer: mean? > > This means that a process is trying to page memory to disk, and the page = attempt has hung trying to access the disk for more than 20 seconds. It mig= ht be caused by bad blocks on the disk drive, disk wiring, cables, or any o= ther disk I/O-related hardware. If the drive itself is bad, disk errors wil= l appear in /var/log/messages and in the output of dmesg. Otherwise, check = the cables and connections. > ENDQUOTE > > > But the code containing the message is for "swread": > (head -r326888) If I understand correctly this is fixed by change "trying to page to" to "trying to page from" ? In other words this happens on swap-in, not swap-out. --=20 Eitan Adler From owner-freebsd-current@freebsd.org Sun Dec 17 04:41:44 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 EF739EA16CF for ; Sun, 17 Dec 2017 04:41:44 +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 94C022C46 for ; Sun, 17 Dec 2017 04:41:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15937 invoked from network); 17 Dec 2017 04:34:57 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Dec 2017 04:34:57 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Dec 2017 23:34:57 -0500 (EST) Received: (qmail 4223 invoked from network); 17 Dec 2017 04:34:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Dec 2017 04:34:57 -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 B8E14EC7B46; Sat, 16 Dec 2017 20:34:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/) From: Mark Millard In-Reply-To: Date: Sat, 16 Dec 2017 20:34:56 -0800 Cc: FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <8D8CFFA3-ADE9-402F-B9A1-C311E4244FCB@dsl-only.net> References: To: Eitan Adler 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: Sun, 17 Dec 2017 04:41:45 -0000 On 2017-Dec-16, at 8:23 PM, Eitan Adler wrote: > On 16 December 2017 at 10:47, Mark Millard = wrote: >> I got a "swap_pager: indefinite wait buffer" notice and looked >> it up. (This was on a rpi2 booted (kernel and world) from a >> USB SSD, swap partition in use instead of a swap file. It >> was building devel/cmake via poudriere-devel .) >>=20 >> = https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffer >> reads like it is for page-out to disk: >>=20 >>=20 >> QUOTE >> 5.9. >>=20 >> What does the error swap_pager: indefinite wait buffer: mean? >>=20 >> This means that a process is trying to page memory to disk, and the = page attempt has hung trying to access the disk for more than 20 = seconds. It might be caused by bad blocks on the disk drive, disk = wiring, cables, or any other disk I/O-related hardware. If the drive = itself is bad, disk errors will appear in /var/log/messages and in the = output of dmesg. Otherwise, check the cables and connections. >> ENDQUOTE >>=20 >>=20 >> But the code containing the message is for "swread": >> (head -r326888) >=20 > If I understand correctly this is fixed by change "trying to page to" > to "trying to page from" ? In other words this happens on swap-in, > not swap-out. That is my understanding of what I reported. Side note comparing with rpi2 (armv7, cortex-A7): A rpi3 (aarch64, cortex-A53) got a couple of the messages during a build of the same port: devel/cmake . In this case it is emmc attached to the microsd-card slot via an adapter, instead of a USB SSD stick. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Dec 17 07:52:17 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 4280CE8202F; Sun, 17 Dec 2017 07:52:17 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 01A3467BFE; Sun, 17 Dec 2017 07:52:17 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-it0-x229.google.com with SMTP id u62so25110887ita.2; Sat, 16 Dec 2017 23:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qLtKkYsJxbBYZ1R8Ck+GbDEbiQ/WBfB0LwNqLxKzl4U=; b=oVq9lkcO7dJYLxUDS3Iy1iQ6p1OISPLT2ezO0l2lNbj8a2vQPQWObV98SlPc3pm9hk 9FjPVwgwP7Au/BxR2NrYMl1twDeiW4ZJBwn0n1cL/cJCxGPmlUqb+xAfnQppN+iWijBU mYneXeJVDE8VhPmaLK/2oYAv5wJX8QmJT9BRjA3Il6L0oq7aLaz9KGVE1NyDY0ApD/V2 y8dJdjwBWQ2n/ZlYcRmMdxIRXNaPvi/MO+KC7xnYkpwcxB/+GJPDv8T8ieUibWAXFbdf 8frz3Eb6gas/I9wdZBxNXFcaex1vtp+FOh4YQhzSw1mVu8Ve22LKKau7IDEhoYIaJq9s gaqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qLtKkYsJxbBYZ1R8Ck+GbDEbiQ/WBfB0LwNqLxKzl4U=; b=AMe3b0dLDYLoivV8wZLhDNe/jdbMwH336y8nBbpLpRZPAwRqy9kZwmFAURKOGFwMWZ jdSf8CtLR/XRy7TBaD5rGQxJ+Nzx4NreiVuxCGSK4jxJLooPmeSQbH5djLlKHVM5KVOO mpyimkLRtmXgJpBNUOBRzZctZmquox4u0c9FP6NOQ2zmHl8zD/1cNAQkxD1/RYT5xVro zcJriVERu8524eHoRZBMKj/ejDcgNyiUiwXtQv+aDGYgndyB6Qsw0ERsM6/In9Z80bny 8hwmJyKUAVhxQmUz7cbKnsxYHVJatdPF7mMiUv8SbX3ETeNU0tYFMxUwPpxqMFWDEvAz e3OQ== X-Gm-Message-State: AKGB3mLeDk22nEIygmODhd0LmsWf/eO/QfTelypQ4YbAWhH3Q5fqdRhJ 5QZUM0zg+oVrFfg7/jlH7Ba9iDX39eJZAxqgrAY= X-Google-Smtp-Source: ACJfBot5Uj/kR8IBsCYu85nXRqUpT2DImRtruLCt8iwyVIs8HoFjCsYw2YuJM7cX24FmA1mKENX49L6U+z+JSZFQUaE= X-Received: by 10.36.131.200 with SMTP id d191mr15476180ite.97.1513497136118; Sat, 16 Dec 2017 23:52:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.144.71 with HTTP; Sat, 16 Dec 2017 23:52:15 -0800 (PST) Received: by 10.2.144.71 with HTTP; Sat, 16 Dec 2017 23:52:15 -0800 (PST) In-Reply-To: References: From: Sami Halabi Date: Sun, 17 Dec 2017 09:52:15 +0200 Message-ID: Subject: need help using ng_patch to modify src/dst packets or alternative way To: freebsd-net@freebsd.org, 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: Sun, 17 Dec 2017 07:52:17 -0000 hi, Can you help in my situation? My goal is so Box in my lan 10.1.1.2 to talk to 10.1.1.1 and actually it would be talking to X.X.X.X outside ip using one of my public IPs say 1.1.1.1. I'm trying to modify packets to passthrough to a local IP. I have a box that a specific IP is routed to it.. say 1.1.1.1 in my bce0 i don't have that ip configured but i have my public IP that say 2.2.2.2 that 1.1.1.1 is routed to it. i configured 10.1.1.1/24 in bce0, my target box is 10.1.1.2/24. i tried the following inside ngctl: mkpeer ipfw: patch 300 in name ipfw:300 src_dst_chg msg src_dst_chg: setconfig { count=2 csum_flags=1 ops=[ { mode=1 value=0x0a010101 length=4 offset=3 } { mode=1 value=0x0a010102 length=4 offset=4 } ] } in my box(10.1.1.1) i did: sysctl net.inet.ip.fw.one_pass=0 /sbin/ipfw add 50 netgraph 300 ip from any to any to 1.1.1.1 then i do simple ping from outside box i see the packets arrive on my 160 rule but never leaves the box.. I would at least see packeta flow one direction to 10.1.1.2 and then that need another ipfw and netgraph opposite rule. If you have alternative way I'm happy to try... Help much appreciated... Sami From owner-freebsd-current@freebsd.org Sun Dec 17 10:59:27 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 39B24E85B19; Sun, 17 Dec 2017 10:59:27 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 DDDA16C4CB; Sun, 17 Dec 2017 10:59:26 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-it0-x230.google.com with SMTP id d137so24631392itc.2; Sun, 17 Dec 2017 02:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IsRX8m3q8HkLj0DYOG7YFnXmJSWDwlRV1L+Sex6URxE=; b=nO7QYSMBqma3wRuvtc5YMGE7EGh+E+MPjdr2RGEHjlJPIYnjXOa4QxOJcK8STBg2Ut 1ToQgsmUxtCV8MJH9V2anCHGzZ0lqvgei+lq1/zsl8R/3Ha5ddwVlQ1YHkKo94JuIaH+ v8FHYhGbGBgSmmgVSNyKfFseYLlNgWbzDhzgr1nBb+henutsSqIZJVogj0sfz6f+DTFR 2K7wjHbHPzRfXX3b1VAcNiPsUa7lLOJyqtehvTJDNS6BBC8esEhlZHt28JsPjPww6ygP 4QulfNgrGegds4rYpNf08bbD7qtFJYUVF9YGqryUTUFr/Gd5CV3e2J15voGyFnESmIN4 QIeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IsRX8m3q8HkLj0DYOG7YFnXmJSWDwlRV1L+Sex6URxE=; b=KaFCW2O2QvTBk+rt/BnK0uh79EoG+BkMsttGLb/TjKSlD/eunVGQR2ovSqyG1Gdmh4 ejqxsOMAKW0BQCeBoJRZ/LVvBuahyIyrVMzZU7ElNx9IA/qBzQ9DuorJBrgon1zPWbpV 2Ir7uwuKHWuO4oW+sZWsKVc8xJa6L+qGxdWE6XAx+dJ2rIyZeQYRlBQ+4tYUeJxaMkG9 eYKcBeKZmxqXZECDsG0OPk6cqXvlgoV43sFnRBCFQBaYRxHhA3ReRz8JcJzwiAfzC4bs FJrkumJNiYxcmz+6HqroQcyKBaUr20v3BSt3BqPWA2Si8NWI1i7xl8xzvmZgMECyT5YB X+Lw== X-Gm-Message-State: AKGB3mI84VvyPb1OtD9eCNtcQrF9U2gxkJ5NeAR7NuyIQm4YhP1UtQYZ QyqBhZ+pkMawuLCvrUTTFMDQi4zaIaLkXw7CxxM= X-Google-Smtp-Source: ACJfBov5O64XilvXpoQ3tVbY/x0tdGU6VavAyjzl2r2h4dX9l3/j5IA4E2GKX/lvpTZs4Z0LZmAaywhRnFh4phEDKLQ= X-Received: by 10.36.133.135 with SMTP id r129mr16758271itd.69.1513508366204; Sun, 17 Dec 2017 02:59:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.144.71 with HTTP; Sun, 17 Dec 2017 02:59:25 -0800 (PST) Received: by 10.2.144.71 with HTTP; Sun, 17 Dec 2017 02:59:25 -0800 (PST) In-Reply-To: <5A3638E5.6090308@grosbein.net> References: <5A3638E5.6090308@grosbein.net> From: Sami Halabi Date: Sun, 17 Dec 2017 12:59:25 +0200 Message-ID: Subject: Re: need help using ng_patch to modify src/dst packets or alternative way To: Eugene Grosbein Cc: freebsd-net@freebsd.org, FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sun, 17 Dec 2017 10:59:27 -0000 Hi Eugene, I'm looking for a solution for IP traffic. in linux iptables its possible but I couldn't find freebsd way yet. bkuncr soulution works for tcp only. Thanks for the hint though, Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 17 =D7=91=D7=93=D7=A6=D7=9E=D7=B3 2017= 11:29 AM,=E2=80=8F "Eugene Grosbein" =D7=9B=D7=AA=D7= =91: > 17.12.2017 14:52, Sami Halabi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > hi, > > > > Can you help in my situation? My goal is so Box in my lan 10.1.1.2 to > talk > > to 10.1.1.1 and actually it would be talking to X.X.X.X outside ip usin= g > > one of my public IPs say 1.1.1.1. > > If you need this just for single or several tcp ports, easiest way > is to use any of port forwarders/bouncers like this: > > pkg install bounce > bounce -a 10.1.1.1 -b 1.1.1.1 -p 443 X.X.X.X 443 > > > From owner-freebsd-current@freebsd.org Sun Dec 17 14:47:35 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 DD81DE8B7CA for ; Sun, 17 Dec 2017 14:47:35 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA29A7267A for ; Sun, 17 Dec 2017 14:47:35 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1513522053; bh=vtItktc75nc/n08aV1gBZrEz9Jl6jA1prSqqoT6 iw+I=; b=lKKPYVVRDm0jH8MMcyHYl3aJqqARpbuTnSLEshep6Y4m/PluvT+MlaV /Ue3z1NRH2K0AT+L2LlXxFGgaBxtnkXdCCnox1r0NK87djPY5js4RowoiKVelvg/ 7/lwp4MykLgz/yuwH3V74EfFsKOTg1dL2md8kfzVE6r10HZ6IWPI= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 6B61A94F2 for ; Sun, 17 Dec 2017 09:47:33 -0500 (EST) To: freebsd-current From: Michael Butler Subject: what's changed with newsyslog? Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: <7c79c676-3414-8cab-bcf8-b3e3d08a70f6@protected-networks.net> Date: Sun, 17 Dec 2017 09:47:32 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Sun, 17 Dec 2017 14:47:36 -0000 In the past week or so I've been getting warnings like this .. bzip2: Can't open input file /var/log/snmpd.log.0: No such file or directory. newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0 /var/log/fwlw_clean_log.0' terminated with a non-zero status (1) I've checked the relevant /etc/newsyslog.conf and its /usr/local/etc counterpart to ensure there are tabs in the right places but the errors persist. Similarly, the relevant files are there and seem to be rotated as expected/desired .. -rw-r--r-- 1 root wheel 77 Dec 17 09:00 fwlw_clean_log -rw-r--r-- 1 root wheel 11282 Dec 17 09:00 fwlw_clean_log.0.bz2 -rw-r--r-- 1 root wheel 9452 Dec 17 05:00 fwlw_clean_log.1.bz2 [ .. ] -rw-r--r-- 1 root wheel 50992 Dec 17 09:45 snmpd.log -rw-r--r-- 1 root wheel 1834 Dec 17 09:00 snmpd.log.0.bz2 -rw-r--r-- 1 root wheel 1846 Dec 17 07:00 snmpd.log.1.bz2 Hints? imb From owner-freebsd-current@freebsd.org Sun Dec 17 18:42:49 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 48296E91C23; Sun, 17 Dec 2017 18:42:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B04AB79B9D; Sun, 17 Dec 2017 18:42:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBHIgXNO069873 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 Dec 2017 19:42:33 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: sodynet1@gmail.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vBHIgOV7039505 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Dec 2017 01:42:25 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: need help using ng_patch to modify src/dst packets or alternative way To: Sami Halabi References: <5A3638E5.6090308@grosbein.net> Cc: freebsd-net@freebsd.org, FreeBSD Current From: Eugene Grosbein Message-ID: <5A36BA90.8020302@grosbein.net> Date: Mon, 18 Dec 2017 01:42:24 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Mailman-Approved-At: Sun, 17 Dec 2017 18:52:33 +0000 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: Sun, 17 Dec 2017 18:42:49 -0000 17.12.2017 17:59, Sami Halabi wrote: > Hi Eugene, > I'm looking for a solution for IP traffic. in linux iptables its possible but I couldn't find freebsd way yet. > bkuncr soulution works for tcp only. Then, you need to realize that for every packet, you need to change (translate) both of source IP address from 10.1.1.2 to 1.1.1.1 and destination IP address from 10.1.1.1 to X.X.X.X. This is called network address translation and, in fact, you need NAT. But not ordinary "simple" NAT that translates only source address in outgoing packets (and destination in incoming replies) but double or "binat" to translate destination address in outgoing packets too (and source address in corresponding replies). This is possible to do with two instances of "ipfw nat" (or natd) for single external destination but not for arbitrary number of external destinations. They say, "pf(4)" packet filter can perform "binat" properly. I have not tried that. You should start reading its documentation. From owner-freebsd-current@freebsd.org Sun Dec 17 19:48:41 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 591F2E93A09 for ; Sun, 17 Dec 2017 19:48:41 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35B4F7B956 for ; Sun, 17 Dec 2017 19:48:39 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBHJoHIh093103 for ; Sun, 17 Dec 2017 11:50:23 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: status-mail-rejects: appears to be broken Date: Sun, 17 Dec 2017 11:50:23 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Sun, 17 Dec 2017 19:48:41 -0000 I'm running on r326056, and periodic(8) doesn't seem to be working as expected; mail rejects: Checking for rejected mail hosts: usage: fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=3Dhost] [--ca-cert=3Dfile] [--ca-path=3Ddir] [--cert=3Dfile] [--crl=3Dfile] [-i file] [--key=3Dfile] [-N file] [--no-passive] [--no-proxy=3Dlist= ] [--no-sslv3] [--no-tlsv1] [--no-verify-hostname] [--no-verify-peer] [-o file] [--referer=3DURL] [-S bytes] [-T seconds] [--user-agent=3Dagent-string] [-w seconds] URL =2E=2E=2E fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=3Dhost] [--ca-cert=3Dfile] [--ca-path=3Ddir] [--cert=3Dfile] [--crl=3Dfile] [-i file] [--key=3Dfile] [-N file] [--no-passive] [--no-proxy=3Dlist= ] [--no-sslv3] [--no-tlsv1] [--no-verify-hostname] [--no-verify-peer] [-o file] [--referer=3DURL] [-S bytes] [-T seconds] [--user-agent=3Dagent-string] [-w seconds] -h host -f file [-c dir] Also, 520=2Epfdenied doesn't produce any output=2E In fact, it doesn't appear to be run at all=2E Any thoughts, or advice on how to best proceed? Thanks! --Chris From owner-freebsd-current@freebsd.org Sun Dec 17 19:52:07 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 A49F2E93F2D for ; Sun, 17 Dec 2017 19:52:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 6BA787BF92 for ; Sun, 17 Dec 2017 19:52:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id 68so25365294ite.4 for ; Sun, 17 Dec 2017 11:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=hlshFmVh3VvZUKEnge+al5FjG/TnL9UtEhNWVtBl73Q=; b=TFYMi+cnxNWtDvgW5A2MDMjt3rS8wYmMqtemlXrWvz9aG+OGRPSSqdohuYamnBNXU1 bMoxPVjJ1tGn77lxLYdRBFLvKeiTZz8ktVtCRZXvA6NX4J5rIVfm4y577hgd3u7VR2pK w2SNRWWNS5M2mp5XDHtxWD9oLPYhDPVzgGAS2J9Yt7teAtQV5g7IFUmVTmQjOYgEaSPI 9/8rb5a6NNeFP0z3amHP159GyyLNcgoHUT1nfEA/cfacr3yn3PuDMQAtX/mGHpkhY4KB OMbuW7wXZ3uC9nP9sG2cLKAaPyl0hY+8MwZBoM2u2lSHVl4JqMW/hux2qttMf46Z8bTY fGbQ== 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:from:date:message-id:subject :to; bh=hlshFmVh3VvZUKEnge+al5FjG/TnL9UtEhNWVtBl73Q=; b=T12v1IVr7gFu7M8CVc8hKXg06PB1n8qDRjzOEb+Uhi9kINEgETAv7eD7BTSED8B/68 iYA9CHlSvEaPvBRfBH1xkhfEXg0GyclCZVjhAtYDHssJxgkEbZ1bILVIEY0VMFnJBsts sZPWFMpskgTKDqUQaIJIoggAfuAYp7ZyQIKvObGjxCr8Nr7Mid7k3vLS5uMlzd47pdkZ +DgJoOLOGU7JB6qVWLoYu5xVj1dBr4RyYEsd5XxdGCMV+SndJvw/QwJ4fip7HYzC4ptp fXfFCQ788L4ofjK0lqkn0Z7ceLYELJFMd2QP7FrkvT3FVmoJutnj6PRnI9jhBDNTu9FY SBCw== X-Gm-Message-State: AKGB3mJA8b05qNcGZT2dj8p/jYtUqYEeseBrB5ImTmAhFOhomUAHF3be Z3qAc7DjLVElbQqJpYeibKV+Grg3jsdPPHDkOk0saA== X-Google-Smtp-Source: ACJfBotylsdbWhqP5ribyzFmuvoKMp6NU0Ee9lzfOmMg7HEfAxNc9+dOTIUAtkft0ZMxLlct+Tfs11Kwcdxtxc2FP9U= X-Received: by 10.36.77.143 with SMTP id l137mr17164769itb.50.1513540326338; Sun, 17 Dec 2017 11:52:06 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 17 Dec 2017 11:52:05 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] From: Warner Losh Date: Sun, 17 Dec 2017 12:52:05 -0700 X-Google-Sender-Auth: k-YKavnVFKWdsicej-6l1nNfJk0 Message-ID: Subject: UEFI booting survey To: 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: Sun, 17 Dec 2017 19:52:07 -0000 Greetings If you are booting off UEFI and have a bit of an unusual setup, I'd like you to drop me a line. The setup that I'm looking for is any case where you load boot1.efi off one drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that drive, but on a different drive on the system. An example of this may be loading boot1.efi off what FreeBSD would call /dev/ada0p1, but having root come from /dev/ada1p1. It's my belief that due to the fragility of this setup, few, if any, people have this setup. If you do, please take a minute to reply to this message. In the coming months, we're looking at dropping boot1.efi and instead installing /boot/loader.efi onto the ESP (most likely as \efi\freebsd\loader.efi). As part of the move to fully support the UEFI Boot Manager, we're dropping the 'search every device in the system' part of the current boot1 algorithm. It will be possible to configure the system to continue booting (either via the new efibootmgr which will allow any imaginable combination, or possibly via a fallback mechanism needed for the embedded EFIs that have poor UEFI Variable support at the moment), but as part of an upgrade to a future FreeBSD 12, some intervention will be necessary. Please let me know if you have an unusual setup like this. Warner From owner-freebsd-current@freebsd.org Sun Dec 17 19:52:41 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 21217E93FDF for ; Sun, 17 Dec 2017 19:52:41 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin2.langille.org (clavin2.langille.org [199.233.228.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 032A97C138 for ; Sun, 17 Dec 2017 19:52:40 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin2.int.langille.org (clavin2.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 359BA1F80C for ; Sun, 17 Dec 2017 19:52:39 +0000 (UTC) From: Dan Langille Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: cannot access pass device from within jail Message-Id: Date: Sun, 17 Dec 2017 14:52:12 -0500 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) 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: Sun, 17 Dec 2017 19:52:41 -0000 Hello, What suggestions do you have for where I should look next? I'm happy to = start installing various builds of FreeBSD in order to track down which = commit caused this. I'm trying to access a tape library from within a jail running on a = FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). pass(4) devices (i.e. the tape changer ch0) are not working. This = morning I posted to -scsi@: = https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html= The device appears in the jail and has appropriate permissions. This = access was granted via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 The permissions in the jail: [root@bacula-sd-02 ~]# ls -l /dev/pass7 crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 The command in the jail: [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status=20 cannot open SCSI device '/dev/pass7' - Operation not permitted Here is the truss output of the command in question: = https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe Thank you. --=20 Dan Langille - BSDCan / PGCon dan@langille.org From owner-freebsd-current@freebsd.org Sun Dec 17 20:37:43 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 ED985E94E8C for ; Sun, 17 Dec 2017 20:37:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 8463A7D35B for ; Sun, 17 Dec 2017 20:37:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vBHKbYLW095512 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 17 Dec 2017 22:37:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBHKbYLW095512 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBHKbYSX095511; Sun, 17 Dec 2017 22:37:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Dec 2017 22:37:34 +0200 From: Konstantin Belousov To: Dan Langille Cc: freebsd-current@freebsd.org Subject: Re: cannot access pass device from within jail Message-ID: <20171217203734.GA2272@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Sun, 17 Dec 2017 20:37:44 -0000 On Sun, Dec 17, 2017 at 02:52:12PM -0500, Dan Langille wrote: > Hello, > > What suggestions do you have for where I should look next? I'm happy to start installing various builds of FreeBSD in order to track down which commit caused this. > > I'm trying to access a tape library from within a jail running on a FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). > > pass(4) devices (i.e. the tape changer ch0) are not working. This morning I posted to -scsi@: https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html > > The device appears in the jail and has appropriate permissions. This access was granted > via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 > > The permissions in the jail: > > [root@bacula-sd-02 ~]# ls -l /dev/pass7 > crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 > > The command in the jail: > > [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status > cannot open SCSI device '/dev/pass7' - Operation not permitted > > Here is the truss output of the command in question: https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe Does it work to access the pass device from host using host' /dev ? Same question for the host access using the nodes of the jailed devfs mount. From owner-freebsd-current@freebsd.org Sun Dec 17 20:38:06 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 22562E94F08 for ; Sun, 17 Dec 2017 20:38:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D8A197D47B for ; Sun, 17 Dec 2017 20:38:05 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0A8CE25D389C; Sun, 17 Dec 2017 20:38:03 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 5E46DD1F834; Sun, 17 Dec 2017 20:38:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id OjibuAEvuWkA; Sun, 17 Dec 2017 20:38:01 +0000 (UTC) Received: from [192.168.1.224] (unknown [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D9D31D1F832; Sun, 17 Dec 2017 20:38:00 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Dan Langille" Cc: freebsd-current@freebsd.org Subject: Re: cannot access pass device from within jail Date: Sun, 17 Dec 2017 20:37:59 +0000 X-Mailer: MailMate (2.0BETAr6102) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 17 Dec 2017 20:38:06 -0000 On 17 Dec 2017, at 19:52, Dan Langille wrote: > Hello, > > What suggestions do you have for where I should look next? I'm happy > to start installing various builds of FreeBSD in order to track down > which commit caused this. > > I'm trying to access a tape library from within a jail running on a > FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind > nsa0). > > pass(4) devices (i.e. the tape changer ch0) are not working. This > morning I posted to -scsi@: > https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html > > The device appears in the jail and has appropriate permissions. This > access was granted > via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 > > The permissions in the jail: > > [root@bacula-sd-02 ~]# ls -l /dev/pass7 > crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 > > The command in the jail: > > [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status > cannot open SCSI device '/dev/pass7' - Operation not permitted > > Here is the truss output of the command in question: > https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe You don’t by any chance have a securelevel > 1 set for that jail? /bz From owner-freebsd-current@freebsd.org Sun Dec 17 20:46:26 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 C56FDE955A3 for ; Sun, 17 Dec 2017 20:46:26 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A06857DC67 for ; Sun, 17 Dec 2017 20:46:25 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 34BF231BD ; Sun, 17 Dec 2017 20:46:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: cannot access pass device from within jail From: Dan Langille In-Reply-To: Date: Sun, 17 Dec 2017 15:45:45 -0500 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3445.5.20) 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: Sun, 17 Dec 2017 20:46:26 -0000 > On Dec 17, 2017, at 3:37 PM, Bjoern A. Zeeb = wrote: >=20 > On 17 Dec 2017, at 19:52, Dan Langille wrote: >=20 >> Hello, >>=20 >> What suggestions do you have for where I should look next? I'm happy = to start installing various builds of FreeBSD in order to track down = which commit caused this. >>=20 >> I'm trying to access a tape library from within a jail running on a = FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). >>=20 >> pass(4) devices (i.e. the tape changer ch0) are not working. This = morning I posted to -scsi@: = https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html= >>=20 >> The device appears in the jail and has appropriate permissions. This = access was granted >> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 >>=20 >> The permissions in the jail: >>=20 >> [root@bacula-sd-02 ~]# ls -l /dev/pass7 >> crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 >>=20 >> The command in the jail: >>=20 >> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status >> cannot open SCSI device '/dev/pass7' - Operation not permitted >>=20 >> Here is the truss output of the command in question: = https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe >=20 >=20 > You don=E2=80=99t by any chance have a securelevel > 1 set for that = jail? On the host:=20 $ sysctl kern.securelevel kern.securelevel: -1 On the jail: $ sysctl kern.securelevel kern.securelevel: -1 Thank you --=20 Dan Langille - BSDCan / PGCon dan@langille.org From owner-freebsd-current@freebsd.org Sun Dec 17 20:49:43 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 D6691E957D6 for ; Sun, 17 Dec 2017 20:49:43 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B58527DE10 for ; Sun, 17 Dec 2017 20:49:43 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 6E48231BF ; Sun, 17 Dec 2017 20:49:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: cannot access pass device from within jail From: Dan Langille In-Reply-To: <20171217203734.GA2272@kib.kiev.ua> Date: Sun, 17 Dec 2017 15:49:15 -0500 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171217203734.GA2272@kib.kiev.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.3445.5.20) 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: Sun, 17 Dec 2017 20:49:43 -0000 > On Dec 17, 2017, at 3:37 PM, Konstantin Belousov = wrote: >=20 > On Sun, Dec 17, 2017 at 02:52:12PM -0500, Dan Langille wrote: >> Hello, >>=20 >> What suggestions do you have for where I should look next? I'm happy = to start installing various builds of FreeBSD in order to track down = which commit caused this. >>=20 >> I'm trying to access a tape library from within a jail running on a = FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). >>=20 >> pass(4) devices (i.e. the tape changer ch0) are not working. This = morning I posted to -scsi@: = https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html= >>=20 >> The device appears in the jail and has appropriate permissions. This = access was granted >> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 >>=20 >> The permissions in the jail: >>=20 >> [root@bacula-sd-02 ~]# ls -l /dev/pass7 >> crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 >>=20 >> The command in the jail: >>=20 >> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status=20 >> cannot open SCSI device '/dev/pass7' - Operation not permitted >>=20 >> Here is the truss output of the command in question: = https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe >=20 > Does it work to access the pass device from host using host' /dev ? Yes, it does. see "This command on the host" at = https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007610.html= > Same question for the host access using the nodes of the jailed devfs = mount. I didn't try that, but I will soon. To be clear, does this command on = the host look like what you have in mind? mtx -f /usr/jails/bacula-sd-02/dev/pass7 status=20 --=20 Dan Langille - BSDCan / PGCon dan@langille.org From owner-freebsd-current@freebsd.org Sun Dec 17 21:01:29 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 43CCBE95D07 for ; Sun, 17 Dec 2017 21:01:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 CE2D17E56A for ; Sun, 17 Dec 2017 21:01:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vBHL1KYb001355 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 17 Dec 2017 23:01:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBHL1KYb001355 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBHL1KXf001353; Sun, 17 Dec 2017 23:01:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Dec 2017 23:01:20 +0200 From: Konstantin Belousov To: Dan Langille Cc: freebsd-current@freebsd.org Subject: Re: cannot access pass device from within jail Message-ID: <20171217210120.GB2272@kib.kiev.ua> References: <20171217203734.GA2272@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Sun, 17 Dec 2017 21:01:29 -0000 On Sun, Dec 17, 2017 at 03:49:15PM -0500, Dan Langille wrote: > > On Dec 17, 2017, at 3:37 PM, Konstantin Belousov wrote: > > Does it work to access the pass device from host using host' /dev ? > > Yes, it does. see "This command on the host" at https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007610.html Ok. > > > Same question for the host access using the nodes of the jailed devfs mount. > > I didn't try that, but I will soon. To be clear, does this command on the host look like what you have in mind? > > mtx -f /usr/jails/bacula-sd-02/dev/pass7 status I do not know. Check with truss which node gets accessed. From owner-freebsd-current@freebsd.org Sun Dec 17 21:04:20 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 B1AECE96016 for ; Sun, 17 Dec 2017 21:04:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 76B927E817 for ; Sun, 17 Dec 2017 21:04:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id f190so25422420ita.5 for ; Sun, 17 Dec 2017 13:04:20 -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=zO4ukwg/FvdRXuotFYTFt9L+iuaL0n5rwOCom5zN7P8=; b=jOC6jLvnHtrW+rbFGRyvzkjus1LNtVsBdTumqQMyJzDD7/GSPhrr7K+RY67OuVZ9UP Vqhr7gVr8n9ORXEfp7l5re2bqBVIDr3wDUjguvM+QIxTyQVTiOmol1rEYhQ+yUsfzNMs r0zPN3M566qQgL/k0mJAuSENn2PjLonf5OJsU+NXUXz88AhvDNoiUGUSJozb2QfPCQV3 BmA5z4s14YhlXQm7D7RyF7/upRTig7hgObAQlE+/w9diOHtQwRQ61kilic8jOCE4yhC6 5h0Q4icpR01KK57ZzZRpXV3T5T3qrTEMMP9f6yGoc4yeTziblErQHg7PdpbV/dSAp7x+ zqYA== 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=zO4ukwg/FvdRXuotFYTFt9L+iuaL0n5rwOCom5zN7P8=; b=h+EyzwZKIDkBnRAOUA5W2Mm2sPbiIXA74qm2HOVg29MrZMN/hrcObvRESNL8K3FXTr IHLpmz1pTJKMZHu2l6fLOXvzEiCbI4hBBHwZPQ+hAkUfHru+ZCEHC6nkXGeoiLGfEqso bM+xZOY/ls1tRT8tNoMRRyQSjHW0nus+rUi/29TwxrSm7Dju0DDR+khMzXFtXRPPFEUR hI2rS29mIxDUJgWrGPvK+C22ruJJIX9GKJxrnEBcs/jgaZbEz9PsvQasMvhk2D0iO/EH r7eZKVYzFJHy5Ac59x0q/p6bC+5ctsvvPEaPyEZy3rYO43rR9DJV1HTSrKnJV8aYawpC 0FRg== X-Gm-Message-State: AKGB3mJOSx8tRd0zPhThgFgpDZ3RR7O0+zK5bXce7BBZ424atSdCxJ2g KfpUbvAyer4wPTYI2nHIx0sr7Y61S4xGeZezZB3/DqH/ X-Google-Smtp-Source: ACJfBos5DIWaALDlxOuqYs+Qq/m+Vo7S8/trlHyx/iVxEjNGqoK4hShixFf54JAGE2PEvCg7uA2GzDqr60FSbCaDs28= X-Received: by 10.36.133.135 with SMTP id r129mr18367626itd.69.1513544659708; Sun, 17 Dec 2017 13:04:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 17 Dec 2017 13:04:19 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Sun, 17 Dec 2017 14:04:19 -0700 X-Google-Sender-Auth: 920tY9wz_Yvu0OJqKaCa4GS-va4 Message-ID: Subject: Re: cannot access pass device from within jail To: Dan Langille 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: Sun, 17 Dec 2017 21:04:20 -0000 What's the permissions of /dev/xpt0 in the jail? If it's not there I know at least camcontrol won't work. I've not used mtx, so I can't say if it's affected too or not. However, looking at the truss output: openat(AT_FDCWD,"/dev/pass7",O_RDWR|O_EXCL,00) ERR#1 'Operation not permitted' suggests something other than the canonical xpt0 issue else is going on. If we look at passopen in cam, I can see two exit paths: error = securelevel_gt(td->td_ucred, 1); if (error != 0) {... return error; } securelevel_gt is just "return (cr->cr_prison->pr_securelevel > level ? EPERM : 0);" which might be possible. What's the securelevel of the jail? Maybe this is going on somehow? The second is basically if (((flags & FWRITE) == 0) || ((flags & FREAD) == 0)) {... return EPERM; } which isn't happening because of the O_RDWR in the truss output. The other possibility is that something above the pass driver is doing the check. I've not looked at that code path yet, buy you can see if it's making it to passopen() with dtrace and checking its return value. I don't see anything in how we register the device, though, that would suggest filtering it in jails. Warner On Sun, Dec 17, 2017 at 12:52 PM, Dan Langille wrote: > Hello, > > What suggestions do you have for where I should look next? I'm happy to > start installing various builds of FreeBSD in order to track down which > commit caused this. > > I'm trying to access a tape library from within a jail running on a > FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). > > pass(4) devices (i.e. the tape changer ch0) are not working. This morning > I posted to -scsi@: https://lists.freebsd.org/pipermail/freebsd-scsi/2017- > December/007608.html > > The device appears in the jail and has appropriate permissions. This > access was granted > via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 > > The permissions in the jail: > > [root@bacula-sd-02 ~]# ls -l /dev/pass7 > crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 > > The command in the jail: > > [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status > cannot open SCSI device '/dev/pass7' - Operation not permitted > > Here is the truss output of the command in question: > https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe > > Thank you. > > -- > Dan Langille - BSDCan / PGCon > dan@langille.org > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sun Dec 17 21:08:38 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 0D5CAE96270 for ; Sun, 17 Dec 2017 21:08:38 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2C8E7EBCF for ; Sun, 17 Dec 2017 21:08:37 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 631E9334C ; Sun, 17 Dec 2017 21:08:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: cannot access pass device from within jail From: Dan Langille In-Reply-To: Date: Sun, 17 Dec 2017 16:08:08 -0500 Cc: FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3445.5.20) 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: Sun, 17 Dec 2017 21:08:38 -0000 > On Dec 17, 2017, at 4:04 PM, Warner Losh wrote: > > What's the permissions of /dev/xpt0 in the jail? If it's not there I know > at least camcontrol won't work. I've not used mtx, so I can't say if it's > affected too or not. I have tried both with and without xpt0. When I tried, it was: # ls -l /dev/xpt0 crw------- 1 root operator 0x4c Dec 16 21:52 /dev/xpt0 > > However, looking at the truss output: > > openat(AT_FDCWD,"/dev/pass7",O_RDWR|O_EXCL,00) ERR#1 'Operation not > permitted' > suggests something other than the canonical xpt0 issue else is going on. If > we look at passopen in cam, I can see two exit paths: > > error = securelevel_gt(td->td_ucred, 1); if (error != 0) {... > return error; } > securelevel_gt is just "return (cr->cr_prison->pr_securelevel > level ? > EPERM : 0);" which might be possible. What's the securelevel of the jail? > Maybe this is going on somehow? On the host: $ sysctl kern.securelevel kern.securelevel: -1 On the jail: $ sysctl kern.securelevel kern.securelevel: -1 > > The second is basically > if (((flags & FWRITE) == 0) || ((flags & FREAD) == 0)) {... return > EPERM; } > which isn't happening because of the O_RDWR in the truss output. > > The other possibility is that something above the pass driver is doing the > check. I've not looked at that code path yet, buy you can see if it's > making it to passopen() with dtrace and checking its return value. I don't > see anything in how we register the device, though, that would suggest > filtering it in jails. > > Warner > > On Sun, Dec 17, 2017 at 12:52 PM, Dan Langille wrote: > >> Hello, >> >> What suggestions do you have for where I should look next? I'm happy to >> start installing various builds of FreeBSD in order to track down which >> commit caused this. >> >> I'm trying to access a tape library from within a jail running on a >> FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). >> >> pass(4) devices (i.e. the tape changer ch0) are not working. This morning >> I posted to -scsi@: https://lists.freebsd.org/pipermail/freebsd-scsi/2017- >> December/007608.html >> >> The device appears in the jail and has appropriate permissions. This >> access was granted >> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 >> >> The permissions in the jail: >> >> [root@bacula-sd-02 ~]# ls -l /dev/pass7 >> crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 >> >> The command in the jail: >> >> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status >> cannot open SCSI device '/dev/pass7' - Operation not permitted >> >> Here is the truss output of the command in question: >> https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe >> >> Thank you. >> >> -- >> Dan Langille - BSDCan / PGCon >> dan@langille.org >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Dec 17 21:38:54 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 CB766E96B70 for ; Sun, 17 Dec 2017 21:38:54 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 8266F7F6CE; Sun, 17 Dec 2017 21:38:54 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vk0-x244.google.com with SMTP id v70so688242vkd.8; Sun, 17 Dec 2017 13:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lhIO1pLJHui+BkqgtHUD/ij0BmpbTtJYWelRyOyjQlA=; b=O27rnv5vxTfng6GrASIAv8u3ZALJ+meMrybxqsct/22QsaN1h1/7lpeqfgBS398bDz TKjJR/CTggVTs8nUAqnT30QFPz8qn/h3jSd88a6aYWnIKOgTxjDi7qd1m5iTfv+l6XKo 9sL8nkmcLC12fC2zaOdoEpDKOSkb8AxJRST9bGWEXAeFQYjnF1orAHD8kc7W/6gLovZs 6z2hGbuUAAe4WtRXKssRfkPF84NyefCcaAIm2Nz8GPMU+2brKX2uhYKq7EgrHYripz4q 4/+oF+MoOkmyifdeKd5JoJlIUdAUdA+t4xEJ9EAExbmlZuUgS+ze3iYq482iqXpg0h8u Qi8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lhIO1pLJHui+BkqgtHUD/ij0BmpbTtJYWelRyOyjQlA=; b=SEThWzDIDIx2sifDMeE/XXoazkYBAWuqi8ad3Npv+UO6G3XurY4506q+rfQ3uVMclY 4PLIQLUny6iDJxCZD8XEBNaN1m3xC+s0x3ODP6WZbSWCjuULjx+WOwFszd8lSKJHKEau kKGmoYgJoc2Q3/sc8pSxHI9Shr2qjw9MdHwD1drQEWP/yqfLDJ1t0R6xPfjhYsNOCiEa TIVgCLfVQNQx+b/wa8BNq0e1IHOBptyjgKl//bWWV5alFQ99b6nE9ieJkYDz+rgAF5Of vjmzEiex+IqN9a15Qdxml5Kr43/w2/3dXUb6bC5UdEz0Mwr9RpME04VNhZqojSoxqoZK eUlQ== X-Gm-Message-State: AKGB3mJcdphBEFGPiIjUhk1r/0Pba1VRzv/GyBIlFJZFu7mPjqhBrnpj dnksgDE9bWc18n93NCo/CeKNU514T4GOClkohby/YA== X-Google-Smtp-Source: ACJfBotr84a7P1X0lmjSUXRf3PipjGXUlYqpSgYoVVE7lNi+jB1c4DKbR1OkXR2vATa+0UFeZkS8dNMAxOEesZM0hUc= X-Received: by 10.31.159.148 with SMTP id i142mr20313630vke.1.1513546733296; Sun, 17 Dec 2017 13:38:53 -0800 (PST) MIME-Version: 1.0 References: <7c79c676-3414-8cab-bcf8-b3e3d08a70f6@protected-networks.net> In-Reply-To: <7c79c676-3414-8cab-bcf8-b3e3d08a70f6@protected-networks.net> From: Ben Woods Date: Sun, 17 Dec 2017 21:38:42 +0000 Message-ID: Subject: Re: what's changed with newsyslog? To: Baptiste Daroussin , Michael Butler Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sun, 17 Dec 2017 21:38:54 -0000 On Mon, 18 Dec 2017 at 3:47 am, Michael Butler wrote: > In the past week or so I've been getting warnings like this .. > > bzip2: Can't open input file /var/log/snmpd.log.0: No such file or > directory. > newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0 > /var/log/fwlw_clean_log.0' terminated with a non-zero status (1) > > I've checked the relevant /etc/newsyslog.conf and its /usr/local/etc > counterpart to ensure there are tabs in the right places but the errors > persist. > > Similarly, the relevant files are there and seem to be rotated as > expected/desired .. > > -rw-r--r-- 1 root wheel 77 Dec 17 09:00 fwlw_clean_log > -rw-r--r-- 1 root wheel 11282 Dec 17 09:00 fwlw_clean_log.0.bz2 > -rw-r--r-- 1 root wheel 9452 Dec 17 05:00 fwlw_clean_log.1.bz2 > > [ .. ] > > -rw-r--r-- 1 root wheel 50992 Dec 17 09:45 snmpd.log > -rw-r--r-- 1 root wheel 1834 Dec 17 09:00 snmpd.log.0.bz2 > -rw-r--r-- 1 root wheel 1846 Dec 17 07:00 snmpd.log.1.bz2 > > > Hints? > > imb > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " Could this be related to bapt=E2=80=99s recent change 11 days ago to allow newsyslog to use different style of compression commands? https://svnweb.freebsd.org/base?view=3Drevision&revision=3D326617 Regards, Ben --=20 -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sun Dec 17 21:41:39 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 28932E96CE6 for ; Sun, 17 Dec 2017 21:41:39 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E7DE77FA02; Sun, 17 Dec 2017 21:41:38 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject; s=201508; t=1513546890; bh=9K0U4EaT IDR1g/hGnsEVQBY4QL9Xe8Q0jzvdRGAgN6s=; b=Ee08mGiC9u3Cnzgk8lHiTAza FVQCmrCy3uy4l2Nxw2P/1d+THavVxtBuRFgmfUkHSQ2NpQS7E+5IW1BjeA+4Fdhf 49ql4JBqydZudH4I7S+R58axSElcB+4bp1GOe7KuYto55Pzpfpto7RjpqRHfA9D+ jtRch68xz+4NHC3CXNs= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 2C87E1D6F3; Sun, 17 Dec 2017 16:41:30 -0500 (EST) Subject: Re: what's changed with newsyslog? To: Ben Woods , Baptiste Daroussin Cc: freebsd-current References: <7c79c676-3414-8cab-bcf8-b3e3d08a70f6@protected-networks.net> From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: Date: Sun, 17 Dec 2017 16:41:29 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Sun, 17 Dec 2017 21:41:39 -0000 On 12/17/17 16:38, Ben Woods wrote: > On Mon, 18 Dec 2017 at 3:47 am, Michael Butler > > wrote: > > In the past week or so I've been getting warnings like this .. > > bzip2: Can't open input file /var/log/snmpd.log.0: No such file or > directory. > newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0 > /var/log/fwlw_clean_log.0' terminated with a non-zero status (1) [ .. snip .. ] > > > Hints? > >         imb > > Could this be related to bapt’s recent change 11 days ago to allow > newsyslog to use different style of compression commands? > https://svnweb.freebsd.org/base?view=revision&revision=326617 Yes - I reverted to r326616 and the issue no longer appears, imb From owner-freebsd-current@freebsd.org Sun Dec 17 21:48:41 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 AF866E970A0 for ; Sun, 17 Dec 2017 21:48:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 6DC777FD5C for ; Sun, 17 Dec 2017 21:48:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id o2so7815827ioe.8 for ; Sun, 17 Dec 2017 13:48:41 -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=shSooigwox7cUi1KVn0ED/zs7Uv9Y4jKd9YOTGxeD4s=; b=G/98DvHQnQKlZ+JMuKBhUghBy4fvzEtq3hqEYw5DaFfYoJbVu/EGPM/HzEX10ctRTK Mf7mUmBOmkypZI8z4hUev7CIXMRbOyXQWo7h3OCEKLCPMGnTzzF2QrtCadR4OVAxm+iB dfSvA/RRdfWorUO+3LeNfDzhXfylaC9twe6T5INoR9Y5Iz63ctOcQLbPrCxY396TJH2L w1Q4yfrjWU0ze/PAPD89Jsu6uXSmdWXXPO043PQx+IHIVXvwEOKJADxlbm8X5ZVLrU0F px8bPgrtmWaH5OOuDAFqh4tcspEQ8gNyRnhXQtHM9NER2GO5s4ZsPbmxWfqR8gbwWMvl wt7g== 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=shSooigwox7cUi1KVn0ED/zs7Uv9Y4jKd9YOTGxeD4s=; b=BvQFbx2tKoW/YS7OPHD9H946vt7tyoFZWI2VumU0NpMPRvsbJmZX0qqGwqIZWO/67P iRgjxNYcR+Rla64KHa7n43Lj5Se4cIBs6CApkJorauk542SmjvsNYqKM38Z0JcnIutYY 2xmxr7Arv+Kf8VarRL/dRaLg7+ejjFHlSqCo1xl/LwU1+4JPLVEOGIfBdN8GDjKprYBH jSfQFRBE9z8YCA/mpnjZeuL1seOPphuAwCErzu/aq47TPnLl6kPYVwjBZNwQrxBaLGTc 5Z6xpxpcza1a81dRb96m4f2JbQVHsdlFmlCXQw8t7liD72Ciqgz1HWuSpiZ9awX4a+is tSEQ== X-Gm-Message-State: AKGB3mIoCFK4g06UvIyqIh1wdGY0rmU+SofosvcD9KlzXFqEq2mJyN4j RFkKstZmpZQE5eFOWWFVLay+jVm8kl7DV+TPCyjAqQ== X-Google-Smtp-Source: ACJfBouNP0ilMvBu2ofFwUBLUsekBI4YyRDc1BUUgMUVQrMOC0zrxMZVyyhlZrjyFCyplhhyI5bCeLAJe7ECeu5d6Vc= X-Received: by 10.107.139.146 with SMTP id n140mr14339399iod.136.1513547320639; Sun, 17 Dec 2017 13:48:40 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 17 Dec 2017 13:48:39 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Sun, 17 Dec 2017 14:48:39 -0700 X-Google-Sender-Auth: 8NoG3ygBh7gyyLpXP2wN9CTTTMg Message-ID: Subject: Re: cannot access pass device from within jail To: Dan Langille 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: Sun, 17 Dec 2017 21:48:41 -0000 Sorry to top post. The problem did turn out to be securelevel. We found this by doing dtrace -n 'fbt::securelevel_gt:return {print(args[1];)}' Though you could also replace securelevel_gt with passopen to see it was in passopen too... Warner On Sun, Dec 17, 2017 at 2:08 PM, Dan Langille wrote: > > On Dec 17, 2017, at 4:04 PM, Warner Losh wrote: > > > > What's the permissions of /dev/xpt0 in the jail? If it's not there I know > > at least camcontrol won't work. I've not used mtx, so I can't say if it's > > affected too or not. > > I have tried both with and without xpt0. When I tried, it was: > > # ls -l /dev/xpt0 > crw------- 1 root operator 0x4c Dec 16 21:52 /dev/xpt0 > > > > > However, looking at the truss output: > > > > openat(AT_FDCWD,"/dev/pass7",O_RDWR|O_EXCL,00) ERR#1 'Operation not > > permitted' > > suggests something other than the canonical xpt0 issue else is going on. > If > > we look at passopen in cam, I can see two exit paths: > > > > error = securelevel_gt(td->td_ucred, 1); if (error != 0) {... > > return error; } > > securelevel_gt is just "return (cr->cr_prison->pr_securelevel > level ? > > EPERM : 0);" which might be possible. What's the securelevel of the jail? > > Maybe this is going on somehow? > > > On the host: > > $ sysctl kern.securelevel > kern.securelevel: -1 > > > On the jail: > > $ sysctl kern.securelevel > kern.securelevel: -1 > > > > > The second is basically > > if (((flags & FWRITE) == 0) || ((flags & FREAD) == 0)) {... return > > EPERM; } > > which isn't happening because of the O_RDWR in the truss output. > > > > The other possibility is that something above the pass driver is doing > the > > check. I've not looked at that code path yet, buy you can see if it's > > making it to passopen() with dtrace and checking its return value. I > don't > > see anything in how we register the device, though, that would suggest > > filtering it in jails. > > > > Warner > > > > On Sun, Dec 17, 2017 at 12:52 PM, Dan Langille wrote: > > > >> Hello, > >> > >> What suggestions do you have for where I should look next? I'm happy to > >> start installing various builds of FreeBSD in order to track down which > >> commit caused this. > >> > >> I'm trying to access a tape library from within a jail running on a > >> FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). > >> > >> pass(4) devices (i.e. the tape changer ch0) are not working. This > morning > >> I posted to -scsi@: https://lists.freebsd.org/ > pipermail/freebsd-scsi/2017- > >> December/007608.html > >> > >> The device appears in the jail and has appropriate permissions. This > >> access was granted > >> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 > >> > >> The permissions in the jail: > >> > >> [root@bacula-sd-02 ~]# ls -l /dev/pass7 > >> crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 > >> > >> The command in the jail: > >> > >> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status > >> cannot open SCSI device '/dev/pass7' - Operation not permitted > >> > >> Here is the truss output of the command in question: > >> https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe > >> > >> Thank you. > >> > >> -- > >> Dan Langille - BSDCan / PGCon > >> dan@langille.org > >> > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > From owner-freebsd-current@freebsd.org Sun Dec 17 21:54:16 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 B2938E973F2 for ; Sun, 17 Dec 2017 21:54:16 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin2.langille.org (clavin2.langille.org [199.233.228.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AE7880189 for ; Sun, 17 Dec 2017 21:54:16 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin2.int.langille.org (clavin2.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id BB8B11FAB9 ; Sun, 17 Dec 2017 21:54:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: cannot access pass device from within jail From: Dan Langille In-Reply-To: Date: Sun, 17 Dec 2017 16:53:46 -0500 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3445.5.20) 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: Sun, 17 Dec 2017 21:54:16 -0000 > On Dec 17, 2017, at 4:48 PM, Warner Losh wrote: >=20 > Sorry to top post. The problem did turn out to be securelevel. We = found > this by doing >=20 > dtrace -n 'fbt::securelevel_gt:return {print(args[1];)}' >=20 > Though you could also replace securelevel_gt with passopen to see it = was in > passopen too... On the host we ran: [root@r710-01:~] # sudo dtrace -n 'fbt::securelevel_gt:return = {print(args[1]);}' dtrace: description 'fbt::securelevel_gt:return ' matched 1 probe CPU ID FUNCTION:NAME 21 50269 securelevel_gt:return int 0x1 In the jail: mtx -f /dev/pass7 status Based on the dtrace output, I again checked securelevel in the jail: [dan@bacula-sd-02] $ sysctl kern.securelevel kern.securelevel: 2 WTF? I'd already checked that as seen at = https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007614.html= Oh wait. The above URL refers to bacula-sd-01, not bacula-sd-02. Ouch. = User error... me. After going back into the host, I set: $ sudo iocage set securelevel=3D1 bacula-sd-02 Property: securelevel has been updated to 1 After restarting the jail and getting back into it: [root@bacula-sd-02 ~]# sysctl kern.securelevel kern.securelevel: 1 [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status=20 Storage Changer /dev/pass7:2 Drives, 47 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag =3D = 000001L4 =20 .... Success. Sorry for the noise which would have been reduced if I'd gotten my = sysctl on the right host. Thank you all=10. >=20 > Warner >=20 > On Sun, Dec 17, 2017 at 2:08 PM, Dan Langille = wrote: >=20 >>> On Dec 17, 2017, at 4:04 PM, Warner Losh wrote: >>>=20 >>> What's the permissions of /dev/xpt0 in the jail? If it's not there I = know >>> at least camcontrol won't work. I've not used mtx, so I can't say if = it's >>> affected too or not. >>=20 >> I have tried both with and without xpt0. When I tried, it was: >>=20 >> # ls -l /dev/xpt0 >> crw------- 1 root operator 0x4c Dec 16 21:52 /dev/xpt0 >>=20 >>>=20 >>> However, looking at the truss output: >>>=20 >>> openat(AT_FDCWD,"/dev/pass7",O_RDWR|O_EXCL,00) ERR#1 'Operation not >>> permitted' >>> suggests something other than the canonical xpt0 issue else is going = on. >> If >>> we look at passopen in cam, I can see two exit paths: >>>=20 >>> error =3D securelevel_gt(td->td_ucred, 1); if (error !=3D 0) = {... >>> return error; } >>> securelevel_gt is just "return (cr->cr_prison->pr_securelevel > = level ? >>> EPERM : 0);" which might be possible. What's the securelevel of the = jail? >>> Maybe this is going on somehow? >>=20 >>=20 >> On the host: >>=20 >> $ sysctl kern.securelevel >> kern.securelevel: -1 >>=20 >>=20 >> On the jail: >>=20 >> $ sysctl kern.securelevel >> kern.securelevel: -1 >>=20 >>>=20 >>> The second is basically >>> if (((flags & FWRITE) =3D=3D 0) || ((flags & FREAD) =3D=3D 0)) = {... return >>> EPERM; } >>> which isn't happening because of the O_RDWR in the truss output. >>>=20 >>> The other possibility is that something above the pass driver is = doing >> the >>> check. I've not looked at that code path yet, buy you can see if = it's >>> making it to passopen() with dtrace and checking its return value. I >> don't >>> see anything in how we register the device, though, that would = suggest >>> filtering it in jails. >>>=20 >>> Warner >>>=20 >>> On Sun, Dec 17, 2017 at 12:52 PM, Dan Langille = wrote: >>>=20 >>>> Hello, >>>>=20 >>>> What suggestions do you have for where I should look next? I'm = happy to >>>> start installing various builds of FreeBSD in order to track down = which >>>> commit caused this. >>>>=20 >>>> I'm trying to access a tape library from within a jail running on a >>>> FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind = nsa0). >>>>=20 >>>> pass(4) devices (i.e. the tape changer ch0) are not working. This >> morning >>>> I posted to -scsi@: https://lists.freebsd.org/ >> pipermail/freebsd-scsi/2017- >>>> December/007608.html >>>>=20 >>>> The device appears in the jail and has appropriate permissions. = This >>>> access was granted >>>> via /etc/devfs.rules using the same approach I used for FreeBSD = 10.3 >>>>=20 >>>> The permissions in the jail: >>>>=20 >>>> [root@bacula-sd-02 ~]# ls -l /dev/pass7 >>>> crw------- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 >>>>=20 >>>> The command in the jail: >>>>=20 >>>> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status >>>> cannot open SCSI device '/dev/pass7' - Operation not permitted >>>>=20 >>>> Here is the truss output of the command in question: >>>> https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe >>>>=20 >>>> Thank you. >>>>=20 >>>> -- >>>> Dan Langille - BSDCan / PGCon >>>> dan@langille.org >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> freebsd.org" >>>>=20 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> freebsd.org" >>=20 >>=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Dec 18 09:35:47 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 9C32EE81B69 for ; Mon, 18 Dec 2017 09:35:47 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 771B272629; Mon, 18 Dec 2017 09:35:47 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id A9CA464DB; Mon, 18 Dec 2017 09:35:46 +0000 (UTC) Date: Mon, 18 Dec 2017 10:35:46 +0100 From: Baptiste Daroussin To: Michael Butler Cc: Ben Woods , freebsd-current Subject: Re: what's changed with newsyslog? Message-ID: <20171218093546.yz34iacfeiv5gyeo@ivaldir.net> References: <7c79c676-3414-8cab-bcf8-b3e3d08a70f6@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k2qw6vszdomz2u3t" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171208 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: Mon, 18 Dec 2017 09:35:47 -0000 --k2qw6vszdomz2u3t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 17, 2017 at 04:41:29PM -0500, Michael Butler wrote: > On 12/17/17 16:38, Ben Woods wrote: > > On Mon, 18 Dec 2017 at 3:47 am, Michael Butler > > > wrote: > >=20 > > In the past week or so I've been getting warnings like this .. > >=20 > > bzip2: Can't open input file /var/log/snmpd.log.0: No such file or > > directory. > > newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0 > > /var/log/fwlw_clean_log.0' terminated with a non-zero status (1) >=20 > [ .. snip .. ] >=20 > >=20 > >=20 > > Hints? > >=20 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 imb > >=20 > > Could this be related to bapt=E2=80=99s recent change 11 days ago to al= low > > newsyslog to use different style of compression commands? > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D326617 >=20 > Yes - I reverted to r326616 and the issue no longer appears, >=20 > imb >=20 Should be fixed in r326930, sorry about that Best regards, Bapt --k2qw6vszdomz2u3t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlo3i+8ACgkQY4mL3PG3 PlrwgRAAtbbs4OmbOxsRpz5xW5tfo1xZkps0am1OoQhODPGvV5Q59q5VB7CPWDfR +KelDuasoBcYBQMMjApbZgE6m+xmOu7umV/GnIVU5oC3kCq3Iye9sXXn36PlKXJB wCF2PWHXTH4Zr25upay3Zw00xiI8hn3FbzYAJYBFs89JCt8mXvTQ7cVAmsN9UkW7 cwAjqoKlfRJ4pM8SyoijaWDG2hm6pWnEb1EMULjOAq5JctxFl+2me/g3dSNA/6o2 IkO+5Rp8CTlnEflGe3WKDruaUDQITgt2ICz+8kg+4hna/S7bBNK/WbAzUlvVC6+S zobIZH6s/AhEIFmTZiUec+2/LNhqrgvOFiksG9d6DxspOIxYna1cXyCsx9U7LCa1 HI4n7B4/u3pyQcpvuYnAYoi9G4zm8iNO6vHzhMlDwxeHeKzp6cZIhqHMmMGjyxsF KXlqb356jDXMv9dw3OE2LVpWte3XLJUsIPNdEjgLXG2Vwkcx/v0ycXb7cER5BHWg N08zS8rhWE4saeTpksl5mgcUZ9o7bxjW5QQxFVz9nJDDO65jGAVuAM1WejInzc/X 6sorFVY7kANUGiByIAnwUnIkXVx3/b2niGN9eFTxz6oBpAbYLP4nRQARsya/ECs/ 2TuxlJj+a/bNHpz9c5r8wfm4Pf9HZGA0OT7H05W2o14ZdNGlc8g= =x9Z6 -----END PGP SIGNATURE----- --k2qw6vszdomz2u3t-- From owner-freebsd-current@freebsd.org Mon Dec 18 09:45:16 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 ACCA8E820BA for ; Mon, 18 Dec 2017 09:45:16 +0000 (UTC) (envelope-from antranig@vartanian.am) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 4800A72D0D for ; Mon, 18 Dec 2017 09:45:15 +0000 (UTC) (envelope-from antranig@vartanian.am) Received: by mail-wm0-x231.google.com with SMTP id f206so27990011wmf.5 for ; Mon, 18 Dec 2017 01:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vartanian-am.20150623.gappssmtp.com; s=20150623; h=to:from:subject:openpgp:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=wzLvxObk1Gy+KCTm6xBkyZ3bubQkHE3WUDDS29eIm/c=; b=g380pkFHfqcgZ5YJuHudfnM59Iva6UilSwOfwA4Sd1Ln2jloLzO2yVUxukQxfE8TUr mWkcC051V016XUxuSjCkszJeCt/IkA6Ra2/HLMHd9tVTgVSKwq/vx71y18fGqpXGPDke r8yrYq66eoHhGngcCVMnP/XYsnaFHh+65f8Yh0vAHei7+uEXKBQSo8eC95snZiaKDTqd tAwG6WGZe2zs6myr6bJMzi+pBHh1pkUjnXbk5qVhtw2WpQfesrEK4ICAmqbGlQQ2f37D 4GLgFBSEcT6MMn+7DHbzV7ny4z8esQldyvDXrB11aNeBED7jg8n5BQMwZSAvXlKcLlKQ tOtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=wzLvxObk1Gy+KCTm6xBkyZ3bubQkHE3WUDDS29eIm/c=; b=U9niTaJBxA+XXtm3tcXUCKrs1lSHhhOhUBB1l603tj0GlKakidsP+LYMOwbwaTZrsI bwvpWt88n6TVzG3sTqcxF0wQtQZBT/TBGttCaBv8wCDxbkqRy73/7LI+qoCcVEVuxBws TCahH4+eEToTHyXs1lHz5QSipfK1teV8R8odc99e+w/EFZBRdVjxVVT5QzyQ0DJi6cYw aADJGW0zFuo0lEgvl638zHnmKhFCOA8+sj9Ryk9b10zgMOBKnL40XaZgvp4Xy9SK3YxN Q8tlI4LcynJjgxa/Bhv2tafmVxWdSiR2TUYVirNSXJmCCUuFxjsKX5BFr49GKrk5Ucqt +KrA== X-Gm-Message-State: AKGB3mKd9FZ86csQf508bd9pFYQC/SqVmAU2Df2Q3QNSUeLoyA0Fla0N IkZW0MUB9LOcDhoDD7lJ4ebe4km081A= X-Google-Smtp-Source: ACJfBotQGDfgSUNNUIcyPrclOjGwD/v9hOYLPj41F1KkEU5iMkHkDSZUFB7kJsU+ECtUrbhrW2DTDA== X-Received: by 10.80.173.170 with SMTP id a39mr28506169edd.49.1513590313330; Mon, 18 Dec 2017 01:45:13 -0800 (PST) Received: from [192.168.5.51] ([37.157.223.90]) by smtp.gmail.com with ESMTPSA id q3sm10585432edd.61.2017.12.18.01.45.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 01:45:12 -0800 (PST) To: freebsd-current@freebsd.org From: antranigv Subject: r326820 stuck on bootloader Openpgp: id=7EB8C4FFCF2ED0AA61EE315960686B14DAB81456; url=https://antranigv.am/dab81456.asc Message-ID: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> Date: Mon, 18 Dec 2017 13:45:11 +0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 18 Dec 2017 11:44:20 +0000 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: Mon, 18 Dec 2017 09:45:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hey all! I have just downloaded FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and decompressed it, trying to boot it on QEMU and I get "Consoles: internal video/keyboard" and then it's stuck. I actually have no idea how to debug, any help would be appreciated. Thanks in advance, - -- antranigv https://antranigv.am/ | PGP Key ID : 0xDAB81456 /* do one thing and do it well */ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEfrjE/88u0Kph7jFZYGhrFNq4FFYFAlo3jiIACgkQYGhrFNq4 FFbuWw//du5kjUIR442fkCaCg8honaeZFJ666iwQE1grsSQS74kYzwQ1iSXBnGLV kPt6Nslz3YIRmIqDMuKr31a6zK33bLi7hfKbodIcPNIn/EBUY/D/Pq4FXgqZxu99 MGDAsbLafA3YhyeVuilxrHyDZjaUMDGfJCcBBB57/SxY9mEFT3g/zw1vdVDwpe52 /0bi3u3r/H4l88KGtECSI08WlqnpDyPeGuHImb/xrkQmGbl6PiHwvrijOP639JDf OpDEvLENRIwIBGYxsJPBk3EBPYEgpJKPm1yTU1swU/KJlCpau9O9WrG6OqO8qflO HOCzyhKvXJdXkphlVBLfYk6e8NKwHwc+7ZaMEDJDvqGJ9qFWXanALBkBRyREW61K ZY/8uLhoKNjPmAAMBgwbPihf35zWEXZhKLsaMza5f5NNniLCRrn+I4QhvhWlp10u 20tKX0bAJ+0sjQZInfqXftEwD5Mhw+H1sM1vk8igFFWyrMPCG9t0piV/AseixgDu SZ9IGl5EZSpq/q6Jhcjfxlplwi31SwkVWIRjDqBmzcVcYQO6khszCdi3S1b9Y5El T6gIswPuPWboJFGjPJxQN9V3APNUXT6c2p0aXq8S4NcvSRRmhyEc9mgc/LZrAX4a hwQSVmtJL15qhvBc6TgWEBAaLL9+eX2G9G2Wr1ZEBg5tx/1eY/I= =TQCj -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Mon Dec 18 12:48:07 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 4F325E86FB8 for ; Mon, 18 Dec 2017 12:48:07 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward102o.mail.yandex.net (forward102o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 082DB78ED4 for ; Mon, 18 Dec 2017 12:48:06 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback13g.mail.yandex.net (mxback13g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:92]) by forward102o.mail.yandex.net (Yandex) with ESMTP id A269E5A03BAF for ; Mon, 18 Dec 2017 15:48:02 +0300 (MSK) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:7]) by mxback13g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 8HuDLMVhvl-m2V0HL79; Mon, 18 Dec 2017 15:48:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1513601282; bh=Mkyr4OF7FNV534f1jctrY66Y9+rHvdUsdoZgl81QScU=; h=To:From:Subject:Message-ID:Date; b=GsO3hs4+feBAXllW++ZxiceJirguXRtNJUrKM/0sqJeMJQbEk3vjacTT1etgjKurd xA2DDyuWKXC5sSJa2nx8Z7onRGqJNyShe/BxLLpIvQLWIwfpMxl6NIrIhWRlQlGRcv jQTbKCMPdMQkSWOWHho8LtLY4vhurYcuXI5zejGQ= Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id d7oVdx7WuF-ltsC3cUo; Mon, 18 Dec 2017 15:47:55 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1513601275; bh=Mkyr4OF7FNV534f1jctrY66Y9+rHvdUsdoZgl81QScU=; h=To:From:Subject:Message-ID:Date; b=b1qS4mVaKd/Q+K6j+ypol6iP8GVrAid8kmm7yjqQkQMYeWkQg5XGrbsNeBN2pA8pg RhU+ZXkMsjH6I+4U5xxoM3UOnHHFbBZusUGraBUXB7ACCwKOdK6WxESYkymVJOHaiv 7FG1H/JY8tGE4pCVE5t6+b0RJYZCClhb6/hBP7o0= Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@passap.ru To: freebsd-current@FreeBSD.org From: Boris Samorodov Subject: base packages and subdirs with no regular files Message-ID: Date: Mon, 18 Dec 2017 15:47:55 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit 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: Mon, 18 Dec 2017 12:48:07 -0000 Hi All! I use base package for more then a year now. It works mostly fine. However today I noticed that (some?) blank subdirectories are not removed while updating: --- % LANG=C ls -l /usr/lib/clang drwxr-xr-x 4 root wheel 4 Dec 22 2016 3.9.1 drwxr-xr-x 4 root wheel 4 Mar 3 2017 4.0.0 drwxr-xr-x 4 root wheel 4 Aug 28 14:50 5.0.0 drwxr-xr-x 4 root wheel 4 Dec 8 13:09 5.0.1 --- All previous (to 5.0.1) clang version dirs contain only directories, no regular files: --- % LANG=C ls -l /usr/lib/clang/5.0.0 total 25 drwxr-xr-x 3 root wheel 3 Dec 8 13:09 include drwxr-xr-x 3 root wheel 3 Aug 28 14:50 lib % LANG=C ls -l /usr/lib/clang/5.0.0/include total 1 drwxr-xr-x 2 root wheel 2 Dec 8 13:09 sanitizer % LANG=C ls -l /usr/lib/clang/5.0.0/include/sanitizer total 0 --- I use my personal base package builder and just "pkg upgrade" for, well, upgrades. -- WBR, bsam From owner-freebsd-current@freebsd.org Mon Dec 18 14:17:04 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 D50BCE8DD29 for ; Mon, 18 Dec 2017 14:17:04 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 9CB677C511 for ; Mon, 18 Dec 2017 14:17:03 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-18bc70d5.06-431-73746f70.cust.bredbandsbolaget.se ([213.112.188.24] helo=sigyn.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eQvoD-0007d2-WC; Mon, 18 Dec 2017 14:50:22 +0100 Received: from gw.bright-group.se ([193.12.143.142] helo=[192.168.30.20]) by sigyn.alvermark.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1eQvo9-0004kI-W6; Mon, 18 Dec 2017 14:50:18 +0100 Subject: Re: UEFI booting survey To: Warner Losh , FreeBSD Current References: From: Jakob Alvermark Message-ID: Date: Mon, 18 Dec 2017 14:50:18 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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: Mon, 18 Dec 2017 14:17:04 -0000 On 12/17/17 20:52, Warner Losh wrote: > Greetings > > If you are booting off UEFI and have a bit of an unusual setup, I'd like > you to drop me a line. > > The setup that I'm looking for is any case where you load boot1.efi off one > drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that > drive, but on a different drive on the system. > > An example of this may be loading boot1.efi off what FreeBSD would call > /dev/ada0p1, but having root come from /dev/ada1p1. > > It's my belief that due to the fragility of this setup, few, if any, people > have this setup. If you do, please take a minute to reply to this message. > In the coming months, we're looking at dropping boot1.efi and instead > installing /boot/loader.efi onto the ESP (most likely as > \efi\freebsd\loader.efi). As part of the move to fully support the UEFI > Boot Manager, we're dropping the 'search every device in the system' part > of the current boot1 algorithm. It will be possible to configure the system > to continue booting (either via the new efibootmgr which will allow any > imaginable combination, or possibly via a fallback mechanism needed for the > embedded EFIs that have poor UEFI Variable support at the moment), but as > part of an upgrade to a future FreeBSD 12, some intervention will be > necessary. > > Please let me know if you have an unusual setup like this. > > Warner Hi Warner, I have what I guess is an unusual setup, not like what you describe above, but unusual because I tripple-boot my laptop using only the UEFI boot manager to select the OS to boot. I have FreeBSD-current, OpenBSD-current and Windows 10 on different partitions on one SSD. By default it boots FreeBSD. This was accomplished with bcdedit.exe in Windows, but now I realize this could be done with the new efibootmgr. I wanted to try it out, but it panics on my laptop. Sometimes just 'kldload efirt' just panics, sometimes it loads but panics as soon as I run efibootmgr or efivar. How can I help debugging this? Jakob From owner-freebsd-current@freebsd.org Mon Dec 18 14:39:01 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 37061E8F816 for ; Mon, 18 Dec 2017 14:39:01 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16F497D46E for ; Mon, 18 Dec 2017 14:39:00 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBIEejHF086386; Mon, 18 Dec 2017 06:40:52 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: In-Reply-To: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "antranigv" Subject: Re: r326820 stuck on bootloader Date: Mon, 18 Dec 2017 06:40:51 -0800 Message-Id: <4f7ac727d809b1336e23399122113b02@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Mon, 18 Dec 2017 14:39:01 -0000 On Mon, 18 Dec 2017 13:45:11 +0400 "antranigv" said > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hey all! >=20 > I have just downloaded > FreeBSD-12=2E0-CURRENT-amd64-20171213-r326820-memstick=2Eimg=2Exz and > decompressed it, trying to boot it on QEMU and I get "Consoles: > internal video/keyboard" and then it's stuck=2E >=20 > I actually have no idea how to debug, any help would be appreciated=2E There was a problem in this area introduced somewhere in the beginning of December=2E Warner just landed the correction(s) yesterday (I don't have the revision handy)=2E But it doesn't look like an install image with those chances has been cut yet=2E Your best option as it stands, it to download: https://download=2Efreebsd=2Eorg/ftp/snapshots/ISO-IMAGES/12=2E0/FreeBSD-12=2E0-CUR= RENT-amd64-20171121-r326056-memstick=2Eimg=2Exz Which was cut before the regression=2E After installation=2E You can svn up to the latest revision, and build from there=2E Thereby getting the fixes Warner just added=2E HTH --Chris >=20 > Thanks in advance, >=20 > - --=20 > antranigv > https://antranigv=2Eam/ | PGP Key ID : 0xDAB81456 > /* do one thing and do it well */ > -----BEGIN PGP SIGNATURE----- >=20 > iQIzBAEBCAAdFiEEfrjE/88u0Kph7jFZYGhrFNq4FFYFAlo3jiIACgkQYGhrFNq4 > FFbuWw//du5kjUIR442fkCaCg8honaeZFJ666iwQE1grsSQS74kYzwQ1iSXBnGLV > kPt6Nslz3YIRmIqDMuKr31a6zK33bLi7hfKbodIcPNIn/EBUY/D/Pq4FXgqZxu99 > MGDAsbLafA3YhyeVuilxrHyDZjaUMDGfJCcBBB57/SxY9mEFT3g/zw1vdVDwpe52 > /0bi3u3r/H4l88KGtECSI08WlqnpDyPeGuHImb/xrkQmGbl6PiHwvrijOP639JDf > OpDEvLENRIwIBGYxsJPBk3EBPYEgpJKPm1yTU1swU/KJlCpau9O9WrG6OqO8qflO > HOCzyhKvXJdXkphlVBLfYk6e8NKwHwc+7ZaMEDJDvqGJ9qFWXanALBkBRyREW61K > ZY/8uLhoKNjPmAAMBgwbPihf35zWEXZhKLsaMza5f5NNniLCRrn+I4QhvhWlp10u > 20tKX0bAJ+0sjQZInfqXftEwD5Mhw+H1sM1vk8igFFWyrMPCG9t0piV/AseixgDu > SZ9IGl5EZSpq/q6Jhcjfxlplwi31SwkVWIRjDqBmzcVcYQO6khszCdi3S1b9Y5El > T6gIswPuPWboJFGjPJxQN9V3APNUXT6c2p0aXq8S4NcvSRRmhyEc9mgc/LZrAX4a > hwQSVmtJL15qhvBc6TgWEBAaLL9+eX2G9G2Wr1ZEBg5tx/1eY/I=3D > =3DTQCj > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Mon Dec 18 13:35:37 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 35FFFE8A7E1 for ; Mon, 18 Dec 2017 13:35:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F01757AA7E for ; Mon, 18 Dec 2017 13:35:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBIDZYBx016146; Mon, 18 Dec 2017 05:35:34 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBIDZXNb016145; Mon, 18 Dec 2017 05:35:33 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> Subject: Re: r326820 stuck on bootloader In-Reply-To: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> To: antranigv Date: Mon, 18 Dec 2017 05:35:33 -0800 (PST) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 18 Dec 2017 16:05:18 +0000 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: Mon, 18 Dec 2017 13:35:37 -0000 > Hey all! > > I have just downloaded > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > decompressed it, trying to boot it on QEMU and I get "Consoles: > internal video/keyboard" and then it's stuck. > > I actually have no idea how to debug, any help would be appreciated. This snapshot may have broken boot code in it, I had problems installing it to a zfs system and had to post install replace my zfs boot blocks from those of 20171206. > Thanks in advance, > - -- > antranigv -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Dec 18 14:06:20 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 7CC66E8CBEC for ; Mon, 18 Dec 2017 14:06:20 +0000 (UTC) (envelope-from antranig@vartanian.am) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 458967BDFE for ; Mon, 18 Dec 2017 14:06:19 +0000 (UTC) (envelope-from antranig@vartanian.am) Received: by mail-ot0-x233.google.com with SMTP id e74so13412534ote.7 for ; Mon, 18 Dec 2017 06:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vartanian-am.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L+HYDhaAyI7N1oL9ko37kJCSZMD5JpfhLrc1q0VHS+E=; b=Zyu0zP5+O2ZDt4bSX5/4lhcKBVjfmk/blFEWtVJvc7Yf5xgM6Km3oYvhFr8ONWhxxo OVYgiWoq5e2plHbnOJgodRYHDKF8nLObC8J6VIbxsLlspgWWpoGoLNXeyBPAAQQh/lg8 iQqtulSboYKG9hxrSY/xduWAZ6XkuTHma8brROkxqYFf1efaQY/62DZGEeb+Tdf7pgZk t/Z2jgg19i6/nfDl1VNaomJtfFxJDEw3ZVIQaf9Az7OEDsWmOV3QMzEeNIIHYn1Z8xzx Ob+BoxvY7WCMYn9WM90OzTdH1F3orrg6qRgwW9o+o+P0uxKFFq1Thwl83bKaZ8HyvM3o MUjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L+HYDhaAyI7N1oL9ko37kJCSZMD5JpfhLrc1q0VHS+E=; b=HH10IRPH9zX2aHZACjWR7gVfKFQ1Jm6pd1ejq3U+F4C1oLPi2qD0Nh3C7zlmsstEhe IyGHak8FilcUoVFz7ykgMmSa7OkwrtE34A4n23SXGhc9esIxtxthn+kTXDEOPls44rDl 61OPfsfl4slJMld3KBIH3GsGYLOomhOTfpIGpP1+gzU8BwueAygX3tf/9PF+9cS896Yi XlJ8eluDvmxCnSfpMbP1iWyx3tDfNQZuVU6X0KfV5e8kEYbPYR8y0kIckncuGwX4BAmQ aB/Eejfp2h3I1EfhxsODYnH6jELpZfpiDlye8SD1a4QjiF4upHPWxkHDLoBzsjfjpAy+ uo1g== X-Gm-Message-State: AKGB3mLknkZA9UijJIIuh7CLI32n6JSZ7zzU/SPTDqNCoBkrpYtmyVgu 2x9xxjsaqYRynXW+5zQ0iA+H0kvpQlynFneQT/syy35+ X-Google-Smtp-Source: ACJfBosnnR68DpkbvhEaWm+ICfyT6IUDPcA1WAXU6NkCmQD8v6iz4PuX2spzO8CMi4MVIWTqMRPA82v1vRNK4k89THU= X-Received: by 10.157.12.74 with SMTP id 68mr13954886otr.368.1513605978428; Mon, 18 Dec 2017 06:06:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.205 with HTTP; Mon, 18 Dec 2017 06:06:16 -0800 (PST) X-Originating-IP: [82.199.210.244] Received: by 10.157.14.205 with HTTP; Mon, 18 Dec 2017 06:06:16 -0800 (PST) In-Reply-To: <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> References: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> From: Antranig Vartanian Date: Mon, 18 Dec 2017 18:06:16 +0400 Message-ID: Subject: Re: r326820 stuck on bootloader To: "Rodney W. Grimes" Cc: freebsd-current@freebsd.org X-Mailman-Approved-At: Mon, 18 Dec 2017 16:11:08 +0000 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: Mon, 18 Dec 2017 14:06:20 -0000 Ok, I will install the snapshot before. but is it fixed now? since after the installation I will do buildworld, hope it will not brick. Thanks a lot! -- antranigv https://antranigv.am/ | PGP Key ID : 0xDAB81456 /* do one thing and do it well */ On Dec 18, 2017 5:35 PM, "Rodney W. Grimes" < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > Hey all! > > > > I have just downloaded > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > internal video/keyboard" and then it's stuck. > > > > I actually have no idea how to debug, any help would be appreciated. > > This snapshot may have broken boot code in it, I had problems > installing it to a zfs system and had to post install replace > my zfs boot blocks from those of 20171206. > > > > Thanks in advance, > > - -- > > antranigv > > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-current@freebsd.org Mon Dec 18 14:16:14 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 E3D92E8DC6A for ; Mon, 18 Dec 2017 14:16:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C64D77C4E6 for ; Mon, 18 Dec 2017 14:16:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBIEGCTu016461; Mon, 18 Dec 2017 06:16:12 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBIEGCKd016460; Mon, 18 Dec 2017 06:16:12 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712181416.vBIEGCKd016460@pdx.rh.CN85.dnsmgr.net> Subject: Re: r326820 stuck on bootloader In-Reply-To: To: Antranig Vartanian Date: Mon, 18 Dec 2017 06:16:12 -0800 (PST) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 18 Dec 2017 16:14:49 +0000 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: Mon, 18 Dec 2017 14:16:15 -0000 > Ok, > > I will install the snapshot before. but is it fixed now? since after the > installation I will do buildworld, hope it will not brick. The boot code is in a lot of flux right now, so be carefull and pay attention to commit mail. You should keep the memstick image around for repair incase you have issues. > Thanks a lot! > > -- > antranigv > https://antranigv.am/ | PGP Key ID : 0xDAB81456 > /* do one thing and do it well */ > > On Dec 18, 2017 5:35 PM, "Rodney W. Grimes" < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > Hey all! > > > > > > I have just downloaded > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > internal video/keyboard" and then it's stuck. > > > > > > I actually have no idea how to debug, any help would be appreciated. > > > > This snapshot may have broken boot code in it, I had problems > > installing it to a zfs system and had to post install replace > > my zfs boot blocks from those of 20171206. > > > > > > > Thanks in advance, > > > - -- > > > antranigv > > > > -- > > Rod Grimes > > rgrimes@freebsd.org > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Dec 18 16:17:08 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 8E8CAE974C2 for ; Mon, 18 Dec 2017 16:17:08 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DFD81D66 for ; Mon, 18 Dec 2017 16:17:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.187.99]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Metpl-1eg1yJ0QjB-00OYoT; Mon, 18 Dec 2017 17:16:54 +0100 Date: Mon, 18 Dec 2017 17:16:20 +0100 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: antranigv , freebsd-current@freebsd.org Subject: Re: r326820 stuck on bootloader Message-ID: <20171218171647.384ae7f2@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> References: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/.RT=V1ur2EIz5WVdzs5.Odm"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:VE4Cbqt2+sGXZ7F7mTnDsWlJBs7r2n5AfFyAmWyR6tokyCOS0QA hdQb0p0flH7huendqSfQ70hbs1h8nloBZHvifYrNrRhDE79adp8vLLONLLE6Focp/0VWtye Q9Dyn49vdELraYfTFx9QsWMxLyBZaOd0c/Tot8ImGWdEJU3mrGDsE/UmbqCsPpWOHI3XTzn lMxgUEOQUNRzvEGBgbJWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:gV5hi77MMNI=:vBIs4KS3aOoIKZPsA6Ft8B 9P1OkMBYa9LnkYftSbkDVqMwjPV4ErcVxFaEIyhF3F2JvDkJmFUXuEG8LFPYARFv5JeoulscD h7ru4119ny94x/fSwuJeBI1Kx3/4Oss/cPbBHEsrWvbdKR7EMj/Xu+QKmsuhQ1Z8NR8gQ/VN9 kzxHFU6eeyCddVWIuLUH5/PaEvlqKx9HCyWJTnQ3YEMnFLd00daq4JEOzyhZXu9L5p2HwuUY5 lf5F7A61SG9RWLcY/HDT+Xu+n4Ol3ai4P+p1W0GZnC6tGjp/FWAuXV+Gx7F357+BP1KjrKBX9 G3Ycqgxsk3MUzlshHxD3/vo/nq7S9F91j/gxA9sBleunMMc8PbgoR5XNheEXL9+d/uRu6x+wP zuioeUzjAa5FTO5oTYmGX2N241Uz+nWzDHMOgnRlcxvZz9TGRZDBntfsF+n0BthiTgwIXcmmx lZyG6AHdc0UtUTXBMsj7j850EUrV46QiAZ2judd2QpUzqmPCrvmsSJElb8iULghKnVUsim/JO ca1xaLHKaZ/JMPPIjjSOw4mOymx62wsz3mbr+bTqiX8LOI6+NnIp+FAYeuD7SFeNMSy31bRC0 YPP6xBoKbIO7mlF1vzDQI3n22wnZfeU9LxOrHIBKfPHZDFLj3V+nkMUUHbx41NVpLq/F0qlyJ jdAC5zak9DdfYXgWOzGP63VDwTk7dQckit0m4Qr1QQx9tDajFUhtZNshYdquDLi55oLqsLDRA D5ka9OMM3e2RD21zKPxul4VSi/fJ9mmnC9mkivDNZLXkkgqyd4ofrD10GBnfVnq1tsrtSBllt 4ETiTyRq7lRh0nFjLQwfEzxpvJH/w== 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: Mon, 18 Dec 2017 16:17:08 -0000 --Sig_/.RT=V1ur2EIz5WVdzs5.Odm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) "Rodney W. Grimes" schrieb: > =20 > > Hey all! > >=20 > > I have just downloaded > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > internal video/keyboard" and then it's stuck. > >=20 > > I actually have no idea how to debug, any help would be appreciated. =20 >=20 > This snapshot may have broken boot code in it, I had problems > installing it to a zfs system and had to post install replace > my zfs boot blocks from those of 20171206. >=20 >=20 > > Thanks in advance, > > - --=20 > > antranigv =20 >=20 The shit hit the fan at > r326593 (this is what Warner wrote me back, I had= no problems with r326583, but r326584 and beyond had compilation issues). I tried r3265= 93 and it worked for me (had issues on a serial console for the PCengine APU2C4). =46rom usr/src/UPDATING, tag designated by "20171215": 20171215: r326887 fixes the issue described in the 20171214 UPDATING entry. r326888 flips the switch back to building GELI support always. [...] I tried the first time r326888 on the APU 2C4 and it worked again - this do= esn't imply that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh s= tated it is fixed. I'm with FreeBSD 12.0-CURRENT #16 r326911: Sat Dec 16 20:49:38 CET 2017 amd= 64 and it is working well so far. Kind regards, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/.RT=V1ur2EIz5WVdzs5.Odm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjfp7wAKCRDS528fyFhY lIJjAf9JI1KJEQ5/TL7+dDzyH35K06YnF95MtnAuLPjWy7vX+Pt/MkSMH6i/1WrV QgiqJIvE/WxbxXK/8EmmIWW6NzWXAf45XOYpqVeDl7RWFWUvZFYBVpfK+mddAar5 hS6Ap1MeVaZSeucXstOb6urjSx81lwYcwye1enWl3Ax5E8sYMEPT =BpZz -----END PGP SIGNATURE----- --Sig_/.RT=V1ur2EIz5WVdzs5.Odm-- From owner-freebsd-current@freebsd.org Mon Dec 18 16:47:12 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 8200AE99DC8 for ; Mon, 18 Dec 2017 16:47:12 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 618C53AC4 for ; Mon, 18 Dec 2017 16:47:12 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBIGmvjq094567; Mon, 18 Dec 2017 08:49:03 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: , "antranigv" In-Reply-To: <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Rodney W. Grimes" Subject: Re: r326820 stuck on bootloader Date: Mon, 18 Dec 2017 08:49:03 -0800 Message-Id: <0cc30f3ae9bbac71deb1f4c132d8d795@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Mon, 18 Dec 2017 16:47:12 -0000 On Mon, 18 Dec 2017 05:35:33 -0800 (PST) "Rodney W=2E Grimes" said > > Hey all! > >=20 > > I have just downloaded > > FreeBSD-12=2E0-CURRENT-amd64-20171213-r326820-memstick=2Eimg=2Exz and > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > internal video/keyboard" and then it's stuck=2E > >=20 > > I actually have no idea how to debug, any help would be appreciated=2E >=20 > This snapshot may have broken boot code in it, I had problems > installing it to a zfs system and had to post install replace > my zfs boot blocks from those of 20171206=2E Like I said; I can confirm r326056 (2017-11-21) doesn't contain the boot regression=2E Warner advised me to try an earlier version when I indicated I had the problem you also described in this message=2E Yesterday, Warner indicated he believes he has corrected this regression, as well as add some other goodies=2E So it should be safe to svn up to the latest revision, after your initial install, and build from there=2E --Chris >=20 >=20 > > Thanks in advance, > > - --=20 > > antranigv >=20 > --=20 > Rod Grimes =20 > rgrimes@freebsd=2Eorg > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Mon Dec 18 16:48:03 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 85F08E99FC5 for ; Mon, 18 Dec 2017 16:48:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 456853C51 for ; Mon, 18 Dec 2017 16:48:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id e204so10464668iof.12 for ; Mon, 18 Dec 2017 08:48:03 -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=aBlytzWZ535DNh3OX5FcXaXL3W47YJ3xNW657JvvuBw=; b=gELw3AdaAj1c9Rc6euwupnoPj+I5YPfmutdKJT9S88Mndu+W1w5QZ3R62UBPfjKCTv WyRV1x8Dk0kDZ8U+uSWWzfwD3OigjPpZ/jkTXMgdU+nYUGHWXTaFAaXsj5IE/1WIH3gq Q8EeYAWeBkRO2ov/2DhfR7oEolFXLDomlofI0cmm/X9F99laWjyiVvmhHVqqYjsLA6xb a9ePmSI/opFQsD2RicjISCpk1M+WJdOSeXHBAQ8mUibjoTAW+NLpTLAxFsA5lX1Ya4Ih 1zSyWjgL4CBy9DjTZJp+BOJb0HkoAWul3o8MbAdsxrKqGhQslC4REgVNcaBZWnhFnHii 3dTQ== 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=aBlytzWZ535DNh3OX5FcXaXL3W47YJ3xNW657JvvuBw=; b=mS758FrzMmP8/meIIoXin0rZWXcpxc4btf6ROZyhFI4zVsDOVcJepx7THq13/lUCrr OOExlrNvKkc1O6fSbDdmaoG3cCeolJZY/CHuHFWbQnkLI12NP6+HeMDI2RtcLumESQfe WmVJxNJzCeCkUaTex9yic2PhYiqTl9l/Ilg9oiOWlfv09vi3w4NSU93hsreAHYVPIBbX 9lQKbN9uCwpvovxLvMP6T6ec4a1nyjWz3fUvExpakSmoPM9xVUI/hlorQ/FX8Y6Hm+OU cEUL47w0DOrxcb0+uQeQ1vcxk37JBSqzv1X2B3QtD5w1d1p2Cm6oeYv5JasKR2L5mRO4 /9LQ== X-Gm-Message-State: AKGB3mKdnxgI2Wl5X+h4qIjEyNxEy8cXz3/PsapFWm3hX4NVbFg13Jmr qNB4bGjFjHSjAVvU7bKbDZKXhgfHkpKxWaAddOovyg== X-Google-Smtp-Source: ACJfBot73LBpS18chshPXwg1N4LO6e2BtSe0dgsMWHfAWeZkVzh8VUegZXeXiD+oJ/+gXjh6Ub2nd/n2aw6y6Ra3ut4= X-Received: by 10.107.18.35 with SMTP id a35mr448411ioj.291.1513615682406; Mon, 18 Dec 2017 08:48:02 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 18 Dec 2017 08:48:01 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171218171647.384ae7f2@thor.intern.walstatt.dynvpn.de> References: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> <20171218171647.384ae7f2@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Mon, 18 Dec 2017 09:48:01 -0700 X-Google-Sender-Auth: eNOlbQFIQfl04TadSZwykcwFm1o Message-ID: Subject: Re: r326820 stuck on bootloader To: "O. Hartmann" Cc: "Rodney W. Grimes" , antranigv , 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: Mon, 18 Dec 2017 16:48:03 -0000 On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann wrote: > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > > > > Hey all! > > > > > > I have just downloaded > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > internal video/keyboard" and then it's stuck. > > > > > > I actually have no idea how to debug, any help would be appreciated. > > > > This snapshot may have broken boot code in it, I had problems > > installing it to a zfs system and had to post install replace > > my zfs boot blocks from those of 20171206. > > > > > > > Thanks in advance, > > > - -- > > > antranigv > > > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I > had no problems > with r326583, but r326584 and beyond had compilation issues). I tried > r326593 and it > worked for me (had issues on a serial console for the PCengine APU2C4). > > From usr/src/UPDATING, tag designated by "20171215": > > 20171215: > r326887 fixes the issue described in the 20171214 UPDATING entry. > r326888 flips the switch back to building GELI support always. > > [...] > > I tried the first time r326888 on the APU 2C4 and it worked again - this > doesn't imply > that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh > stated it is > fixed. > Yes. I've confirmed that zfsboot works with or without the GELI code compiled in. I've not confirmed that ZFS + GELI partitions work. I haven't updated my test scripts in tools/boot/genroot.sh to create them yet. If someone who knows this stuff really well wants to do that for one image (gpt + zfs + geli) I can (a) test and (b) generalize. Warner From owner-freebsd-current@freebsd.org Mon Dec 18 16:53:30 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 B985AE9A7A1 for ; Mon, 18 Dec 2017 16:53:30 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39EFF63529 for ; Mon, 18 Dec 2017 16:53:29 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.187.99]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MSMw7-1eb3WI261b-00TWoO; Mon, 18 Dec 2017 17:53:17 +0100 Date: Mon, 18 Dec 2017 17:52:41 +0100 From: "O. Hartmann" To: Warner Losh Cc: "O. Hartmann" , "Rodney W. Grimes" , antranigv , FreeBSD Current Subject: Re: r326820 stuck on bootloader Message-ID: <20171218175308.139afde8@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> <20171218171647.384ae7f2@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/ao1i4xago9Uh.o4iVPJILBN"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:fnmXz80m6HznJjnRoRU4IOSbHOfWtbPyPJhREL4Ka7U8QtooJFj fVOc9iwBxjFcs9QH7BLrwmmqUB7nL6hrt1H2BR0GMoUH7qMU2d2keDMXyZ+OydQe4Yh60b0 WWfFjhvAVwB1CX1G+vjCcFaFKDTrRMq6oL0qoFQaRQLzTf9hxasyZqH0CHyVZpm8f8b4DL2 j6WaX0OPcBMZH7Q7XHJrg== X-UI-Out-Filterresults: notjunk:1;V01:K0:pOKwV/3HYqo=:Dm+djG1UA4kpH7A5oS9SsW xUPxXmWy0ROA+OgKcQjW8ov25FNctwZKB8MX4xD3bitXmAEKW/5N+HrkdESHt/oM6v0fyHWo2 Oxdd/9NAXbanRZQOLhCuAYlIcH+L4nWGz52lwWL2pB+c28OCTjrlOJzn+rQri/pE3TcFzhQWN nkFdyNS9+ISxYAD6h1VWSXW3kPiZOn0CKvo4TYJetu8ynAsCerumiVaa9AOrPJdlSr4cHPP5L yc/X88/GBjVZaa+MquPbVGHEuFSVVYiQHfJyf34EaqpfjOVILQPtAzuoUeq7fUh2brvy0anSS l6/9JNjHUz9IcmyxzEWLMUeJIkNGx7qrn/SO1KcdgXJdrqcsE0HMaZYNQomWctpT+bumeM5ak SsDv5kYfwRxzNRZ7vDe34Fi3CfGG5pLtdE3Sdw32x3JgESL21i1AmkrW1iSFXpWvnpMLk+wNJ dcISUDOTnTE4LPZDaAc3pV0/7kdKVhbhIfM+16Ykhn+k4Vj2wd15PaGIs3a7+3bOdM51NMoGW bNpMEIyS9He383lcE5uxZFAgHa7xs7F8WQsPRoTWfzl/kw7zvCNRWieRwQTilv8GxzCzDY2KW gdADZTwu1a7SIMTzHnI2YXtLipQs+yS6OSe0eLEbha4oT/r/ZG4ta8l/2f9+TTnnefq3CPVwN fwEE+14LVC75pFxGKvXldFTPOIL+/DiCdDaTSrREVfq7mNq7EYwaCTv7vU/VFkG3SP7RjKvh4 AXSwtZeIMhzsrGIcKUod4DMD/2MSMscFiC+Mt8XS0CpKX6N2yGu4IfFWZQL6sKNCE38T9QP1G EVTm6dxAoYQoXc/y/DK03JSape9jw== 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: Mon, 18 Dec 2017 16:53:30 -0000 --Sig_/ao1i4xago9Uh.o4iVPJILBN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mon, 18 Dec 2017 09:48:01 -0700 Warner Losh schrieb: > On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann wro= te: >=20 > > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) > > "Rodney W. Grimes" schrieb: > > =20 > > > =20 > > > > Hey all! > > > > > > > > I have just downloaded > > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > > internal video/keyboard" and then it's stuck. > > > > > > > > I actually have no idea how to debug, any help would be appreciated= . =20 > > > > > > This snapshot may have broken boot code in it, I had problems > > > installing it to a zfs system and had to post install replace > > > my zfs boot blocks from those of 20171206. > > > > > > =20 > > > > Thanks in advance, > > > > - -- > > > > antranigv =20 > > > =20 > > > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I > > had no problems > > with r326583, but r326584 and beyond had compilation issues). I tried > > r326593 and it > > worked for me (had issues on a serial console for the PCengine APU2C4). > > > > From usr/src/UPDATING, tag designated by "20171215": > > > > 20171215: > > r326887 fixes the issue described in the 20171214 UPDATING entr= y. > > r326888 flips the switch back to building GELI support always. > > > > [...] > > > > I tried the first time r326888 on the APU 2C4 and it worked again - this > > doesn't imply > > that the GPT GELI and ZFSBOOT loader are all right again, but Warner Lo= sh > > stated it is > > fixed. > > =20 >=20 > Yes. I've confirmed that zfsboot works with or without the GELI code > compiled in. I've not confirmed that ZFS + GELI partitions work. I haven't > updated my test scripts in tools/boot/genroot.sh to create them yet. If > someone who knows this stuff really well wants to do that for one image > (gpt + zfs + geli) I can (a) test and (b) generalize. >=20 > Warner Oh, my bad. So it is still to use with caution? At that point I can not understand why the build of bootable images is stil= l in progress. People which desperate in need of a bootable image may download the wrong o= ne from the FreeBSD site - and find out the harsh way it is broken. If the build of tho= se images is automated - can this be stopped? --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/ao1i4xago9Uh.o4iVPJILBN Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjfydQAKCRDS528fyFhY lMAUAf9wP4TjnV1ibKv1eIXSQKcx+rp5b1leqF8WEXnvI+0Pc/Exv9mxAhHwMHe3 gc8G6KOYTGY6Io91AUSxIKjJ+zWPAgCEz+V7yaDzVWuTgJI2uwb0f5CVcB/+k8OY A8RMeGYlk8ymU0k39tdnuUytCn2CP1GfeGQR79wBLH+sUUZkgEQI =/40Q -----END PGP SIGNATURE----- --Sig_/ao1i4xago9Uh.o4iVPJILBN-- From owner-freebsd-current@freebsd.org Mon Dec 18 16:58:32 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 C4054E9AE1A for ; Mon, 18 Dec 2017 16:58:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 86172638A3 for ; Mon, 18 Dec 2017 16:58:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id u62so29106952ita.2 for ; Mon, 18 Dec 2017 08:58:32 -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=p0nnOI+fRUiPEMkMvK4d0sL+f5oYjtgweVEC/2UonOA=; b=IhtotVvEuKrQ1KyOrPhmbhALXt+0NVMuEM6U1TFyKpXbBy3Q+jAWciRB+FYag8Kx0W EJg2kum+v7qjCUx1+1ar8n0SNGTuP6zbWANnDFd3+fEBd4R3DuicM8BFWa5zcPYCCinL bm28cq2hrjcQpEkMUmNosOshIhCN6zq8I/3MIqqI2i+oq6gIf2sElLQCyKbXySMqpL5J OoTRqZrlRJa4/pt/AdF+1CBLtu7nLbvzAYcmv6+mcp4EwZeIfdzFS6LddjhcACntzaUN lx+0MLXiP+dr6obMHp9xHahjtLY/cbGOvC41xpuVrZpFvirdIqJOpWHGVMU57tZhn/eu JUyQ== 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=p0nnOI+fRUiPEMkMvK4d0sL+f5oYjtgweVEC/2UonOA=; b=MTd16uqIaKw/FYT80+C0nyGaEkTUjKpIo569ikSNxUIUf/Td+939CyqXLJy9dXMxCt WKTid72d61TUfBQCtKdDe4bsw02IBnlV0VvOU5BCMd0ObZKIx0yTEjh/nf28SiscR4Du 4+kOlDlML3aAlz75roKloh6NiOeC5bTZZ/M6f3cSENX7MISxB52DYnVJHpseTNH5CCyd gTN5RS9Ch6iQzYJU9Tw7rU6KNFUbJLNConZp2JskmWvhBsb523KG8HhKAChQ0ac/nKC7 xqqdrBkZPhdh4wCFOMHSgj4fTe/XhUYNOpAqg9yDjAuRV2nyCI3/4jdTFKTaHVTcVhIN F+Aw== X-Gm-Message-State: AKGB3mK6FZ/iubBnvfxa/rCMoD17Og8andrYo5AXvNSeE8U3eP6Xl4Jq H1Np8FUFlGb7gPLtsQC9GI4Id/cQ9cR8/W58yvtJjA== X-Google-Smtp-Source: ACJfBot1sTIXwoJ6cTX39wP2h0nyvTNxURKwLqUia1Mn+Kjdt/r9RuUf7qVskjJ/xsJWCt8uEVlxmaxz5HIleyZboLA= X-Received: by 10.36.164.13 with SMTP id z13mr393452ite.115.1513616311263; Mon, 18 Dec 2017 08:58:31 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 18 Dec 2017 08:58:30 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171218175308.139afde8@thor.intern.walstatt.dynvpn.de> References: <9038c936-17db-1405-4d1b-5995ddabfa33@vartanian.am> <201712181335.vBIDZXNb016145@pdx.rh.CN85.dnsmgr.net> <20171218171647.384ae7f2@thor.intern.walstatt.dynvpn.de> <20171218175308.139afde8@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Mon, 18 Dec 2017 09:58:30 -0700 X-Google-Sender-Auth: -WkpqaTILywH0kOgnOCeX7DO5uE Message-ID: Subject: Re: r326820 stuck on bootloader To: "O. Hartmann" Cc: "Rodney W. Grimes" , antranigv , 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: Mon, 18 Dec 2017 16:58:32 -0000 On Mon, Dec 18, 2017 at 9:52 AM, O. Hartmann wrote: > Am Mon, 18 Dec 2017 09:48:01 -0700 > Warner Losh schrieb: > > > On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann > wrote: > > > > > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST) > > > "Rodney W. Grimes" schrieb: > > > > > > > > > > > > Hey all! > > > > > > > > > > I have just downloaded > > > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and > > > > > decompressed it, trying to boot it on QEMU and I get "Consoles: > > > > > internal video/keyboard" and then it's stuck. > > > > > > > > > > I actually have no idea how to debug, any help would be > appreciated. > > > > > > > > This snapshot may have broken boot code in it, I had problems > > > > installing it to a zfs system and had to post install replace > > > > my zfs boot blocks from those of 20171206. > > > > > > > > > > > > > Thanks in advance, > > > > > - -- > > > > > antranigv > > > > > > > > > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I > > > had no problems > > > with r326583, but r326584 and beyond had compilation issues). I tried > > > r326593 and it > > > worked for me (had issues on a serial console for the PCengine APU2C4). > > > > > > From usr/src/UPDATING, tag designated by "20171215": > > > > > > 20171215: > > > r326887 fixes the issue described in the 20171214 UPDATING > entry. > > > r326888 flips the switch back to building GELI support always. > > > > > > [...] > > > > > > I tried the first time r326888 on the APU 2C4 and it worked again - > this > > > doesn't imply > > > that the GPT GELI and ZFSBOOT loader are all right again, but Warner > Losh > > > stated it is > > > fixed. > > > > > > > Yes. I've confirmed that zfsboot works with or without the GELI code > > compiled in. I've not confirmed that ZFS + GELI partitions work. I > haven't > > updated my test scripts in tools/boot/genroot.sh to create them yet. If > > someone who knows this stuff really well wants to do that for one image > > (gpt + zfs + geli) I can (a) test and (b) generalize. > > > > Warner > > Oh, my bad. So it is still to use with caution? > I have good reason to believe it will work. I fixed the underlying issues that were broken in '593, so I think it will work again. I just haven't confirmed it and hoped that someone else could get to it before I could :) > At that point I can not understand why the build of bootable images is > still in progress. > People which desperate in need of a bootable image may download the wrong > one from the > FreeBSD site - and find out the harsh way it is broken. If the build of > those images is > automated - can this be stopped? That shouldn't be necessary. The normal images should be fine. Warner From owner-freebsd-current@freebsd.org Mon Dec 18 20:21:21 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 F2F03E844F2 for ; Mon, 18 Dec 2017 20:21:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 B440A6E11A for ; Mon, 18 Dec 2017 20:21:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ua0-x22a.google.com with SMTP id i20so11515558uak.6 for ; Mon, 18 Dec 2017 12:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PFawPzCQHSHqsvjRvGc3ZzqIbEbJhzp918j8lDsfGb0=; b=IRqySzx9NXVianK2REHqQQiBPeu/pVTk2c69ryw+0kO2/Ai8CQqmi0uh0DEKfvtjY0 7dHCmYCpf/YtRj2NV3zouyvM3HorCdNOTVpMA4ytstlrqk0EjTy7yVgFRsIZMZSA9nSD muQ4pBJPfF9JlVuaOcmZBaCr4GpVH/k/OIjG4o0Lv6GSenaIjUlcHWqLFc/31tSOyCNF zHAIsygbApo6sAhJdpSxBoS7+HX3gQ0kpMHuj0GqfgXtoNRtDMD9OZKrxmdCjvWDRwMX qbF07jnuwSKAea4NRcymssJjYoI8G6lbRJjGInOQGJP8icQDLUpx+znKkKbAzVN5RBic 9MrQ== 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=PFawPzCQHSHqsvjRvGc3ZzqIbEbJhzp918j8lDsfGb0=; b=P//2iAp4DP8B+ffowpkBEfy4OcATgjXU79RQsQiopB688NjCxdEjhEUZ2sttJmlm2r opSgFj6NNUfSyirKWBp8Q71x9mgxI61Be9riqTFdKcU3U0yJbbkCedsGfAMkaPBNZ5Ri 0FUxVGBruJh190sNhP00HU262DEkbJ2M5Yke6M/ASXnRHC8ToWPj8/QlSwFs8ng5mtWf awfYHPhwxhEUxAjqXq2H1aWxXqlPS37aY0hDZ8LgvFwM6XNFYlmZan3JFzmn9BfgxeDd JZR/mymsouf/VA11tuxSAun0YhnqV/DMbbcDud2Mw1u+Cl7BGc+KGDkAS40cUZX7ugQc QPMQ== X-Gm-Message-State: AKGB3mI5sfjQrv9/fojMXp+Z7bHF5M0FgEJLJwexLhNFIRXGSefIdbwD wcbJzhzlKqjuX9mrXswUFG6k3pW9WelIqo+brnWUSA== X-Google-Smtp-Source: ACJfBovcYErRAVpccQ7w7pl6LPZJoTEo18UZmcHHNRoj0Hnv53Uj/koP8PB8+C2Mgktik3u7HNuBtDB8NXVSdlHLkHM= X-Received: by 10.176.25.70 with SMTP id u6mr1139542uag.114.1513628480719; Mon, 18 Dec 2017 12:21:20 -0800 (PST) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.176.14.25 with HTTP; Mon, 18 Dec 2017 12:21:20 -0800 (PST) In-Reply-To: References: From: Maxim Sobolev Date: Mon, 18 Dec 2017 12:21:20 -0800 X-Google-Sender-Auth: Zlv_mx2VLJ_OP5J0kr59QV0BP0A Message-ID: Subject: Re: UEFI booting survey To: Jakob Alvermark Cc: Warner Losh , 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: Mon, 18 Dec 2017 20:21:22 -0000 Not really specific to UEFI, but when ZFS is in use the /boot might be partially or fully located on the drive that does not correspond to your boot drive. We've bumped into this issue on AWS recently when our kernel ended up on second drive after upgrade in a pool that were spanning two EBS volumes. Now, it does not work with AWS (as boot code only has access to the boot EBS volume apparently), but according to Alan such scenario is totally supported on a physical hardware. So I am worried that by not allowing loader to scan all drives in the system you'd make this scenario fundamentally impossible. -Max On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark wrote: > On 12/17/17 20:52, Warner Losh wrote: > >> Greetings >> >> If you are booting off UEFI and have a bit of an unusual setup, I'd like >> you to drop me a line. >> >> The setup that I'm looking for is any case where you load boot1.efi off >> one >> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that >> drive, but on a different drive on the system. >> >> An example of this may be loading boot1.efi off what FreeBSD would call >> /dev/ada0p1, but having root come from /dev/ada1p1. >> >> It's my belief that due to the fragility of this setup, few, if any, >> people >> have this setup. If you do, please take a minute to reply to this message. >> In the coming months, we're looking at dropping boot1.efi and instead >> installing /boot/loader.efi onto the ESP (most likely as >> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI >> Boot Manager, we're dropping the 'search every device in the system' part >> of the current boot1 algorithm. It will be possible to configure the >> system >> to continue booting (either via the new efibootmgr which will allow any >> imaginable combination, or possibly via a fallback mechanism needed for >> the >> embedded EFIs that have poor UEFI Variable support at the moment), but as >> part of an upgrade to a future FreeBSD 12, some intervention will be >> necessary. >> >> Please let me know if you have an unusual setup like this. >> >> Warner >> > Hi Warner, > > I have what I guess is an unusual setup, not like what you describe above, > but unusual because I tripple-boot my laptop using only the UEFI boot > manager to select the OS to boot. > I have FreeBSD-current, OpenBSD-current and Windows 10 on different > partitions on one SSD. By default it boots FreeBSD. > > This was accomplished with bcdedit.exe in Windows, but now I realize this > could be done with the new efibootmgr. > I wanted to try it out, but it panics on my laptop. Sometimes just > 'kldload efirt' just panics, sometimes it loads but panics as soon as I run > efibootmgr or efivar. > How can I help debugging this? > > Jakob > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Mon Dec 18 20:29:45 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 7AC24E84DFB for ; Mon, 18 Dec 2017 20:29:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 3DD646E564 for ; Mon, 18 Dec 2017 20:29:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id m11so6318484iti.1 for ; Mon, 18 Dec 2017 12:29:45 -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=yaEHgrXy3iLJNWmwfrx9yxkNuU7xhiEfqo38GZyV5tM=; b=nplYDOtTojXKCt+r3EvoiPV00yZDRSAyX05hgfdy3HzuHX6M6KxsyPiPQioMIPDzPT xDLHnUSqk5Luw54XgWyLZDMP4OMmhy0z1nLZ+71VrF3KLi2dUP+IKcr5yHDghtLlz33D Flgw8KuAm2JUWfraXBqR0qKo7PWVRETqYBB5c6g7R4yHp/WqR8rTcrymGduWHrmHep7x 3kIkshnAxNg0EJGyrkZwXhks3M+wZVuz+oDsBfrJqC/iluQ86TDghJj93gJYq6kywldP HzLO0qwdtNDTIGwQtDV19s7CzgiBYbVj6Wuv3Ocl7ZnOmeH244JRvl8ZR/sPLrcV0RQ1 iHMQ== 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=yaEHgrXy3iLJNWmwfrx9yxkNuU7xhiEfqo38GZyV5tM=; b=VvBnS+bfIRBiAuKlT3TYDr2j02V5/pUqT0U5V4I343598cARg9B5uaydGduFJxwxC/ 3DvObSdWn53EhN3S3a1jD/h8bdziB0gx0PXJecxDwhAosmNBqdJaxVjBxv4bXi91KKwU ehfCnuUUdAfwi8CWahy6LZb02/bcTzJjQ8TVWcMpEJ1/KcAGjAxD4fb2TLcKkXEfIkmZ +l/JWZqTojInLDVaUuqB8fSMiwq7qcNwUy9de7xNex7jK9uQhHsJpTK4xZBHj0rjjlv2 DNxAA18/mhy2MWr0w8wE/bDOZFr2Sb5JOxqglGY6RH0HdE4EnO1UhOwmePaQxgfHOn+M AIpQ== X-Gm-Message-State: AKGB3mKMGMmpKhSPo5aQ/sSGGTSZluoxlL4/ReTVE8U8yLBS5wP++14r KqLe6sr0eKXqGpC4X+mpfpuqEnThsTuMhNcJytwJ4A== X-Google-Smtp-Source: ACJfBouMtdDhSuLhqvS+hs+xyYMDPmBeL14Sjwzo0X8cPWN6hGwkUCQVm1W+eOxlnqLg33jgmtNYTb92i8DfeKA+/dk= X-Received: by 10.36.164.13 with SMTP id z13mr427537ite.115.1513628984263; Mon, 18 Dec 2017 12:29:44 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 18 Dec 2017 12:29:43 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Mon, 18 Dec 2017 13:29:43 -0700 X-Google-Sender-Auth: vCVP4JSnrJNJ6z634rM_ixc5hmE Message-ID: Subject: Re: UEFI booting survey To: Maxim Sobolev Cc: Jakob Alvermark , 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: Mon, 18 Dec 2017 20:29:45 -0000 On Mon, Dec 18, 2017 at 1:21 PM, Maxim Sobolev wrote: > Not really specific to UEFI, but when ZFS is in use the /boot might be > partially or fully located on the drive that does not correspond to your > boot drive. We've bumped into this issue on AWS recently when our kernel > ended up on second drive after upgrade in a pool that were spanning two EBS > volumes. Now, it does not work with AWS (as boot code only has access to > the boot EBS volume apparently), but according to Alan such scenario is > totally supported on a physical hardware. So I am worried that by not > allowing loader to scan all drives in the system you'd make this scenario > fundamentally impossible. > Let's get one thing clear: nothing in what I've said would make this impossible. The first thing we do is to boot off something specific, no matter what that specific thing might be. If you want to boot a kernel off a floppy after loading /boot/loader.efi from cdrom, I don't care and won't prevent that since you can easily specify that with UEFI paths. For UFS the above scenario wouldn't automatically work, but could easily be made to work. ZFS is a bit special, since it spans multiple drives. I'm not touching the code that hunts for the zpools at all. If we can find them, and they have the right info, we'll still boot. I'm surprised the upgrade didn't work, especially with the code that's gone in to hunt for disks to present as devices in the loader itself. The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on a device other than the one the loader.efi came from. No other boot loader we have does that. No other loader outside of the tree does that to my knowledge. boot1.efi is the only one that did, and it was a bad call to do so. Warner > On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark > wrote: > >> On 12/17/17 20:52, Warner Losh wrote: >> >>> Greetings >>> >>> If you are booting off UEFI and have a bit of an unusual setup, I'd like >>> you to drop me a line. >>> >>> The setup that I'm looking for is any case where you load boot1.efi off >>> one >>> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that >>> drive, but on a different drive on the system. >>> >>> An example of this may be loading boot1.efi off what FreeBSD would call >>> /dev/ada0p1, but having root come from /dev/ada1p1. >>> >>> It's my belief that due to the fragility of this setup, few, if any, >>> people >>> have this setup. If you do, please take a minute to reply to this >>> message. >>> In the coming months, we're looking at dropping boot1.efi and instead >>> installing /boot/loader.efi onto the ESP (most likely as >>> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI >>> Boot Manager, we're dropping the 'search every device in the system' part >>> of the current boot1 algorithm. It will be possible to configure the >>> system >>> to continue booting (either via the new efibootmgr which will allow any >>> imaginable combination, or possibly via a fallback mechanism needed for >>> the >>> embedded EFIs that have poor UEFI Variable support at the moment), but as >>> part of an upgrade to a future FreeBSD 12, some intervention will be >>> necessary. >>> >>> Please let me know if you have an unusual setup like this. >>> >>> Warner >>> >> Hi Warner, >> >> I have what I guess is an unusual setup, not like what you describe >> above, but unusual because I tripple-boot my laptop using only the UEFI >> boot manager to select the OS to boot. >> I have FreeBSD-current, OpenBSD-current and Windows 10 on different >> partitions on one SSD. By default it boots FreeBSD. >> >> This was accomplished with bcdedit.exe in Windows, but now I realize this >> could be done with the new efibootmgr. >> I wanted to try it out, but it panics on my laptop. Sometimes just >> 'kldload efirt' just panics, sometimes it loads but panics as soon as I run >> efibootmgr or efivar. >> How can I help debugging this? >> >> Jakob >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> >> > From owner-freebsd-current@freebsd.org Mon Dec 18 22:37:32 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 890E5E8E7AE for ; Mon, 18 Dec 2017 22:37:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 4B4DA745D2 for ; Mon, 18 Dec 2017 22:37:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id d137so569339itc.2 for ; Mon, 18 Dec 2017 14:37:32 -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=uP1u1gDOrjSX3jxJ/RDz9llKk3b7flkosKGtSyMAH34=; b=h0msapDHhKfWO8XkPBebW6DGrp0UUIHQXvqGAWyUQvzks9up/3G1kmGajHmZenOU+h p2Xozzugk56fh10dBF2ErgsRlvHpnSEFDILrxwk4/rCgqWjyqk/9COiVsWnhZRgEfKpj zDwONHK229xPhckUzaLiGaigUd+ZEDzyeDlg3m8KHZsAnl2zic6zAME4kdEj3Qsz5QF4 uba+QUywfJrugA/Bm3GBsoqsi7Cg7kZJQqBPWs7QKSpa1DfHFRttpXHLqMRSdWvLRuaM wx/SDtJeeFaZkW49WMkYn7dDBSlmL9JYaeDqUHSir1qS7xNgO/WU6oKxaEJRXuYUuZFw cPQg== 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=uP1u1gDOrjSX3jxJ/RDz9llKk3b7flkosKGtSyMAH34=; b=CD/fsGh+w/ckHyVCjK8WD1siIVb3ppHRdA+PYIMuezL5xZBEpgEd/I9sftPKPV0IM3 Kr9ub68sWAE7jvQrMcwudOLrs1DLHKDpRNxcRZZ7UF8pY2Lsld+AKCUK/F4QP8mU8RtH rdC916bL9s0oDMtf0LB3PcuKSkaNZCEhAV33E5l5eHLJ/TxDD42kP65qKmdFLliugx5A mho5+bnKwCDQXjvcTIaCxj1950GPOyJP/pSVH0uy+KQ2sjhPGmj//EW7PF0QrcMDwXRA UtoYTpLxzMClmVQ5gbwarMqDXrUdor+qXgLZ/CsoUbk7Lh5fTThXDe39zFxWNMVskjhI WpJQ== X-Gm-Message-State: AKGB3mLkWlbFvB7e4l8dolFIFtAr+bYIiiafRjSC5foCY07EetOiFyr5 migfpHyfU1iPvm0hJ/5A/kcFmRtYKn9SnKUb7zLbdA== X-Google-Smtp-Source: ACJfBouI6wQwQWz4lUVzPhFrjDjbZv2TXeou/sYWDEeYLCysY9194S//K9mCahWu/ZyjKwtrsiGHRz592SfGLPoRy5g= X-Received: by 10.36.131.200 with SMTP id d191mr814627ite.97.1513636651327; Mon, 18 Dec 2017 14:37:31 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 18 Dec 2017 14:37:30 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> From: Warner Losh Date: Mon, 18 Dec 2017 15:37:30 -0700 X-Google-Sender-Auth: i0Y_PtSPVdXvAnonJ-K99RpD8xQ 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: Mon, 18 Dec 2017 22:37:32 -0000 On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard wrote: > Warner Losh imp at bsdimp.com wrote on > Mon Dec 18 20:29:45 UTC 2017 : > > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root on a > device > > other than the one the loader.efi came from. > > Warner Losh imp at bsdimp.com wrote on > Sun Dec 17 19:52:07 UTC 2017 : > > > In the coming months, we're looking at dropping boot1.efi and instead > > installing /boot/loader.efi onto the ESP (most likely as > > \efi\freebsd\loader.efi). > > > Combining the two statements would appear to have consequences > not obvious from the separate statements in isolation. Rewording > the first to substitute where loader.efi comes from based on > the second (if I interpret right): > > MISQUOTE > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root > on other than the device for the ESP used (which will hold > loader.efi). > END MISQUOTE > The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on other than the device for the ESP used (which will hold now loader.efi as boot1.efi will shortly be eliminated). 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 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. Warner From owner-freebsd-current@freebsd.org Mon Dec 18 23:59:09 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 4E1C7E93B5E for ; Mon, 18 Dec 2017 23:59:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (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 D93E577BEB for ; Mon, 18 Dec 2017 23:59:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6733 invoked from network); 18 Dec 2017 22:12:21 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 18 Dec 2017 22:12:21 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 18 Dec 2017 17:12:21 -0500 (EST) Received: (qmail 17942 invoked from network); 18 Dec 2017 22:12:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Dec 2017 22:12:21 -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 ADFAFEC9529; Mon, 18 Dec 2017 14:12:20 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: UEFI booting survey Message-Id: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> Date: Mon, 18 Dec 2017 14:12:19 -0800 To: Warner Losh , FreeBSD Current 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: Mon, 18 Dec 2017 23:59:09 -0000 Warner Losh imp at bsdimp.com wrote on Mon Dec 18 20:29:45 UTC 2017 : > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root on a device > other than the one the loader.efi came from. Warner Losh imp at bsdimp.com wrote on Sun Dec 17 19:52:07 UTC 2017 : > In the coming months, we're looking at dropping boot1.efi and instead > installing /boot/loader.efi onto the ESP (most likely as > \efi\freebsd\loader.efi). Combining the two statements would appear to have consequences not obvious from the separate statements in isolation. Rewording the first to substitute where loader.efi comes from based on the second (if I interpret right): MISQUOTE The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on other than the device for the ESP used (which will hold loader.efi). END MISQUOTE === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Dec 19 01:06:28 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 5CFCAE984C8 for ; Tue, 19 Dec 2017 01:06:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 478547A56E for ; Tue, 19 Dec 2017 01:06:27 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBJ16LW2018836; Mon, 18 Dec 2017 17:06:21 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBJ16LpE018835; Mon, 18 Dec 2017 17:06:21 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712190106.vBJ16LpE018835@pdx.rh.CN85.dnsmgr.net> Subject: Re: UEFI booting survey In-Reply-To: To: Warner Losh Date: Mon, 18 Dec 2017 17:06:21 -0800 (PST) CC: Mark Millard , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 19 Dec 2017 01:25:54 +0000 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 01:06:28 -0000 > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard wrote: > > > Warner Losh imp at bsdimp.com wrote on > > Mon Dec 18 20:29:45 UTC 2017 : > > > > > The specific thing we will stop doing is that in the absence of > > > instructions to the contrary, we will no longer search for root on a > > device > > > other than the one the loader.efi came from. > > > > Warner Losh imp at bsdimp.com wrote on > > Sun Dec 17 19:52:07 UTC 2017 : > > > > > In the coming months, we're looking at dropping boot1.efi and instead > > > installing /boot/loader.efi onto the ESP (most likely as > > > \efi\freebsd\loader.efi). > > > > > > Combining the two statements would appear to have consequences > > not obvious from the separate statements in isolation. Rewording > > the first to substitute where loader.efi comes from based on > > the second (if I interpret right): > > > > MISQUOTE > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root > > on other than the device for the ESP used (which will hold > > loader.efi). > > END MISQUOTE > > > > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root on other > than the device for the ESP used (which will hold now loader.efi as > boot1.efi will shortly be eliminated). Yes please, that is the correct behavior, our searching can lead to problems, and as you have pointed out, often more problems than it ever really fixed. > > 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. use the ACTIVE ufs partition, not the first, I can have more than 1 slice, only 1 of them can be set active. Do not use any ufs partitions if they are not in active slices, it is possible to have 0 partitions set active. > > A partition is usable if /boot/loader.rc exists on that path. A partition is usable if it is in an active slice, and ^above Is there any fallback to skip loader and go direct to /boot/kernel/kernel, back to /kernel any more? > 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. > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Dec 19 02:56:19 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 2D3BEEA3BFA for ; Tue, 19 Dec 2017 02:56:19 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A73C47FDF9 for ; Tue, 19 Dec 2017 02:56:18 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [202.216.24.27]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id vBJ2uFaj053413 for ; Tue, 19 Dec 2017 11:56:15 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201712190256.vBJ2uFaj053413@kx.openedu.org> Date: Tue, 19 Dec 2017 11:56:15 +0900 From: KIRIYAMA Kazuhiko To: freebsd-current@FreeBSD.org Subject: r326622 and r326820 broken? User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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 02:56:19 -0000 Hi, I've fetched [1] and [2] and burned to USB and then boot by the USB, but both does not boot and stop at boot loader at the beginning: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboad Basically,does r326622 and r326820 broken ? [1] FreeBSD-12.0-CURRENT-amd64-20171206-r326622-memstick.img [2] FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Tue Dec 19 10:02:03 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 6B012E9C0FB for ; Tue, 19 Dec 2017 10:02:03 +0000 (UTC) (envelope-from 010001606e350447-ea112c5b-2179-4828-9899-f33e704aa131-000000@amazonses.com) Received: from a8-13.smtp-out.amazonses.com (a8-13.smtp-out.amazonses.com [54.240.8.13]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FD5570F4D for ; Tue, 19 Dec 2017 10:02:02 +0000 (UTC) (envelope-from 010001606e350447-ea112c5b-2179-4828-9899-f33e704aa131-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1513677456; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=sbi2dnClvEChZUK0VBs88LfsjSmWXEeCAklqMLbtHAQ=; b=rV5MP00JCvlJuAZrW4ZVNG0D02eXwFLISwpdVHcKmOc/7FhZcKqnxc0OdbVosqwg z0LrYbhypVb/nEIPUPD8nLbPUJvBbbGSSPDQLSSS7VygJqmCJHQc/aqH2VbWtvRoenh rK3pik8qHXoZ1KY6s/ioL6hdfh764AoElKM+krJM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1513677456; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=sbi2dnClvEChZUK0VBs88LfsjSmWXEeCAklqMLbtHAQ=; b=aQNwly1Cqdz8gd7S3iDPGYxNWEqJPol3zD22r18nZSOkgVLslOW8WZhFHCKUMYo0 moXon0xwvadWWj7eCyYKFtDmBWJS5tK5eKP+/LFHo9ILBNq8qkf1Kec1uIYR4DiCuis 5QBUsb6+x8V50hPUS8Z1mXcXUoP+kvkcLDmOsb40= Subject: Re: RFC: Removing hpt* drivers from GENERIC To: "O'Connor, Daniel" References: <0100015f557d9cd2-098d2e99-d4c4-45ce-90bf-47b76455a6de-000000@email.amazonses.com> Cc: "freebsd-current@freebsd.org" , Andrew Turner , Baptiste Daroussin From: Colin Percival Message-ID: <010001606e350447-ea112c5b-2179-4828-9899-f33e704aa131-000000@email.amazonses.com> Date: Tue, 19 Dec 2017 09:57:36 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.12.19-54.240.8.13 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-Mailman-Approved-At: Tue, 19 Dec 2017 12:09:15 +0000 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 10:02:03 -0000 On 10/25/17 15:56, O'Connor, Daniel wrote: >> On 26 Oct 2017, at 08:13, Colin Percival wrote: >> [Proposal for removing hpt* drivers since hpt27xx and hptnr take a long >> time to in DEVICE_PROBE.] > > Seems sensible to me, but also worth contacting the blob authors if > possible and asking them what gives (and if they can fix it). Turns out that they were indeed able to fix it, with startling rapidity. delphij@ committed r325683 (MFCed as r32600[56]) which reduces the time spent in these DEVICE_PROBE routines from ~150 ms down to ~37 *us* on my laptop. So my immediate desire for faster booting has been satisfied with regard to these drivers. I know some people (CCed) were enthusiastic about removing these from GENERIC on the basis that we shouldn't have binary blobs in GENERIC; while I'm certainly sympathetic to this, I'd suggest that it should be done by someone who has time to look at the other binary blobs in the tree and formulate a general policy rather than just picking on the hpt* drivers. Unfortunately, that person is not me; I have 12 days left to submit a talk to AsiaBSDCon about my work on profiling the kernel boot (which is how I noticed the slow probing originally) and then a long list of other places to speed up the boot performance. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@freebsd.org Tue Dec 19 17:58:14 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 1CEACE94052 for ; Tue, 19 Dec 2017 17:58:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-95.reflexion.net [208.70.210.95]) (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 C05BE2FAD for ; Tue, 19 Dec 2017 17:58:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24447 invoked from network); 19 Dec 2017 17:58:06 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Dec 2017 17:58:06 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 19 Dec 2017 12:58:06 -0500 (EST) Received: (qmail 8626 invoked from network); 19 Dec 2017 17:58:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Dec 2017 17:58:05 -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 393F7EC943C; Tue, 19 Dec 2017 09:58:05 -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 09:58:04 -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 17:58:14 -0000 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 >=20 > 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. >=20 > 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? (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. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Dec 19 19:26:33 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 F0B1AE9A11A for ; Tue, 19 Dec 2017 19:26:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-99.reflexion.net [208.70.210.99]) (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 9C55667468 for ; Tue, 19 Dec 2017 19:26:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29672 invoked from network); 19 Dec 2017 19:26:26 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Dec 2017 19:26:26 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 19 Dec 2017 14:26:26 -0500 (EST) Received: (qmail 20200 invoked from network); 19 Dec 2017 19:26:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Dec 2017 19:26:26 -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 8B6ECEC9378; Tue, 19 Dec 2017 11:26:25 -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 11:26:25 -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 19:26:34 -0000 [I forgot to list the .dtb file with the kernel and world.] On 2017-Dec-19, at 9:58 AM, Mark Millard wrote: > On 2017-Dec-18, at 2:37 PM, Warner Losh wrote: >=20 >> . . . >>=20 >> Or the following pseudo-code with all the weird special cases removed = for clarity >>=20 >> 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. >>=20 >> 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? Typo: should be "establishing where". > (For my particular interest the context uses UFS, not > ZFS.) I forgot to list: What will be the role of /etc/fstab in establishing where the .dtb file will be found (when such is involved)? >> 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. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Dec 19 21:42:46 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 74581EA25C2 for ; Tue, 19 Dec 2017 21:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 35E7F6CD21 for ; Tue, 19 Dec 2017 21:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id o130so9559337itg.0 for ; Tue, 19 Dec 2017 13:42:46 -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=e8j/Elf3y0IuVfmESy4rE9O1NYngbCMS2J/ocW5xRoM=; b=Y4RzcCfOn+PfSHIJbeT9KLLimwPslyS3f5mAKNKSL54A846x4l4aVSZVNFO515/Okm HgeI3RxI/M+OHCeTmdhknc7oi2ZnaMc43h2fkyn/5o0FS/aPUjpr0S5BFou2ZJvGZTyG VAv6qmH31b2m4ABFpEzrTJTEydxrM8YqxG8Yj06c7NqUvtSFBJRgeLrnwteq3gyeym+C ZhnHV+CN5PIRPY0I4Rz+//ZT4pEMIilCo+G66uvr5XPWIjGEi70jhM6HD0DYaOr52WRn /aXccKlA8oapQIix5Y0YOg62x9Lkq59KTBodiVVGwn94gZT8qwAbQND+yltKOV7IUKJO wJQA== 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=e8j/Elf3y0IuVfmESy4rE9O1NYngbCMS2J/ocW5xRoM=; b=ITGuN8tliyIFxUuQF0xdwQt02ZLM70YJRSuQhkBVQlK8KCF+hRkwXCdy+D++l7Jq1C bd0xiuFKoEOnenSYxN4UnL9SvOVcns/a34dLqlLNoZW+n7aRfktAn8Gttl4PlPUOxF24 NXT8A/9lmbn23e3JK9fYxFwbIW05jxGAiIG0cy1S0Y8YJnP5lDRmbwzJx1rc5KqFJGXU AT18iUCbKojdexOhD4pG17TwKM2UGdZ74ozw+tf22aIy6jc/Ui6thUV1GtJJfzF94CGR 7sx+ck8myY2Y1K+Enxgai7VCGt5IRSzcQy4/b2RZtZL9ojIRWMdDKQSdcrFob5m5tuKR 7FKQ== X-Gm-Message-State: AKGB3mLI5kR/vJM2qVi70EUu2+YDESlje78qbSHeBiBnUzAYIjB7nq9u X2AiAh1X2vqw0kLWFeK8Z9A6JH243JC/brGV0UppIA== X-Google-Smtp-Source: ACJfBotzIq7s0IEV4RrwGKVmatSyVj8MUE1qnSs2IqMmqM0zRTWpAWgzXXm16D4acxcWVNWqk9pVuGYbXOsInJcYY6w= X-Received: by 10.36.77.143 with SMTP id l137mr5138703itb.50.1513719765089; Tue, 19 Dec 2017 13:42:45 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:42:44 -0800 (PST) X-Originating-IP: [2607:fb90:6f6a:13fc:4073:f971:9d8e:a305] Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:42:44 -0800 (PST) In-Reply-To: <201712190106.vBJ16LpE018835@pdx.rh.CN85.dnsmgr.net> References: <201712190106.vBJ16LpE018835@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 19 Dec 2017 14:42:44 -0700 X-Google-Sender-Auth: HJUHgxLs_2dT8h4GeHRilRe_-xg Message-ID: Subject: Re: UEFI booting survey To: "Rodney W. Grimes" Cc: Mark Millard , 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: Tue, 19 Dec 2017 21:42:46 -0000 On Dec 18, 2017 6:06 PM, "Rodney W. Grimes" < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard wrote: > > > Warner Losh imp at bsdimp.com wrote on > > Mon Dec 18 20:29:45 UTC 2017 : > > > > > The specific thing we will stop doing is that in the absence of > > > instructions to the contrary, we will no longer search for root on a > > device > > > other than the one the loader.efi came from. > > > > Warner Losh imp at bsdimp.com wrote on > > Sun Dec 17 19:52:07 UTC 2017 : > > > > > In the coming months, we're looking at dropping boot1.efi and instead > > > installing /boot/loader.efi onto the ESP (most likely as > > > \efi\freebsd\loader.efi). > > > > > > Combining the two statements would appear to have consequences > > not obvious from the separate statements in isolation. Rewording > > the first to substitute where loader.efi comes from based on > > the second (if I interpret right): > > > > MISQUOTE > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root > > on other than the device for the ESP used (which will hold > > loader.efi). > > END MISQUOTE > > > > The specific thing we will stop doing is that in the absence of > instructions to the contrary, we will no longer search for root on other > than the device for the ESP used (which will hold now loader.efi as > boot1.efi will shortly be eliminated). Yes please, that is the correct behavior, our searching can lead to problems, and as you have pointed out, often more problems than it ever really fixed. > > 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. use the ACTIVE ufs partition, not the first, I can have more than 1 slice, only 1 of them can be set active. Do not use any ufs partitions if they are not in active slices, it is possible to have 0 partitions set active. Active is not a GPT concept. UEFI makes it hard to implement since there is no good API to get and set the flags FreeBSD's gptboot uses to hack this concept in. Active is done via BootOrder UEFI variable. Loader.efi and boot.efi completely ignore this today. I have no plans on changing that. > > A partition is usable if /boot/loader.rc exists on that path. A partition is usable if it is in an active slice, and ^above Active isn't a got thong. So no. Is there any fallback to skip loader and go direct to /boot/kernel/kernel, back to /kernel any more? You are thinking about this wrong. We are loader.efi, not boot2. This is one of the big advantages of loading directly. We don't have the space limitations that forced that design, so we should simplify. Warner > 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. > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Dec 19 21:50:01 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 3CADDEA2C8E for ; Tue, 19 Dec 2017 21:50:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 F39516D0DB for ; Tue, 19 Dec 2017 21:50:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id f18so10086578ioh.1 for ; Tue, 19 Dec 2017 13:50:00 -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=FbY1eZLelyVJSC05ZntVJvfPX/r0qCMOHBdSreBg3oM=; b=IL9oRIGsvbnHNE56EslldDbKNSQzbMbrOEzgR9U43GxbqVWU+szl6iy2nZzaYE9whG POv7q5SmF898jPHz63xSjrbiGO5+RHuHMn399hmMlbMI103CKBFTVDwuOgkQX7SOYB/6 8bRxRLO8SQoVK1TnPD3SGMK1qvrIdpFFhECf0T+naqOdjE9U6dXnS500sBfqnel4gj46 HtXE1+tno1iSKJzG/qOxuSL/OQuyhxF2DIC8dxBx58pwmnM5IciCZD6glTeu8vr48RhG eQLwynTagRvpfqqLcJY28Sf/jkOTPfRPeDLNdD098xKwQrFb7kdXvF8vdgF/gFEpu5GB n3cg== 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=FbY1eZLelyVJSC05ZntVJvfPX/r0qCMOHBdSreBg3oM=; b=foBlT7n+ztzxCJxLjgMBAf8p55gzYJWjAd+GrCuwfrAIcaVNZ2HvMHTw7r9e7jDQZO tkK0dRtOqQIWHlPvZM/ao4oWF7ny2t9O+VrpQOdM7lcQmmrPPPefgCpT9d2kQs2udvsO 0mIjCh/1fveV0euXqS7uGCu16wi1LEebqH20xrOS289MSR4D8C0HkqAYurMl8hRbHdJI 7XeNoAPJMxh2dzqiDzsam8k4dODSHt7kKKp2igr31KVw6LOJu+pytvw6eyXX/9T33nJ6 /Q7GU4K2SnwVa7iikk/5ncqxaWXeY05eDqvIg+HCvLlJtT5ZWgd55i592AZz76D65bGO HqGQ== X-Gm-Message-State: AKGB3mIO58AWOKNXaQS1EBYa2pdDS5Pbia5FvnZ9CZ0PLkfPBF6dyo2H 0FZFhQTvp9XzFcSY6p/CrF5QLZXYT5yr2uQTFYUiIw== X-Google-Smtp-Source: ACJfBotbKBCOYviImxfc6UcT/f2V+xyNdss8rb9YusXKdCKHuqGJkpKWuDqj53e8VUK8LaqySxyyBTSRxpfKk9cSVRU= X-Received: by 10.107.83.8 with SMTP id h8mr5502229iob.63.1513720200169; Tue, 19 Dec 2017 13:50:00 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:49:59 -0800 (PST) X-Originating-IP: [2607:fb90:6f6a:13fc:4073:f971:9d8e:a305] Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:49:59 -0800 (PST) In-Reply-To: References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> From: Warner Losh Date: Tue, 19 Dec 2017 14:49:59 -0700 X-Google-Sender-Auth: vkWnR5Qy8jGJliD0hYrLbVHFkT8 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: Tue, 19 Dec 2017 21:50:01 -0000 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 (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 From owner-freebsd-current@freebsd.org Tue Dec 19 21:51:26 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 C7D13EA2E63 for ; Tue, 19 Dec 2017 21:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 88E806D2FB for ; Tue, 19 Dec 2017 21:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id t196so15150736iof.0 for ; Tue, 19 Dec 2017 13:51:26 -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=tDfOIn8ZBWPYEL5OIa3So0GErUrme1azoB9O0r5fonI=; b=wFCArLgnxdbpwdrTKKxOr7LrGjl2WwGdXDBHMXjZT1xEnp0vwmjNPcSWOmwlUjAru8 tMrZja1Ob6aAC3spx8CRUEnrO7DobFUpjDswVYuhccTBzsvqNmGb6Xfv0KwBQVI3N5Ms z8k88TYRD+dewr3zLJ04Zlh5bjIyAaQw5VD/70a8qBteH1/DN8f3iuKaurIsIgXpMJkZ Ed+cPLBXjHT4jeCPqeWsaz0mCKyZU1bc3Vcjo0jS6opAzGR/Rf72qQLF4e06tO16DTxZ TNEe2cseIVh4o4lDMkrTbr4y4qcjSHSt/FuPugoTPRFOZ7WTqp0Lt5BNJsYmiRNVPj2z S8ZQ== 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=tDfOIn8ZBWPYEL5OIa3So0GErUrme1azoB9O0r5fonI=; b=QGW937chQFcaoT8+EBflCcPASMmQAkxPYKg0/iwkkLO02NTKBKtIGob4996c9OGet5 6L3IaPBokauKqZ1lSlT+HPr60jBZ2JDSxzPNsfaOkbyOuuubrWpt4GjorJpWRye2iegK 3NASUdl9nP4Wmt+OKa9PBSt7tZjGHmSCxNyRTB3qceTE9aUaW33LcTTVIxOYxAgj/txS K2NQwm6J4GuE/HS+wg00FTpOJezGaTJh9XBSWAFsQwfgqFWPMYmRpLLb82uHVxa/blVJ mQf75IccmDhTKqZm5xNEbmUgoxqWGca2d03RZW92YHEt98+/c1I1FB3gYae+QnQZ1IHH S+SA== X-Gm-Message-State: AKGB3mIjukUU4g0R0TxNKqPKQ1j3aEQduGE//5GzvcEy0VtX8dMnDhYU T3ytX/JRypw56RJc0tDHcvrnzrlHjxEpVA9WmqYxDQ== X-Google-Smtp-Source: ACJfBotarUhbpXaFfI3pVBr561qzVP7bG9ITq6aIkXpaC0kpH0ZjaNDh3qh2cUKpKu8amv8DWQggMvPd+2tmh8wk4kE= X-Received: by 10.107.18.35 with SMTP id a35mr1549251ioj.291.1513720285823; Tue, 19 Dec 2017 13:51:25 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:51:24 -0800 (PST) X-Originating-IP: [2607:fb90:6f6a:13fc:4073:f971:9d8e:a305] Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:51:24 -0800 (PST) In-Reply-To: References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> From: Warner Losh Date: Tue, 19 Dec 2017 14:51:24 -0700 X-Google-Sender-Auth: Xjd7NcNEmEdRipYEkPv7V-nR9yM 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: Tue, 19 Dec 2017 21:51:26 -0000 On Dec 19, 2017 12:26 PM, "Mark Millard" wrote: [I forgot to list the .dtb file with the kernel and world.] On 2017-Dec-19, at 9: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? Typo: should be "establishing where". > (For my particular interest the context uses UFS, not > ZFS.) I forgot to list: What will be the role of /etc/fstab in establishing where the .dtb file will be found (when such is involved)? None. See my prior message for why. Warner >> 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 From owner-freebsd-current@freebsd.org Tue Dec 19 22:39:00 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 4152DEA556C for ; Tue, 19 Dec 2017 22:39:00 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 C934C6F05D for ; Tue, 19 Dec 2017 22:38:59 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wm0-x232.google.com with SMTP id g130so13334437wme.0 for ; Tue, 19 Dec 2017 14:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M1g8yLrGdXVMA+z5pCK8ee9RrPmbbVK2GS8+Rq8M13E=; b=DjykNrfAsx4RhAs1dRXEQVte//ZhOgnqggu5SX/aur46OVapdEj++AmiuPn+J+fm7d KOaXGWiBL3YGn8GxkOVOYxt0BuALRmza/rOi0eBLJi4ZlgGPc94g4+GGVqe9JSaDhY3A CAm9vIIskvph+KHWaW9gl9Ok82G8aHE0tIaLS1S6F6reeh0sY23z6UW4j019SLkMN1IL rq9+HMQl484NMZtNKubqPnAZBkcaBYWtkVeZqCaFFLQ4BJhhTOkB5JcmQn2wB63YTc6q UMSWgDTrTfSN1QgUhgqwQfyZGXSuT0ifyqxVQIz0Y6y3kM4KIr+jHBytFYFHrz7KHYXD WPYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M1g8yLrGdXVMA+z5pCK8ee9RrPmbbVK2GS8+Rq8M13E=; b=XLXpC7WaCnWTXeESiOKoo9d8Ps/1I7HWH9kPdN+DJyJGYEmBiENz1LebjXtsrLlL4G 9VAD2HN/lXGY26qNPBlZ02gSzYl7YEYZfaD6lHQISP0hFoWlGaIS/J/N5MuUySeO/uy1 d6sGus/7nL8PIWIBcfPguQognz/7eHSPYqG1h94jUY1cnlmg+tut/rvLydXCfoz7yakb J1L5sRU/J2bVFyhbg4zDrRIie5rNu+JES39wxQ70Z9Trp0bQAOodjE/+Un4iqIj4gdIs wtERZZzOGoZJNWBxge3+MZt+Tl1mHJcpUuPP2QqmB8BELUP53vg/TgwPeB6vJ2HrBS/1 6l7w== X-Gm-Message-State: AKGB3mLjiJVqVckrvj0MRgCSCtvnsOyh+07Ycv4wsQmTU+X/8CeVq52b 1TLZ5TtFol2VxhbNF4tslU40B83atCzr9gmONV3uVA== X-Google-Smtp-Source: ACJfBotfSqKvhSSvEyBy+WSk1htO2lRe1uhHwqt2NVvbuTumP0f+mnb04INUgHAyDAJfmzqvvhu1DCEfHa0/dNrhorg= X-Received: by 10.80.181.70 with SMTP id z6mr2550426edd.201.1513723138216; Tue, 19 Dec 2017 14:38:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.149.174 with HTTP; Tue, 19 Dec 2017 14:38:57 -0800 (PST) In-Reply-To: References: <201712190106.vBJ16LpE018835@pdx.rh.CN85.dnsmgr.net> From: Oliver Pinter Date: Tue, 19 Dec 2017 23:38:57 +0100 Message-ID: Subject: Re: UEFI booting survey To: Warner Losh Cc: "Rodney W. Grimes" , Mark Millard , 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: Tue, 19 Dec 2017 22:39:00 -0000 On Tuesday, December 19, 2017, Warner Losh wrote: > On Dec 18, 2017 6:06 PM, "Rodney W. Grimes" < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard > wrote: > > > > > Warner Losh imp at bsdimp.com wrote on > > > Mon Dec 18 20:29:45 UTC 2017 : > > > > > > > The specific thing we will stop doing is that in the absence of > > > > instructions to the contrary, we will no longer search for root on a > > > device > > > > other than the one the loader.efi came from. > > > > > > Warner Losh imp at bsdimp.com wrote on > > > Sun Dec 17 19:52:07 UTC 2017 : > > > > > > > In the coming months, we're looking at dropping boot1.efi and instead > > > > installing /boot/loader.efi onto the ESP (most likely as > > > > \efi\freebsd\loader.efi). > > > > > > > > > Combining the two statements would appear to have consequences > > > not obvious from the separate statements in isolation. Rewording > > > the first to substitute where loader.efi comes from based on > > > the second (if I interpret right): > > > > > > MISQUOTE > > > The specific thing we will stop doing is that in the absence of > > > instructions to the contrary, we will no longer search for root > > > on other than the device for the ESP used (which will hold > > > loader.efi). > > > END MISQUOTE > > > > > > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root on other > > than the device for the ESP used (which will hold now loader.efi as > > boot1.efi will shortly be eliminated). > > Yes please, that is the correct behavior, our searching can lead to > problems, and as you have pointed out, often more problems than it > ever really fixed. > > > > > 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. > > use the ACTIVE ufs partition, not the first, I can have more than 1 slice, > only 1 of them can be set active. Do not use any ufs partitions if they > are not in active slices, it is possible to have 0 partitions set active. > > > Active is not a GPT concept. UEFI makes it hard to implement since there is > no good API to get and set the flags FreeBSD's gptboot uses to hack this > concept in. Active is done via BootOrder UEFI variable. Loader.efi and > boot.efi completely ignore this today. I have no plans on changing that. And what's about the bootme and bootonce flags in gpart? They are freebsdism? Or they are the equivalent of active in the UEFI standard? > > > > > A partition is usable if /boot/loader.rc exists on that path. > > A partition is usable if it is in an active slice, and ^above > > > Active isn't a got thong. So no. > > Is there any fallback to skip loader and go direct to > /boot/kernel/kernel, back to /kernel any more? > > > You are thinking about this wrong. We are loader.efi, not boot2. This is > one of the big advantages of loading directly. We don't have the space > limitations that forced that design, so we should simplify. > > Warner > > > 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. > > > > Warner > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Dec 19 23:18:03 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 7C4ACE81EEE for ; Tue, 19 Dec 2017 23:18:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E93070B07 for ; Tue, 19 Dec 2017 23:18:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from helicon.physics.ucla.edu (helicon.physics.ucla.edu [169.232.156.253]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vBJN6hBj030980 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Dec 2017 15:06:43 -0800 Subject: Re: UEFI booting survey To: freebsd-current@freebsd.org References: <201712190106.vBJ16LpE018835@pdx.rh.CN85.dnsmgr.net> From: Nathan Whitehorn Message-ID: <5dc9d252-cb0d-8d4d-979b-d9faaa3ff1b6@freebsd.org> Date: Tue, 19 Dec 2017 15:06:42 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVa21JGLqHYCbvTA9GmNhQu4EryvedlrzTdaEqoGOhw8UFyZAYmplAQbebYFekxL3wos5d89+gKwysgel52AYc1KW96V2jfUwSs= X-Sonic-ID: C;WINDRxHl5xGpbesnWtmBlw== M;tFWhRxHl5xGpbesnWtmBlw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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:18:03 -0000 On 12/19/17 14:38, Oliver Pinter wrote: > On Tuesday, December 19, 2017, Warner Losh wrote: > >> [snip] >>> 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. >> use the ACTIVE ufs partition, not the first, I can have more than 1 slice, >> only 1 of them can be set active. Do not use any ufs partitions if they >> are not in active slices, it is possible to have 0 partitions set active. >> >> >> Active is not a GPT concept. UEFI makes it hard to implement since there is >> no good API to get and set the flags FreeBSD's gptboot uses to hack this >> concept in. Active is done via BootOrder UEFI variable. Loader.efi and >> boot.efi completely ignore this today. I have no plans on changing that. > > And what's about the bootme and bootonce flags in gpart? They are > freebsdism? Or they are the equivalent of active in the UEFI standard? > They are a FreeBSD-ism. Because UEFI handles parsing the GPT tables internally, it is not even possible to read them from loader.efi. -Nathan 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 From owner-freebsd-current@freebsd.org Wed Dec 20 03:15:41 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 7D1F0E8E9F5 for ; Wed, 20 Dec 2017 03:15:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 46DC179499 for ; Wed, 20 Dec 2017 03:15:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id g70so3226506ioj.6 for ; Tue, 19 Dec 2017 19:15:41 -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=f1YNyWWqWvt53+LeCXMSIjWxH0ZPvZlVpa4QmpXHo9M=; b=Dl0yLdQxXs1obnRDGCFVdfaaxS9uC6zddbo3zKZzhH1OvNkJnScc/sMkcjZB1XiZa3 +13YAG7HhokP0y2/twRTZX0zdGh9OT+EaWaDFTYC3ADaEWTg/fsKyzpKYPEKk2HOfJuM XPnTwY7VbcuTRvIAmnKvWHyhbT4xhgip/lcKkyI8Li6BGHhxp65WjEQhsk5hVG16CkdO ZW9I0gvz6GFOvgE5CvbGqyvrdc63PGV9g/Awi+cYWCZDOs+bPKhul/SapP1REY1r6COx bXFxv3lWqzVBoaxVAMhFZDth/J/4fJITGbibkYe473XerRERRJWgOaE5ejOCqdppdV76 bFOQ== 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=f1YNyWWqWvt53+LeCXMSIjWxH0ZPvZlVpa4QmpXHo9M=; b=tg5lJBtEEOVXbaOay1mo0+gJaE6b7YZos0+U67M9oOzEZp2WfUv+K77tznz+31ktIf ZvvGVWPd70lNYztYGDJWReWD6BbWPwJhsWKLfsU5s61YpJ213IasMl1fWzfKQ61sDvKH 6eKLjgeLQg6T4sVNLpHrctAw0rhr3ibK2yS+OMCSG+c42tYtewbwIo4hvZWoHNXpvB/0 9FrclHDaGOWbhhWL+AJa/SKs9+m20jvi0NKhGVS+ho7G5x2IpN1AH305AMlNN/Y89DT4 047XANGlXrr/myHXESzLnM7/zHaEaA4IdJHrLqx/IvSoSmb488B9eA/nNQE3vM/r/Nz6 fQZw== X-Gm-Message-State: AKGB3mKz/9fvPz0ZP9MJTGi7CyN95U7ClkrTbBDxQZvn8mYB1BCi/Bnb yk3zFue9MmJqYHvKUhhFFnRXWhgyKJRmB0Mg3eS98w== X-Google-Smtp-Source: ACJfBou4lL9CLFnu1xWqCTgo+W5d7RhsLZjYeUP6TOSOZJkiEUZBgA43dQaXWeKGtFUuFS0jU0UjxryvL05ssYh7nEU= X-Received: by 10.107.18.35 with SMTP id a35mr2581188ioj.291.1513739740096; Tue, 19 Dec 2017 19:15:40 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 19:15:39 -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:15:39 -0800 (PST) In-Reply-To: References: <201712190106.vBJ16LpE018835@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 19 Dec 2017 20:15:39 -0700 X-Google-Sender-Auth: t29Om3lysU5yr_vCT5QVaTDVG5U Message-ID: Subject: Re: UEFI booting survey To: Oliver Pinter Cc: "Rodney W. Grimes" , Mark Millard , 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:15:41 -0000 On Dec 19, 2017 3:38 PM, "Oliver Pinter" wrote: On Tuesday, December 19, 2017, Warner Losh wrote: > On Dec 18, 2017 6:06 PM, "Rodney W. Grimes" < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard > wrote: > > > > > Warner Losh imp at bsdimp.com wrote on > > > Mon Dec 18 20:29:45 UTC 2017 : > > > > > > > The specific thing we will stop doing is that in the absence of > > > > instructions to the contrary, we will no longer search for root on a > > > device > > > > other than the one the loader.efi came from. > > > > > > Warner Losh imp at bsdimp.com wrote on > > > Sun Dec 17 19:52:07 UTC 2017 : > > > > > > > In the coming months, we're looking at dropping boot1.efi and instead > > > > installing /boot/loader.efi onto the ESP (most likely as > > > > \efi\freebsd\loader.efi). > > > > > > > > > Combining the two statements would appear to have consequences > > > not obvious from the separate statements in isolation. Rewording > > > the first to substitute where loader.efi comes from based on > > > the second (if I interpret right): > > > > > > MISQUOTE > > > The specific thing we will stop doing is that in the absence of > > > instructions to the contrary, we will no longer search for root > > > on other than the device for the ESP used (which will hold > > > loader.efi). > > > END MISQUOTE > > > > > > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root on other > > than the device for the ESP used (which will hold now loader.efi as > > boot1.efi will shortly be eliminated). > > Yes please, that is the correct behavior, our searching can lead to > problems, and as you have pointed out, often more problems than it > ever really fixed. > > > > > 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. > > use the ACTIVE ufs partition, not the first, I can have more than 1 slice, > only 1 of them can be set active. Do not use any ufs partitions if they > are not in active slices, it is possible to have 0 partitions set active. > > > Active is not a GPT concept. UEFI makes it hard to implement since there is > no good API to get and set the flags FreeBSD's gptboot uses to hack this > concept in. Active is done via BootOrder UEFI variable. Loader.efi and > boot.efi completely ignore this today. I have no plans on changing that. And what's about the bootme and bootonce flags in gpart? They are freebsdism? Or they are the equivalent of active in the UEFI standard? They are a FreeBSD hack. Not part of the standard. All the bootnext / bootme stuff lives in UEFI variables as documented in the standard for UEFI boot manager, not in the partitions. FreeBSD on UEFI has never honored them. Warner > > > > A partition is usable if /boot/loader.rc exists on that path. > > A partition is usable if it is in an active slice, and ^above > > > Active isn't a got thong. So no. > > Is there any fallback to skip loader and go direct to > /boot/kernel/kernel, back to /kernel any more? > > > You are thinking about this wrong. We are loader.efi, not boot2. This is > one of the big advantages of loading directly. We don't have the space > limitations that forced that design, so we should simplify. > > Warner > > > 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. > > > > Warner > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > 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 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 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 > > > > From owner-freebsd-current@freebsd.org Wed Dec 20 10:48:05 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 69617EA5E55 for ; Wed, 20 Dec 2017 10:48:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-136.reflexion.net [208.70.210.136]) (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 2863667389 for ; Wed, 20 Dec 2017 10:48:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17767 invoked from network); 20 Dec 2017 10:47:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Dec 2017 10:47:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 20 Dec 2017 05:47:57 -0500 (EST) Received: (qmail 1587 invoked from network); 20 Dec 2017 10:47:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Dec 2017 10:47:57 -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 CA922EC9186; Wed, 20 Dec 2017 02:47:56 -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: Wed, 20 Dec 2017 02:47:56 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6EFC9D27-02B8-4441-9B9B-E380EFECED78@dsl-only.net> References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> <2822699E-DDD5-4604-8567-974AE30659A3@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 10:48:05 -0000 On 2017-Dec-19, at 9:10 PM, Warner Losh wrote: > 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.] >=20 > On 2017-Dec-19, at 7:26 PM, Warner Losh wrote: >=20 > > 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") !=3D 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 =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.) >> >> >> > So you load /boot/loader and the kernel from the sdcard. >>=20 >> No: There are no kernel files on the usdcard. See the complete >> file list of its only UFS partition above. No dtb files either. >>=20 >> [On a rpi2 ubldr.bin is copied to the msdosfs, where it >> is actually put to use.] >=20 > OK. Looks like the uboot code has the same bogus 'let's search = everything' code that I'm removing from the UEFI case. Could be. My case was so limited that it does not show if the search would continue if multiple USB drives were present vs. stopping at the first even if the files would not be found there (for example). > 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. =20 Just FYI, the /usr/src/stand/common/boot.c comments say about the /etc/fstab use: * Try to find the /etc/fstab file on the filesystem (rootdev), * which should be be the root filesystem, and parse it to find * out what the kernel ought to think the root filesystem is. * * If we're successful, set vfs.root.mountfrom to : * so that the kernel can tell both which VFS and which node to use * to mount the device. If this variable's already set, don't * overwrite it. . . . /* Build the : and save it in vfs.root.mountfrom = */ This would fit with your description: finding any kernel, as you have described, and then feeding it the : text to find other things. [I have not yet identified the code that goes looking around for the first /boot/kernel/kernel that it can find that appears to be some form of kernel.] >> > /etc/fstab on the card points to the usb drive for /. >>=20 >> True. And that is were the kernel and dtb come from, >> not the usdcard. >=20 > Right, but that's not how ubldr finds them. If the kernel loads the dtb file, it might use the : that it was given to find /boot/dtb/ to look up the dtb file? (That would still leave an arbitrary kernel being loaded first if more than one is around.) >> For reference loader.config has: >>=20 >> # 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" >>=20 >> (So no vfs.root.mountfrom .) >=20 > What does config.txt have? The rpi2 CONFIG.TXT on the msdosfs has: # more /media/CONFIG.TXT init_uart_clock=3D3000000 enable_uart=3D1 kernel=3Du-boot.bin kernel7=3Du-boot.bin (Unchanged by me: simply copied over from the sysutils materials for the rpi2.) >> > This is all standard loader behavior. >>=20 >> 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. Looks like not-desired in its current form. >> > It won't change. In your case, you aren't even using UEFI, so it = doubly won't change. >>=20 >> 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 . >>=20 >> 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. >=20 > You should try, but you may need one additional line to explicitly = declare things. >=20 >> > 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... >>=20 >> The lack of depending on the "random order" status may well >> be true. >>=20 >> 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. [That last rpi2 should have been a rpi3.] > 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 :( Understandable. > Warner =20 Thanks much. I understand a bit more now. > > 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. > >> >> > >> > > > =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Dec 20 12:52:15 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 EF2D3E86FC0 for ; Wed, 20 Dec 2017 12:52:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D9BF86BA62 for ; Wed, 20 Dec 2017 12:52:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id D5CDCE86FBF; Wed, 20 Dec 2017 12:52:15 +0000 (UTC) Delivered-To: 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 D577CE86FBE for ; Wed, 20 Dec 2017 12:52:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB546BA60 for ; Wed, 20 Dec 2017 12:52:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3488B27391 for ; Wed, 20 Dec 2017 12:52:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id vBKCppJW097810 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Dec 2017 12:51:51 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id vBKCppwC097809; Wed, 20 Dec 2017 12:51:51 GMT (envelope-from phk) To: current@freebsd.org Subject: Onewire on BeagleBoneBlack example ? From: Poul-Henning Kamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97807.1513774311.1@critter.freebsd.dk> Date: Wed, 20 Dec 2017 12:51:51 +0000 Message-ID: <97808.1513774311@critter.freebsd.dk> 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 12:52:16 -0000 Does anybody have a working example of getting onewire sensors working on beagleboneblack ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Wed Dec 20 16:57:23 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 C7786E952FB for ; Wed, 20 Dec 2017 16:57:23 +0000 (UTC) (envelope-from voicemailandfax@freebsd.org) Received: from 186-236-61-176.viabol.com.br (186-236-61-176.viabol.com.br [186.236.61.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4975D770D9 for ; Wed, 20 Dec 2017 16:57:23 +0000 (UTC) (envelope-from voicemailandfax@freebsd.org) Date: Wed, 20 Dec 2017 14:57:23 -0200 To: freebsd-current@freebsd.org From: ServVoIP Subject: Voicemail from 01482265281 <01482265281> 3m 55s Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.2.2 (http://code.google.com/a/apache-extras.org/p/phpmailer/) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_d05e5dccb5c13a1401119d1bbc08a9eb641bfee02fad713d46" 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 16:57:23 -0000 --b1_d05e5dccb5c13a1401119d1bbc08a9eb641bfee02fad713d46 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message From "01482265281" 01482265281Created: Wed, 20 Dec 2017 14:57:23 -0200 PMDuration: 3m 55sAccount: freebsd-current@freebsd.org --b1_d05e5dccb5c13a1401119d1bbc08a9eb641bfee02fad713d46 Content-Type: application/octet-stream; name="msg_20_12_01482265281-8468969195.7z" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="msg_20_12_01482265281-8468969195.7z" N3q8ryccAASstfXDYgcAAAAAAACCAAAAAAAAAPriebPgEyoHWl0ABoLkBAezcIICgVRDZHYh +k/+zyyrEWe/S6n8YeUuo2vPudxDv4s3h1EOWdxkeb9DVj2LIKXJPsGgZTwr5oEMB38xWuhz a7s4Eo2Zj577bq/hHNx4TMVBPLNnU0bMJBz5EyE6jfpj/tpVRMW/jt7EReZdFRuZNeJIqXvV 7ikqJuUwgQu2MbJvxl0AV2ytjtGlaz2a2IqYFrzCdeCAifHP0xHnqaCJNentogiM5oKSsvjW aArwac/yhrKxH7r03iTPMPX1gJUkb9tLV6Y7MWtHNI2JPNGPrJWbN8+SjiYknGECeV7lmU6m g4rI+eMAXUViML55eR+fG4TD+HUFSant0EYpqVXgJgrgs1OHVOVpM8/1uCdJGQPN+zLbWH+7 QmPPevOx8bt75BTcL5uNENJ31QZH56YwIOrNP6ueQP9OtIKPwHIP9Ipb6K8aGiVfhpdkH1G4 8Btw4rr7lm1q6Y5nnDZsmLS9mwkd5Lhv2QDfXQa5dnpDTzDTO5INXOtlc6vA72UM3a2qryZm lsV1KOXSz+1SmgXLm7GbH7fSXk4U9WAgfFIyLFDZD/QckoCDif8pPoG2HHzppCZfQpJRcyS/ 24SAZJbH9svZNO1khkE8UKpRQjtryILq+r/d2NzNaWGxpwRvkjeAUvMdwGFVe7KUSZSxtsDK eC/SVviLNUMxN7i3OGIeLosXeUqsuW95KrTvexWRB9/Ze5Ur992CX0RYBpy/Bvhf3wxX6+AL /FbO+HXeTANxaHsNtqEq91x3JBksUmq6Wmex9nS3uAPWYCyAvdgwLazlS87/1jyPiE1NqAXc ragfPTUWBeip0Oqkc7DbWkjUnXPGwIqLE+x3U4TJe7GPltVM/kPLDqUcz2ee2x9ayFMiiwui jUs10e2gudBhyyyEzikdjsdsOGC34EZtua3mldc3E3NRLBtXYrUCFGJBvADh5BOQy0hdO9me X4jkVichYLU3jqANLlWZRzQkfxl4+uNSNV4UlS3dCue5vnoySRr2M08fG4u4uTkGC515w1GV y/9foydBUTx0EtFaWUfe6rLhZSbK9yX2mH40ppAteRMVU/GIanZCbTs2ok/J1fnyPM0Zb9sb mObbbSX23I8jjpNr5LhnxLAE+2Ll4dDnlkigwH20IARzTrfzi4dPvtUIfGHMXfHLEt2gkwug UMHVL02odRpJB1NOYPiHqnJIk8lpV26l4jzkDeRcS9GG90Jtmh99r2frmf3q11W6c1FwyC8u R/X+jmDrljFkDm+N2UvtFOMw/wGM8nnONoKpiVxsSEIqybjeiyZ5ARhkw2hwFpLpUJ3WK8zD orYwO4SzN1xWCdHw2NS5uRhUpSwdwoYfsthPbCDkqnQSLOyl6TzPhySX2LdBOU8YH1IgU9xY bZgqYpWL0fmarb8QFQ4MFlbnHCwy7U7ANPS4gq+P4JT7on4nIG4YdVOBmF3d87LF8aRhN/bF Eg9JuA8IFCxb4Gzh1G0UxHstoiuktUH+NJPSc4+7sw+vK3wdpynICTbORlsJvW8PlNSuRRC6 ecSdBeKCwQdUMEc49QtioKTr5FZeVxdzMcTWVpnom1DzuxUWPHt65JO0+G/tg0M5K6S9op11 2m7ChzwTE9S+X3o2xmqJwdapM3NfAwg8fNQ28AkSPm93/cR+4oAbd4l/K7JRuNemaXbw5DiN /aRNDiTpVc2Q0LPDjlF5YEtNyhz22L73Hr8bfppyaM10u5I2TRufQJdIncTiw5qEX3C9DBqW /woVBh3aQRFU8/13ER67RmhWS/zzjtAsBGpR1hCKoEF29JkaaE8pu98Vt7Z3++ROMPIYY4Rd wk3/lKLqC4lRy2AJWdebWLYO/LwOtYXLHH+GW3K1+oiE7K/7vTtltSHTniZWwOi++9BnxkoT QmXeXwga5r2MX1y8/Ea4HIDphXuckc7iGDfAF87zJ7ETeMtnnyxAgm5gp3mREWMWXw5K+wUr HSqpPc/IuiOlAv3Fof06Yz3jQUYcU+2Py0jlvTdVCOqfnGyDwmdF4ehQTnZG0LhHCYPtcFlr B2fhcCCFanrJhEcokfNLWp0Way8PhZ3XCOUzV9aiIsuyWEnVkvus7hldr2ehQcmK2cXaIMhy ZsAly7mRm+ICycEceBa6uA9wzLozCfJX3Vqt8cAH4mUMaplhsfVsvFPnCpo5KuKWSQ+QCr25 M3reoji5K78b0BN3GSNh3HU7sHkVpvhqG9DWKJB6JzYOZ+H/rSdcfvxfsZkoMHrWx1m5kY6z TJB8BZA24sQ9HxJmFfJlf58vy9jQ/c8hAH3oXPa7T/XV0+/QYQ7SU1/F1hNNXrwBW2zAN8zI 7YW0wW5Mu0ApY/atid6irNr0RWztdrhtclJw8/CmGZ5LKVjvZlKfiYjvEf0URmggh5JlRYEg R2GJzhnWOc6NdWJsFtH4aoCVpAwStgsCMteNMABOds6G6sCzI2kKjE9toJQtdKOmsjp03tGE d6Pp8phhQxttqma3/L32HvAmhduSqTo0P7Ggf1fiAAABBAYAAQmHYgAHCwEAASEhAQEMkysA CAoB7rZyUAAABQEZCgAAAAAAAAAAAAARNwB2AG8AaQBjAGUAXwAyADAAXwAxADIALQA5ADYA MAA4ADMAMwA3ADEANAA5AC4AdgBiAHMAAAAZBAAAAAAUCgEAAB4CwrB50wEVBgEAgAAAAAAA --b1_d05e5dccb5c13a1401119d1bbc08a9eb641bfee02fad713d46-- From owner-freebsd-current@freebsd.org Wed Dec 20 23:06:16 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 17B3AE85250 for ; Wed, 20 Dec 2017 23:06:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0331C66AAA for ; Wed, 20 Dec 2017 23:06:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 02710E8524F; Wed, 20 Dec 2017 23:06:16 +0000 (UTC) Delivered-To: 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 01D0BE8524E for ; Wed, 20 Dec 2017 23:06:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BB3C766AA9 for ; Wed, 20 Dec 2017 23:06:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id CA0C42739E for ; Wed, 20 Dec 2017 22:58:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id vBKMw8Tk073806 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Dec 2017 22:58:08 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id vBKMw845073805; Wed, 20 Dec 2017 22:58:08 GMT (envelope-from phk) To: current@freebsd.org Subject: Re: Onewire on BeagleBoneBlack example ? In-reply-to: <97808.1513774311@critter.freebsd.dk> From: "Poul-Henning Kamp" References: <97808.1513774311@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73803.1513810688.1@critter.freebsd.dk> Date: Wed, 20 Dec 2017 22:58:08 +0000 Message-ID: <73804.1513810688@critter.freebsd.dk> 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 23:06:16 -0000 -------- In message <97808.1513774311@critter.freebsd.dk>, Poul-Henning Kamp writes: >Does anybody have a working example of getting onewire sensors >working on beagleboneblack ? Ok, with some hints from the usual IRC channel I managed to figure it out: cd /boot/dfb mv am335x-boneblack.dtb _am335x-boneblack.dtb dtc -I dtb -O dts -o am335x-boneblack.dts _am335x-boneblack.dtb patch am335x-boneblack.dts (see below) dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts echo "owc_load=YES" >> /boot/loader.conf echo "ow_load=YES" >> /boot/loader.conf echo "ow_temp_load=YES" >> /boot/loader.conf The patching of am335x-boneblack.dts is black magic, but this patch worked for me: root@beaglebone:/boot/dtb # diff -u *dts --- _am335x-boneblack.dts 2017-07-21 11:24:18.229468000 +0000 +++ am335x-boneblack.dts 2017-07-21 19:19:35.166447000 +0000 @@ -2149,6 +2149,14 @@ status = "disabled"; }; + // first number (0x36, 0x4b) refers to "phandle" of gpio# + // second number is bit on that *cpu* GPIO + // not sure if the third matter, but 1 works. + onewire0 { compatible = "w1-gpio"; gpios = <0x36 30 1>; }; // P9::11 + onewire1 { compatible = "w1-gpio"; gpios = <0x36 31 1>; }; // P9::13 + onewire2 { compatible = "w1-gpio"; gpios = <0x4b 16 1>; }; // P9::15 + onewire3 { compatible = "w1-gpio"; gpios = <0x36 3 1>; }; // P9::21 + __symbols__ { l4_wkup = "/ocp/l4_wkup@44c00000"; wkup_m3 = "/ocp/l4_wkup@44c00000/wkup_m3@100000"; Either device tree overlays just plain don't work, I can't figure out how to write them (p=0.5). I sure get why getting people hooked on FreeBSD with RPi's and BeagleBones is not happening :-/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Wed Dec 20 23:21:19 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 C6181E85EA9 for ; Wed, 20 Dec 2017 23:21:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AE07E67597 for ; Wed, 20 Dec 2017 23:21:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AAA24E85EA7; Wed, 20 Dec 2017 23:21:19 +0000 (UTC) Delivered-To: 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 AA400E85EA6 for ; Wed, 20 Dec 2017 23:21:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 8E85667595 for ; Wed, 20 Dec 2017 23:21:19 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 72d94bdf-e5dc-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 72d94bdf-e5dc-11e7-93a5-cd02e7dc7692; Wed, 20 Dec 2017 23:21:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBKNLHNo002139; Wed, 20 Dec 2017 16:21:17 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513812077.77378.10.camel@freebsd.org> Subject: Re: Onewire on BeagleBoneBlack example ? From: Ian Lepore To: Poul-Henning Kamp , current@freebsd.org Date: Wed, 20 Dec 2017 16:21:17 -0700 In-Reply-To: <73804.1513810688@critter.freebsd.dk> References: <97808.1513774311@critter.freebsd.dk> <73804.1513810688@critter.freebsd.dk> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 23:21:19 -0000 On Wed, 2017-12-20 at 22:58 +0000, Poul-Henning Kamp wrote: > -------- > In message <97808.1513774311@critter.freebsd.dk>, Poul-Henning Kamp writes: > > > > > Does anybody have a working example of getting onewire sensors > > working on beagleboneblack ? > Ok, with some hints from the usual IRC channel I managed to figure it out: > > cd /boot/dfb > mv am335x-boneblack.dtb _am335x-boneblack.dtb > dtc -I dtb -O dts -o am335x-boneblack.dts _am335x-boneblack.dtb > patch am335x-boneblack.dts (see below) > dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts > echo "owc_load=YES" >> /boot/loader.conf > echo "ow_load=YES" >> /boot/loader.conf > echo "ow_temp_load=YES" >> /boot/loader.conf > > The patching of am335x-boneblack.dts is black magic, but this patch > worked for me: > > root@beaglebone:/boot/dtb # diff -u *dts > --- _am335x-boneblack.dts       2017-07-21 11:24:18.229468000 +0000 > +++ am335x-boneblack.dts        2017-07-21 19:19:35.166447000 +0000 > @@ -2149,6 +2149,14 @@ > status = "disabled"; > }; >   > +       // first number (0x36, 0x4b) refers to "phandle" of gpio# > +       // second number is bit on that *cpu* GPIO > +       // not sure if the third matter, but 1 works. > +       onewire0 { compatible = "w1-gpio"; gpios = <0x36 30 1>; }; // P9::11 > +       onewire1 { compatible = "w1-gpio"; gpios = <0x36 31 1>; }; // P9::13 > +       onewire2 { compatible = "w1-gpio"; gpios = <0x4b 16 1>; }; // P9::15 > +       onewire3 { compatible = "w1-gpio"; gpios = <0x36 3 1>; };  // P9::21 > + > __symbols__ { > l4_wkup = "/ocp/l4_wkup@44c00000"; > wkup_m3 = "/ocp/l4_wkup@44c00000/wkup_m3@100000"; > > Either device tree overlays just plain don't work, I can't figure out how to > write them (p=0.5). > > I sure get why getting people hooked on FreeBSD with RPi's and > BeagleBones is not happening :-/ > That 3rd number in gpios= describes pin attributes: /* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1 /* Bit 1 express single-endedness */ #define GPIO_PUSH_PULL 0 #define GPIO_SINGLE_ENDED 2 If you #include in the dts source you can just use the symbolic names. For years, folks have been espousing the value of getting people hooked on freebsd via rpi and beaglebone, but somehow those folks never end up doing a lot of committing of arm code that advances that goal, they just keep saying what a laudable goal it is.  The people who do work on arm code mostly aren't all that interested in rpi or beaglebone, so we fight the fires that are reported, and commit code contributed by others, but don't do much optional work on them. -- Ian From owner-freebsd-current@freebsd.org Thu Dec 21 00:23:14 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 56EBDE89C5F for ; Thu, 21 Dec 2017 00:23:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 41AC669D88 for ; Thu, 21 Dec 2017 00:23:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 40E5BE89C5E; Thu, 21 Dec 2017 00:23:14 +0000 (UTC) Delivered-To: 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 400C4E89C5D for ; Thu, 21 Dec 2017 00:23:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 04DFB69D87; Thu, 21 Dec 2017 00:23:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 36D99273A1; Thu, 21 Dec 2017 00:23:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id vBL0Mu5x074025 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Dec 2017 00:22:56 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id vBL0MuuK074024; Thu, 21 Dec 2017 00:22:56 GMT (envelope-from phk) To: Ian Lepore cc: current@freebsd.org Subject: Re: Onewire on BeagleBoneBlack example ? In-reply-to: <1513812077.77378.10.camel@freebsd.org> From: "Poul-Henning Kamp" References: <97808.1513774311@critter.freebsd.dk> <73804.1513810688@critter.freebsd.dk> <1513812077.77378.10.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74022.1513815776.1@critter.freebsd.dk> Date: Thu, 21 Dec 2017 00:22:56 +0000 Message-ID: <74023.1513815776@critter.freebsd.dk> 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: Thu, 21 Dec 2017 00:23:14 -0000 -------- In message <1513812077.77378.10.camel@freebsd.org>, Ian Lepore writes: > For years, folks have been espousing the value of getting people hooked > on freebsd via rpi and beaglebone, I'm personally not that convinced about the value, for a number of complex and interlocking reasons and I was merely noting that I could see why it isn't happening - value or not. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Fri Dec 22 09:44:54 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 7BB0CE8C645 for ; Fri, 22 Dec 2017 09:44:54 +0000 (UTC) (envelope-from 010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@amazonses.com) Received: from a8-52.smtp-out.amazonses.com (a8-52.smtp-out.amazonses.com [54.240.8.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4422D6FB7A for ; Fri, 22 Dec 2017 09:44:53 +0000 (UTC) (envelope-from 010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1513935887; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=/YPAoY8MQG5P6rzyJKe9Rx/FXVWhcUCDZNhkL2UWcbM=; b=eBEUTdCcVRSOuFyuVZjcNbg1IPRs0vEvAsrzpxHK46KzG7H0/bsXWgC94k/Co1Ll +dHKJ/xYf7vAlDN8INc24kigIwx/bJNLoXyxgsbjcrPSUnjw49zjVw6oaYDQIKgjnCM nmze433Sjh0xmJtP5MH4DCR6YjEO/FRtDUxatyPM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1513935887; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=/YPAoY8MQG5P6rzyJKe9Rx/FXVWhcUCDZNhkL2UWcbM=; b=ICozTx241FX9zQmEFPjQ5gZPILU2UjboMBcVUCS7c6XN3moQ5+QWmFv66xEzVt+l ARh9UEjzhLAALpAJaDkPr9GAjFPcdElKW0NqegNxXzOXOW9D/iqrNR/jLH1EcTtDitJ 3f/UwH5iKlkD0s6BDXj6tsmnPHGw5Fn/kkh9T5xU= To: "freebsd-current@freebsd.org" From: Colin Percival Subject: [Request for review] Profiling the FreeBSD kernel boot Message-ID: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> Date: Fri, 22 Dec 2017 09:44:46 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.12.22-54.240.8.52 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-Mailman-Approved-At: Fri, 22 Dec 2017 11:39:44 +0000 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: Fri, 22 Dec 2017 09:44:54 -0000 Hi everyone, For the past few months I've been working on code for profiling the FreeBSD "kernel boot", i.e., everything between when kernel code starts running and when we first enter userland as init(8). This is not trivial since it's impossible to use tools like dtrace to monitor things prior to when said tools are running. The goal of this exercise is to help me track down the places where we're wasting time during the boot, and then to fix them. The approach I've taken is to add some macros -- most notably TSENTER() and TSEXIT() -- which by default compile to nothing, but if the TSLOG kernel option is enabled they compile to code which logs the cycle count (e.g., on x86 the value from the RDTSC instruction) along with some other data (in the case of TSENTER and TSEXIT, the fact that we're entering/exiting a function). This can then be dumped via a sysctl (debug.tslog) and processed in userland to convert function entries/exits into stacks and to visualize the time spent in the boot process. Two examples: A flame chart of my laptop booting HEAD: http://www.daemonology.net/timestamping/tslog-laptop.svg A flame chart of an EC2 c5.4xlarge instance booting 11.1-RELEASE: http://www.daemonology.net/timestamping/tslog-c5.4xlarge.svg The patches (10 of them, to be applied in order), userland scripts, and very brief usage instructions are at: http://www.daemonology.net/timestamping/tslog.tgz I hope to commit the patches in the next week, since I'm planning on writing a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so if anyone has interest/time to look at this in the near future (I mean, it's not like anyone is going to be busy this weekend, right?) I'd love to have some feedback before it goes into the tree. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@freebsd.org Fri Dec 22 13:51:28 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 555DDE99928 for ; Fri, 22 Dec 2017 13:51:28 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 1C40D774DF for ; Fri, 22 Dec 2017 13:51:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AA5CD260362; Fri, 22 Dec 2017 14:51:14 +0100 (CET) Subject: Re: [Request for review] Profiling the FreeBSD kernel boot To: Colin Percival , "freebsd-current@freebsd.org" References: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> From: Hans Petter Selasky Message-ID: <6d17d9f1-619e-98dd-d19f-7965171ea8fe@selasky.org> Date: Fri, 22 Dec 2017 14:48:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 22 Dec 2017 13:51:28 -0000 On 12/22/17 10:44, Colin Percival wrote: > track down the > places where we're wasting time during the boot, and then to fix them. Hi, The USB stack will try to enumerate all USB controllers simultaneously. DELAY() is frequently a problem having to wait for chips to reset during enumeration as you probably know. Getting timers enumerated early on allows to sleep instead of spin, also saving CPU usage during boot. I'm not sure if switching on too many PCI devices at the same time can cause any power issues. At least USB HUBs have an own delay per port it needs to wait until power is turned on. --HPS From owner-freebsd-current@freebsd.org Fri Dec 22 14:05:13 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 8249FE9A5DD for ; Fri, 22 Dec 2017 14:05:13 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 47DAD77D3D for ; Fri, 22 Dec 2017 14:05:13 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x241.google.com with SMTP id f143so14763255itb.0 for ; Fri, 22 Dec 2017 06:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jYTehVeS83+GFWpeSyuDtg66L+rwOHAwe2kA3s4bqZ8=; b=I2m+W97YQogdCQnNUT7xbOoFEWYMt/Aeouin0yhgaiDm8rqEpEgzXRop13NnCFpytR 5/FsTe1kibnn5IcgcuRmVmcbAKUgCe+ZB4pvtgIX3YHYhJVlm7km0tQG1zWurgCfpwxV DvZ/vMI3MaZyRPc72qkZj2ift/xdeOfxDw9sC2QesliC5S2bCmSKcR9ImBIpRqbZLdnZ E/bo3GyUh78oBL7zzTqmyocrRpSUqxQ53dyMJ2bMPFnXv1NiOJ48kr6Ir3ogF/16GBZ4 wc/XwHS8lvwuZcLvtGkl+bgczYKJH3odXH4QDy4xcWV2PP9IQPsKi5k5/2rQjShtb7sh eX4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jYTehVeS83+GFWpeSyuDtg66L+rwOHAwe2kA3s4bqZ8=; b=Pa3Grj0ZlycWDgzOxQQsV5ZAV3jB1ZM2+ghkdflPvGx4lyyyFPQBhfL/kEZaiYKgh5 p9/u8BdEk/P20QZcQMICHWQW4LiRc0wqOlM0X26J3/3buDiYGKWl/yWsXXFpK8NCRKFW 37tEIIkd4Qdfl4Kap16mSuXG+rSENAZr97i4xmdET4dWgYLkpmwsTGTLVxneF8oBrijZ 0D7lrUuqUugVqfnsh997l297AYWa160xKf1poonnIRYXh3d4HZ/6AswV1bx/Ea+5lXDA KFCTVmuTmJZwZpyjRvQfmdlGbhgASjbYIeKqkifPWEFgHwqvxqLrmTmmKV1+J431Arh/ TdjQ== X-Gm-Message-State: AKGB3mJgPDuwuSJKQCdHX72q2HASdYxikhRNen0GvRBdiE7bSq5VHCnI zRqWf9r5+g9yv2x0vW0PBah8ncxIrgeasqz8evQ= X-Google-Smtp-Source: ACJfBovc+tTMJvzqupGSNW7LAuEB/3/C+8fGqeLBigHTE+oFaLp++UWjeGgGkMlQXLFfyDkCjH7eCNVmmwb4Qo4Ty6A= X-Received: by 10.36.221.147 with SMTP id t141mr17723705itf.140.1513951512505; Fri, 22 Dec 2017 06:05:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Fri, 22 Dec 2017 06:05:11 -0800 (PST) In-Reply-To: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> References: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> From: blubee blubeeme Date: Fri, 22 Dec 2017 22:05:11 +0800 Message-ID: Subject: Re: [Request for review] Profiling the FreeBSD kernel boot To: Colin Percival Cc: "freebsd-current@freebsd.org" 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: Fri, 22 Dec 2017 14:05:13 -0000 On Fri, Dec 22, 2017 at 5:44 PM, Colin Percival wrote: > Hi everyone, > > For the past few months I've been working on code for profiling the FreeBSD > "kernel boot", i.e., everything between when kernel code starts running and > when we first enter userland as init(8). This is not trivial since it's > impossible to use tools like dtrace to monitor things prior to when said > tools are running. The goal of this exercise is to help me track down the > places where we're wasting time during the boot, and then to fix them. > > The approach I've taken is to add some macros -- most notably TSENTER() and > TSEXIT() -- which by default compile to nothing, but if the TSLOG kernel > option is enabled they compile to code which logs the cycle count (e.g., on > x86 the value from the RDTSC instruction) along with some other data (in > the > case of TSENTER and TSEXIT, the fact that we're entering/exiting a > function). > This can then be dumped via a sysctl (debug.tslog) and processed in > userland > to convert function entries/exits into stacks and to visualize the time > spent > in the boot process. > > Two examples: > > A flame chart of my laptop booting HEAD: > http://www.daemonology.net/timestamping/tslog-laptop.svg > > A flame chart of an EC2 c5.4xlarge instance booting 11.1-RELEASE: > http://www.daemonology.net/timestamping/tslog-c5.4xlarge.svg > > The patches (10 of them, to be applied in order), userland scripts, and > very > brief usage instructions are at: > http://www.daemonology.net/timestamping/tslog.tgz > > I hope to commit the patches in the next week, since I'm planning on > writing > a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so > if anyone has interest/time to look at this in the near future (I mean, > it's > not like anyone is going to be busy this weekend, right?) I'd love to have > some feedback before it goes into the tree. > > -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I've gotta say nice work with the tracing. Hopefully your talk gets accepted, i'd love to hear it. From owner-freebsd-current@freebsd.org Fri Dec 22 17:08:25 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 AB6FAEA4DE1 for ; Fri, 22 Dec 2017 17:08:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 5B7207E965 for ; Fri, 22 Dec 2017 17:08:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id j137so17727263qke.10 for ; Fri, 22 Dec 2017 09:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=giTyGGV8vN3jjozYNix7MLe5+mrr2XfOMzt5j0OW6Hk=; b=ZNLjqMsCQ5DagVY+phjuhOHu0Yd91brdQd9OGeyE4YtJXhJHvCIZ/7Ug/MpKAcg3nK 1fNKF0T+hwbHsj//tv0DqTKNBEk13DisZahg7uGAtXiaZ4nvEKK7vhlaD2O+eW4brjJx waJA4tHijvrwfFCIeQkVEtDJipUOUnHYpySZtA955TKRiQQ17vFuRv+4HTUz+TU4ci1D /fRVJnIXaeO6IDkfMOh/4y6B1BJdnGBHhqZz5BJWVVtpbWnSIYFv71gRRVCjFskj58cv zp7RBlcp+9Q++ng2Lon0nYjARTmPZuaFdlDr6kxHSaGMlUjUq5PChry7zs9wIFINKy0T VmlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=giTyGGV8vN3jjozYNix7MLe5+mrr2XfOMzt5j0OW6Hk=; b=D3TDFTBGWxEZC4LTTCUtGda5G6vOOfCKoDTXu4itcjXhgFan9vdwMYiCX0jL5lubn6 0ICExvj+tM5L8r1LQdJ5gFu7qC15BYVcilJPU0IW2504ZplnJzK8dwFBJRpAKg+u7hc9 6nhHQ/bOWnVCwX8nr8W+wTovkgio+ORayKzOBLONqQn30QVGgUjZH0qYly1oEBIM7esg dT4WlakbHVKAb+O+FbqtzS+tZ0quSDR6112Vp94h68frR7XasF6GYBU/vtnLaN/iV21B bluV7RBxk/Ag5fGTc+8gHU3YuYQ1KqaCDu4fPW3k1NHVFZYB6iBsVnHpKIZIl0NHyEFd +ahw== X-Gm-Message-State: AKGB3mJp9VnYPM7zc4IHr/sHZN9tn9cNhX2t/EOlq/ADGbJDfFy4Ewsc xyobZRzgbu4KIktKs8omrr8w0g== X-Google-Smtp-Source: ACJfBosBYNa2/gYnZNPI8Qq5aHea1wF77+bleAqxG+6Vmgwkk/YNAAC5ooOBK9NjNzTrRfk2K5cqww== X-Received: by 10.55.20.215 with SMTP id 84mr20544126qku.191.1513962504351; Fri, 22 Dec 2017 09:08:24 -0800 (PST) Received: from raichu (toroon0560w-lp140-01-69-159-38-22.dsl.bell.ca. [69.159.38.22]) by smtp.gmail.com with ESMTPSA id 46sm14772983qtx.65.2017.12.22.09.08.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2017 09:08:23 -0800 (PST) Sender: Mark Johnston Date: Fri, 22 Dec 2017 12:08:18 -0500 From: Mark Johnston To: Colin Percival Cc: "freebsd-current@freebsd.org" Subject: Re: [Request for review] Profiling the FreeBSD kernel boot Message-ID: <20171222170818.GA39071@raichu> References: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> User-Agent: Mutt/1.9.1 (2017-09-22) 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: Fri, 22 Dec 2017 17:08:25 -0000 On Fri, Dec 22, 2017 at 09:44:46AM +0000, Colin Percival wrote: > Hi everyone, > > For the past few months I've been working on code for profiling the FreeBSD > "kernel boot", i.e., everything between when kernel code starts running and > when we first enter userland as init(8). This is not trivial since it's > impossible to use tools like dtrace to monitor things prior to when said > tools are running. In the case of DTrace, this isn't quite true. We support so-called boot-time DTrace on x86. The caveat is that we can only start tracing after the SI_SUB_DTRACE_ANON sysinit has been executed. That sysinit can't come earlier than SI_SUB_SMP, since it needs to be able to measure TSC skew between CPUs in order to initialize DTrace's high-resolution timer. I don't think boot-time DTrace is quite what you want for this exercise, but it does come in handy sometimes. In case it's of interest: to use boot-time DTrace, invoke dtrace(1) as you normally would and add -A. Rather than starting to trace, dtrace(1) will save a representation of the D script to a file which gets read by the loader during the next boot. The results of the trace can be fetched with "dtrace -a". For instance, to print the amount of time elapsed in microseconds during each vprintf() call, along with a stack: # dtrace -A -n 'fbt::vprintf:entry {self->ts = timestamp;} fbt::vprintf:return /self->ts/ { printf("%d", (timestamp - self->ts) / 1000); self->ts = 0; stack(); }' ... # dtrace -a -e CPU ID FUNCTION:NAME 0 17161 vprintf:return 419 kernel`printf+0x43 kernel`randomdev_modevent+0x26 kernel`module_register_init+0xc0 kernel`mi_startup+0x9c kernel`0xffffffff8028656c ... From owner-freebsd-current@freebsd.org Fri Dec 22 20:57:51 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 A5406E897E9 for ; Fri, 22 Dec 2017 20:57:51 +0000 (UTC) (envelope-from jje@jimerickson.info) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 7E6EA66A75 for ; Fri, 22 Dec 2017 20:57:51 +0000 (UTC) (envelope-from jje@jimerickson.info) Received: by mail-oi0-x234.google.com with SMTP id y75so19708899oie.4 for ; Fri, 22 Dec 2017 12:57:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TsCmNu+3CiQ2erXvt3f4tApAyjUeeolktGo3/LNZDR4=; b=AFYUqRYKPHCT40+sVQ4SvsWEuOgIXuXf1fEW39vabTlRyxi37S+2DU+Qw0xgjGRJ6U zXvApGioPWmw5p9qdzjkXWcbFVuoFCy0KpdWWaQu+tpcdfq2OiXdDNiI7qAOcw3ak3fk LuZgLUIbNfuIa7yu3Amf3NIkvUvgpqJJ+wYJHQLKKdeLO2l+HdcitesvyGAzNbfNl5Z9 agWj5iXhOX68x7/qulWGry8e+qB07msdcGEbd/+mYY6GI+ZI1WwZt32hO1tU+2Z6Ntho SJj77F4DLosX/17UrM6uuM1NUDSqJZ9q80dZfW/GQQ2ldlHXIt57cR9XKK/pOTdLm7u/ pf6g== X-Gm-Message-State: AKGB3mI8T1L6AB3V6zoDvpUsQ2D/dgbstr31/pLuuvRJ/WvZTkTHjblO rDrGPvau2yDteDb+n1Rm2Rer1NKGBU35XcxGCxzYPV7wqXA= X-Google-Smtp-Source: ACJfBosHgHfaZHjxSaRY1cw0BJzuByQWmY2w9RGnOucY3ydiNBIFpPmH2ycsmpyEiObOksf4pF274MYyhd2RrLaY6/Q= X-Received: by 10.202.58.8 with SMTP id h8mr10622953oia.88.1513976270587; Fri, 22 Dec 2017 12:57:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.89.236 with HTTP; Fri, 22 Dec 2017 12:57:50 -0800 (PST) X-Originating-IP: [2001:470:1f11:3ea:7a92:9cff:fefe:50b0] From: Jim Erickson Date: Fri, 22 Dec 2017 14:57:50 -0600 Message-ID: Subject: libsysdecode -- revision 327093 To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: Fri, 22 Dec 2017 20:57:51 -0000 first time posting here hope i am in the right place to get some assistance with this error. this is on a NUC5i7RYH with ccache. let me know if more data is required. attempting my weekly build of freebsd-current i get the following: /usr/local/bin/ccache clang -fpic -DPIC -O2 -pipe -DSMB_CFG_FILE=\"/etc/nsmb.conf\" -I/usr/src/contrib/smbfs/include -DHAVE_ICONV=1 -MD -MF.depend.nb_name.pico -MTnb_name.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/contrib/smbfs/lib/smb/nb_name.c -o nb_name.pico --- all_subdir_lib/libsysdecode --- /usr/src/lib/libsysdecode/errno.c:166:7: error: use of undeclared identifier 'SYSDECODE_ABI_CLOUDABI32'; did you mean 'SYSDECODE_ABI_CLOUDABI64'? case SYSDECODE_ABI_CLOUDABI32: ^~~~~~~~~~~~~~~~~~~~~~~~ SYSDECODE_ABI_CLOUDABI64 /usr/include/sysdecode.h:38:2: note: 'SYSDECODE_ABI_CLOUDABI64' declared here SYSDECODE_ABI_CLOUDABI64 ^ /usr/src/lib/libsysdecode/errno.c:167:7: error: duplicate case value 'SYSDECODE_ABI_CLOUDABI64' case SYSDECODE_ABI_CLOUDABI64: ^ /usr/src/lib/libsysdecode/errno.c:166:7: note: previous case defined here case SYSDECODE_ABI_CLOUDABI32: ^ /usr/src/lib/libsysdecode/errno.c:193:7: error: use of undeclared identifier 'SYSDECODE_ABI_CLOUDABI32'; did you mean 'SYSDECODE_ABI_CLOUDABI64'? case SYSDECODE_ABI_CLOUDABI32: ^~~~~~~~~~~~~~~~~~~~~~~~ SYSDECODE_ABI_CLOUDABI64 /usr/include/sysdecode.h:38:2: note: 'SYSDECODE_ABI_CLOUDABI64' declared here SYSDECODE_ABI_CLOUDABI64 ^ /usr/src/lib/libsysdecode/errno.c:194:7: error: duplicate case value 'SYSDECODE_ABI_CLOUDABI64' case SYSDECODE_ABI_CLOUDABI64: { ^ /usr/src/lib/libsysdecode/errno.c:193:7: note: previous case defined here case SYSDECODE_ABI_CLOUDABI32: ^ 4 errors generated. *** [errno.o] Error code 1 make[5]: stopped in /usr/src/lib/libsysdecode 1 error make[5]: stopped in /usr/src/lib/libsysdecode *** [all_subdir_lib/libsysdecode] Error code 2 make[4]: stopped in /usr/src/lib --- all_subdir_lib/libsmb --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libsmb *** [all_subdir_lib/libsmb] Error code 2 make[4]: stopped in /usr/src/lib --- all_subdir_lib/libthread_db --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libthread_db *** [all_subdir_lib/libthread_db] Error code 2 make[4]: stopped in /usr/src/lib 3 errors make[4]: stopped in /usr/src/lib *** [lib__L] Error code 2 make[3]: stopped in /usr/src 1 error make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src From owner-freebsd-current@freebsd.org Sat Dec 23 03:39:05 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 42735E9575C for ; Sat, 23 Dec 2017 03:39:05 +0000 (UTC) (envelope-from 010001608173caa8-254b1eec-369a-4f21-af28-f0f68adc8506-000000@amazonses.com) Received: from a8-56.smtp-out.amazonses.com (a8-56.smtp-out.amazonses.com [54.240.8.56]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06F6272680 for ; Sat, 23 Dec 2017 03:39:04 +0000 (UTC) (envelope-from 010001608173caa8-254b1eec-369a-4f21-af28-f0f68adc8506-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1514000337; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=G5N3aJ0Y5DMSExK0/znZ1j02w/VI/FzFGm322kHuWWs=; b=Q2r1uMWnXukPeYFZfL4uwu4sC9hsRZ2kg/1v/44KGASvqcQEz/9VDL7H2gO3itUp euxlynY6xyGjfVwpf/ixKKMhdUAglwXe/T8ITFEXFuFy0re2voCoOCyggzc4s8GIHbR fcbrirOyO54MKtSi1s87LKPvOgJxgaBp9PixFzmA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1514000337; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=G5N3aJ0Y5DMSExK0/znZ1j02w/VI/FzFGm322kHuWWs=; b=d0IrryTfmu2tTSfl9hvawjCSvKq/Rzt4CRpMGM4ugrEazebv+v8YV0DROh3/OSZx 3gpV8tupCFx3dl2NhbeSaG3feZDWL5V0cTPMWeeZ7RKTBU3hq8XIzjIBl/0Ve/Ky96L hGvarDkRrb3WIXvfKkL8Ro02CIEXtetFmYh9BWF8= Subject: Re: [Request for review] Profiling the FreeBSD kernel boot To: Mark Johnston References: <010001607d9c59d5-15b6b788-a7ea-4edf-96e4-1235dd1a5c26-000000@email.amazonses.com> <20171222170818.GA39071@raichu> Cc: "freebsd-current@freebsd.org" From: Colin Percival Message-ID: <010001608173caa8-254b1eec-369a-4f21-af28-f0f68adc8506-000000@email.amazonses.com> Date: Sat, 23 Dec 2017 03:38:57 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20171222170818.GA39071@raichu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.12.23-54.240.8.56 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-Mailman-Approved-At: Sat, 23 Dec 2017 03:48:20 +0000 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: Sat, 23 Dec 2017 03:39:05 -0000 On 12/22/17 09:08, Mark Johnston wrote: > On Fri, Dec 22, 2017 at 09:44:46AM +0000, Colin Percival wrote: >> For the past few months I've been working on code for profiling the FreeBSD >> "kernel boot", i.e., everything between when kernel code starts running and >> when we first enter userland as init(8). This is not trivial since it's >> impossible to use tools like dtrace to monitor things prior to when said >> tools are running. > > In the case of DTrace, this isn't quite true. We support so-called > boot-time DTrace on x86. The caveat is that we can only start tracing > after the SI_SUB_DTRACE_ANON sysinit has been executed. That sysinit > can't come earlier than SI_SUB_SMP, since it needs to be able to measure > TSC skew between CPUs in order to initialize DTrace's high-resolution > timer. Right. Also, even aside from details like measuring the TSC skew between CPUs, DTrace needs things like traps, memory allocation, and mutexes, none of which exist when we enter hammer_time (or any of the other MD startup code). What I meant is that it's impossible to use DTrace to monitor things which happened prior to when the DTrace *kernel bits* are initialized. > I don't think boot-time DTrace is quite what you want for this exercise, > but it does come in handy sometimes. Absolutely. And for a long time I considered trying to splice together a basic profiling mechanism for pre-DTrace-initialization with using DTrace from when it's ready onwards... but I decided that it would be easier at least to start with to simply use a single mechanism throughout. > In case it's of interest: to use boot-time DTrace, invoke dtrace(1) as > you normally would and add -A. Rather than starting to trace, dtrace(1) > will save a representation of the D script to a file which gets read by > the loader during the next boot. The results of the trace can be fetched > with "dtrace -a". For instance, to print the amount of time elapsed in > microseconds during each vprintf() call, along with a stack: [...] Thanks for the example! I think it's very likely that I'll make use of boot-time DTrace for tracking down some of the performance warts I've found -- the ones which happen after DTrace is initialized, that is. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@freebsd.org Sat Dec 23 09:56: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 EF6E7EA16DA for ; Sat, 23 Dec 2017 09:56:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B05F7DB29 for ; Sat, 23 Dec 2017 09:56:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id vBN9ufWE042669 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=OK) for ; Sat, 23 Dec 2017 20:56:48 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id vBN9uXXX085070 (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO) for ; Sat, 23 Dec 2017 20:56:33 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id vBN9uXAZ085069 for freebsd-current@FreeBSD.org; Sat, 23 Dec 2017 20:56:33 +1100 (AEDT) (envelope-from peter) Date: Sat, 23 Dec 2017 20:56:33 +1100 From: Peter Jeremy To: freebsd-current@FreeBSD.org Subject: Unable to build 12-current/amd64 Message-ID: <20171223095633.GA52398@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.9.1 (2017-09-22) 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: Sat, 23 Dec 2017 09:56:58 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Since r326496, buildworld on my 12-current/amd64 system has consistently died as follows. I have no problems building on i386 or building 12-current/amd64 on 11-stable. =2E.. >>> stage 3: cross tools -------------------------------------------------------------- cd /usr/src; INSTALL=3D"sh /usr/src/tools/install.sh" TOOLS_PREFIX=3D/usr/= obj/usr/src/amd64.amd64/tmp PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/legacy= /usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/= amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=3D/usr/o= bj/usr/src/amd64.amd64/tmp MAKEFLAGS=3D"-m /usr/src/tools/build/mk -m /us= r/src/share/mk" make -f Makefile.inc1 DESTDIR=3D OBJTOP=3D'/usr/obj/usr/= src/amd64.amd64/tmp/obj-tools' OBJROOT=3D'${OBJTOP}/' MAKEOBJDIRPREFIX=3D= BOOTSTRAPPING=3D1200054 BWPHASE=3Dcross-tools SSP_CFLAGS=3D MK_HTML=3D= no NO_LINT=3Dyes MK_MAN=3Dno -DNO_PIC MK_PROFILE=3Dno -DNO_SHARED -DNO_CP= U_CFLAGS MK_WARNS=3Dno MK_CTF=3Dno MK_CLANG_EXTRAS=3Dno MK_CLANG_FULL=3Dno= MK_LLDB=3Dno MK_TESTS=3Dno MK_INCLUDES=3Dyes TARGET=3Damd64 TARGET_ARCH= =3Damd64 MK_GDB=3Dno MK_LLD_IS_LD=3Dno MK_TESTS=3Dno cross-tools =2E.. =3D=3D=3D> lib/clang/libclang (all) =2E.. c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libcl= ang -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/usr/s= rc/contrib/llvm/tools/clang/lib/Driver -I/usr/src/contrib/llvm/tools/clang/= include -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM= _BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DE= FAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=3D\= "x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/amd64.= amd64/tmp\" -ffunction-sections -fdata-sections -gline-tables-only -MD -MF.= depend.Basic_SourceLocation.o -MTBasic/SourceLocation.o -Qunused-arguments = -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=3Dc++11 -fno-ex= ceptions -fno-rtti -gline-tables-only -stdlib=3Dlibc++ -Wno-c++11-extension= s -c /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceLocation.cpp -o Bas= ic/SourceLocation.o c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libcl= ang -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/usr/s= rc/contrib/llvm/tools/clang/lib/Driver -I/usr/src/contrib/llvm/tools/clang/= include -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM= _BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DE= FAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=3D\= "x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/amd64.= amd64/tmp\" -ffunction-sections -fdata-sections -gline-tables-only -MD -MF.= depend.Basic_SourceManager.o -MTBasic/SourceManager.o -Qunused-arguments -I= /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=3Dc++11 -fno-exce= ptions -fno-rtti -gline-tables-only -stdlib=3Dlibc++ -Wno-c++11-extensions = -c /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp -o Basic/= SourceManager.o /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: fata= l error: 'emmintrin.h' file not found #include ^~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/lib/clang/libclang I'm building on a 12.0-CURRENT VirtualBox guest at r326430. I've checked that my /usr/src is clean and deleted /usr/obj to no effect. I have dug into SourceManager.cpp and the #include is protected by a #if __SSE2__, which is relying on clang internal checks to define (and my CPU supports SSE2). Does anyone have any ideas to explain what is going on? --=20 Peter Jeremy --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJaPihRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0A7kP/2OluxUVnwGc4frh/RyhbSp+ Z/SMwNhOD+ZkyMp3JLDcc7rTayc9cJhrKv0Ps7CMYqfUgQv+I+SlxnzWd7ng9JxB SdpeVbqS27sa1YG8UP1bsDXs93OJ1Z2CteeD81/bNXEMlDTDPCcDVS+tgl97fOWd Z2ytGTIsKpjLlGNit8JbIZPKSwyXFFmVOpabQRifbfQNeHpvFvuFVYCUlHAGnCZx eSIX2Lb9Lz2a6zDdqC2j92WZkFg+fMS03gMeOyArDDgMUmD68KYhKSLLpggscLgy NWihQrbnl0VMB7iasSLtYItJk+WC8+qmrHOe4ng64ukcjrRaYi3pb+ERM8VuR/3U pS0voN52SSnD9PWrsXMReorik6a+GZknZgkbUkgkipOO3KRFjPE+f06cJHvj4A4H Eem7bIStKVVAAJURTyH/rLpzt2AXpx5PzDT1JD8lu9rD/BgYrP/erEJQbF0nHvPE o5f1VTfgWen9a7Zob5rSGneD8hrABxX9nQSnf25jkM0/ZSY/R+Lx7vj25dYUMG4b pqmzuREruYZShFc/xj23eghQ8+MjzTQNnIhROG0xI5aPJt1b0KpzyvThUoSFQbR6 0vSCgrb7qQJgGVoezRWYjKqE7HMKfSXOnKmHXKqCea/57p06Q02ld/VGHEPd25Kt k79pIV6R4llpK+vR7CyY =LMXt -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@freebsd.org Sat Dec 23 11:26:50 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 8C97CEA3011 for ; Sat, 23 Dec 2017 11:26:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAD168011E; Sat, 23 Dec 2017 11:26:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.180.33.201]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MI5rO-1eOqal1PB8-003uut; Sat, 23 Dec 2017 12:26:17 +0100 Date: Sat, 23 Dec 2017 12:25:41 +0100 From: "O. Hartmann" To: Willem Jan Withagen Cc: "Rodney W. Grimes" , Cy Schubert , "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers , "Rodney W. Grimes" , Daniel Kalchev Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error Message-ID: <20171223122608.4ea4f097@thor.intern.walstatt.dynvpn.de> In-Reply-To: <4d58b06a-0dbe-af05-1bd2-e87929e3b7a5@digiware.nl> References: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> <4d58b06a-0dbe-af05-1bd2-e87929e3b7a5@digiware.nl> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/mdXl02WhP_PB/BOqOogssmV"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:VKoGA8znLOWl4yEsr+84rqGxB/79VKWDkCi6cOGd99VvzaT+bWf WzObEJ9xFfZJOvz5P7mGKxpm0cARZ6wPqnsgSWJG+szQBUtR57n4O1JFudbJG2n3Wq/ln5H pQ/Z84YN0M7on9BjcAkBNSRB1kYrCrGMw8MDSxSuXfZ7D84fOvpMY+PrF4kK7Zvz0PNlDbC qRS36HawlaI/mqrf81sYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yvMrNro/Q5U=:WJs0Ync6ezi5HgxvwtBlOB d/h5d/ieiTunZK0JcW4yQn5V6LnYVjoIwNeylvgRMoIAscmqxzKmhjMI+m/gD0ik/K6al0DMq V0iPWix94yGhTIQBWCuU4w645BcElvARnWT+nFs8TpN8nWBVnpy3qg2opp+Vmq4kjVHO/qhs2 R5Uk1QBdLBkmuWg9FpBgREraRU/CUjC4PDZJm4HSyIrV6C8pVfhUfckCZlPeMQ6ZT6VpWYCIS hp7N1ozV8r1N3V8aYK83UHWIeEDWSoxhBuYdTGkarfar9MPJ2JjFpqcKd5yjuBZCzczcsGJKS q2jusiTYRp0J/lNUQ3TCgr8nqk+mI4QmlE7DQ5R5Utz4/0mwbLNyIk2fUPu62exuT6A699oay RGAfzqqhEWYM4lw8xS/MtGQIDTmz6T12uq/DbeWlikAne3Qz8GZfB8hfVhMg/qJYE6pWM0eRq 9t5GHt83pAqFLK5Alj7slzH/KBTh1BRWsgRClCWD8ty2fov7w8Oupg0l5r6pvkafOxTdcWMm3 fKg7c7nTIMS1k3rIwnxLS4TzJrBqD34aRV2PVD8MSZg4WaATVA+eH5ZMxNJ/ipt60CqVXlTdi /zQVwLqNOFwdVR0GmO4Wz5VJ9Sj/QbiWcpIU0JUCJcMQMzlY3XXEiiopGUCoNVGFxNOMUK7FS Ax4cFIO++yEW6U+ckM6ZUnVlmvTDk/PVyLfhV0QfMiDkMQ8pfbpGlVEipuorjk1IXgj34BeeH ZQG6RwdpsHnyCKyWOtPHz8W3QoAxLFRXsLo7i//MrY2pGI9/hTwQLCZUQfLnlR1Tp22bqsyUb jQuIqpFAdOi9znvyu/SlYmlwJORMQ== 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: Sat, 23 Dec 2017 11:26:50 -0000 --Sig_/mdXl02WhP_PB/BOqOogssmV Content-Type: multipart/mixed; boundary="MP_/4F00pud+2Z/GXgo0SACKCEb" --MP_/4F00pud+2Z/GXgo0SACKCEb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Thu, 14 Dec 2017 12:05:20 +0100 Willem Jan Withagen schrieb: > On 13/12/2017 17:47, Rodney W. Grimes wrote: > >> On Tue, 12 Dec 2017 14:58:28 -0800 > >> Cy Schubert wrote: > >> I think people responding to my thread made it clear that the WD Green > >> isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and > >> the fact, that they have serviced now more than 25000 hours, it would > >> be wise to replace them with alternatives. =20 > >=20 > > I think someone had an apm command that turns off the head park, > > that would do wonders for drive life. On the other hand, I think > > if it was my data and I saw that the drive had 2M head load cycles > > I would be looking to get out of that driv with any data I could > > not easily replace. If it was well backed up or easily replaced > > my worries would be less. =20 >=20 > WD made their first series of Green disks green by aggressively turning=20 > them into sleep state. Like when few secs there was nog activity they=20 > would park the head, spin it down, and sleep the disk... > Access would need to undo the whole series of command. >=20 > This could be reset by writing in one of the disks registers. I remember= =20 > doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of=20 > startups. I still have 'm around, but only use them for things that are=20 > not valuable at all. Some have died over time, but about half of them=20 > still seem to work without much trouble. >=20 > WD used to have a .exe program to actually do this. But that did not > work on later disks. And turning things of on those disks was=20 > impossible/a lot more complex. >=20 > This type of disk worked quite a long time in my ZFS setup. Like a few=20 > years, but I turned parking of as soon as there was a lot of turmoil=20 > about this in the community. > Now I using WD reds for small ZFS systems, and WD red Pro for large=20 > private storage servers. Professional server get HGST He disks, a bit=20 > more expensive, but very little fallout. >=20 > --WjW Hello fellows. First of all, I managed it over the past week+ to replace all(!) drives wit= h new ones. I decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) inste= ad of WD RED 4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in the n= ext days. Apart from the very long resilvering time (the first drive, the Western Dig= ital WD RED 4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although cons= idered faster (7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - except,= as mentioned, the exorbitant times of recovery. A very interesting point in this story is: as you could see, the WD Caviar = Green 3TB drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour. Wh= en replacing the drives, I figured out, that one of the four drives was already a Wester= n Digital RED 3TB NAS drive, but investigating its "193 Load_Cycle_Count" revealed, that= this drive also had a unusual high reload count - see "smartctl -x" output attached. I= t seems, as you already stated, that the APM feature responsible for this isn't availab= le. The drive has been purchased Q4/2013. The HGST drives are very(!) noisy, th ehead movement induces a notable ring= ing, while the WD drive(s) are/were really silent. The power consumption of the HGST drive= s is higher. But apart from that, I'm disappointed about the fact that WD has also imple= mented this "timebomb" Load_Cycle_Count issue. Thanks a lot for your help and considerations! Kind regards, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --MP_/4F00pud+2Z/GXgo0SACKCEb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=ada3.txt smartctl 6.6 2017-11-05 r4594 [FreeBSD 12.0-CURRENT amd64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D Model Family: Western Digital Red Device Model: WDC WD30EFRX-68EUZN0 Serial Number: Seriennummer LU WWN Device Id: 5 0014ee 0ae56aef0 Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Sat Dec 23 11:59:30 2017 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled AAM feature is: Unavailable APM feature is: Unavailable Rd look-ahead is: Enabled Write cache is: Enabled DSN feature is: Unavailable ATA Security is: Disabled, NOT FROZEN [SEC1] Wt Cache Reorder: Enabled =3D=3D=3D START OF READ SMART DATA SECTION =3D=3D=3D SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine comp= leted without error or no self-test has ever=20 been run. Total time to complete Offline=20 data collection: (38760) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine=20 recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 389) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x703d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 0 3 Spin_Up_Time POS--K 171 165 021 - 6416 4 Start_Stop_Count -O--CK 099 099 000 - 1860 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 9 Power_On_Hours -O--CK 072 072 000 - 20809 10 Spin_Retry_Count -O--CK 100 100 000 - 0 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 12 Power_Cycle_Count -O--CK 099 099 000 - 1858 192 Power-Off_Retract_Count -O--CK 200 200 000 - 112 193 Load_Cycle_Count -O--CK 001 001 000 - 1974142 194 Temperature_Celsius -O---K 128 109 000 - 22 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 0 198 Offline_Uncorrectable ----CK 200 200 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 0 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning General Purpose Log Directory Version 1 SMART Log Directory Version 1 [multi-sector log support] Address Access R/W Size Description 0x00 GPL,SL R/O 1 Log Directory 0x01 SL R/O 1 Summary SMART error log 0x02 SL R/O 5 Comprehensive SMART error log 0x03 GPL R/O 6 Ext. Comprehensive SMART error log 0x06 SL R/O 1 SMART self-test log 0x07 GPL R/O 1 Extended self-test log 0x09 SL R/W 1 Selective self-test log 0x10 GPL R/O 1 NCQ Command Error log 0x11 GPL R/O 1 SATA Phy Event Counters log 0x21 GPL R/O 1 Write stream error log 0x22 GPL R/O 1 Read stream error log 0x80-0x9f GPL,SL R/W 16 Host vendor specific log 0xa0-0xa7 GPL,SL VS 16 Device vendor specific log 0xa8-0xb7 GPL,SL VS 1 Device vendor specific log 0xbd GPL,SL VS 1 Device vendor specific log 0xc0 GPL,SL VS 1 Device vendor specific log 0xc1 GPL VS 93 Device vendor specific log 0xe0 GPL,SL R/W 1 SCT Command/Status 0xe1 GPL,SL R/W 1 SCT Data Transfer SMART Extended Comprehensive Error Log Version: 1 (6 sectors) Device Error Count: 7 CR =3D Command Register FEATR =3D Features Register COUNT =3D Count (was: Sector Count) Register LBA_48 =3D Upper bytes of LBA High/Mid/Low Registers ] ATA-8 LH =3D LBA High (was: Cylinder High) Register ] LBA LM =3D LBA Mid (was: Cylinder Low) Register ] Register LL =3D LBA Low (was: Sector Number) Register ] DV =3D Device (was: Device/Head) Register DC =3D Device Control Register ER =3D Error register ST =3D Status register Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=3Ddays, hh=3Dhours, mm=3Dminutes, SS=3Dsec, and sss=3Dmillisec. It "wraps" after 49.710 days. Error 7 [6] occurred at disk power-on lifetime: 16151 hours (672 days + 23 = hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 00 98 01 cd d0 40 00 Error: IDNF at LBA =3D 0x9801cdd0= =3D 2550255056 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 50 00 00 98 01 cd d0 40 08 00:12:14.943 WRITE FPDMA QUEU= ED ea 00 00 00 00 00 00 00 00 00 00 40 08 00:12:05.025 FLUSH CACHE EXT 61 00 08 00 40 00 01 5d 50 9f a0 40 08 00:12:05.024 WRITE FPDMA QUEU= ED 61 00 08 00 38 00 01 5d 50 9d a0 40 08 00:12:05.024 WRITE FPDMA QUEU= ED 61 00 08 00 30 00 00 00 00 13 a0 40 08 00:12:05.024 WRITE FPDMA QUEU= ED Error 6 [5] occurred at disk power-on lifetime: 10875 hours (453 days + 3 h= ours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 01 30 01 ce 78 40 00 Error: IDNF at LBA =3D 0x13001ce7= 8 =3D 5100392056 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 b0 00 01 30 01 ce 78 40 08 04:06:34.288 WRITE FPDMA QUEU= ED ea 00 00 00 00 00 00 00 00 00 00 40 08 04:06:24.234 FLUSH CACHE EXT 61 00 08 00 a0 00 01 5d 50 9f 30 40 08 04:06:24.234 WRITE FPDMA QUEU= ED 61 00 08 00 98 00 01 5d 50 9d 30 40 08 04:06:24.234 WRITE FPDMA QUEU= ED 61 00 08 00 90 00 00 00 00 13 30 40 08 04:06:24.233 WRITE FPDMA QUEU= ED Error 5 [4] occurred at disk power-on lifetime: 8417 hours (350 days + 17 h= ours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 00 c4 06 ba 08 40 00 Error: IDNF at LBA =3D 0xc406ba08= =3D 3288775176 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 a8 00 00 c4 06 ba 08 40 08 00:45:57.190 WRITE FPDMA QUEU= ED ea 00 00 00 00 00 00 00 00 00 00 40 08 00:45:47.264 FLUSH CACHE EXT 61 00 08 00 98 00 01 5d 50 9f b0 40 08 00:45:47.263 WRITE FPDMA QUEU= ED 61 00 08 00 90 00 01 5d 50 9d b0 40 08 00:45:47.263 WRITE FPDMA QUEU= ED 61 00 08 00 88 00 00 00 00 13 b0 40 08 00:45:47.263 WRITE FPDMA QUEU= ED Error 4 [3] occurred at disk power-on lifetime: 3423 hours (142 days + 15 h= ours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 00 b2 59 f6 a8 40 00 Error: IDNF at LBA =3D 0xb259f6a8= =3D 2992240296 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 f8 00 00 b2 59 f6 a8 40 08 12:09:22.415 WRITE FPDMA QUEU= ED ea 00 00 00 00 00 00 00 00 00 00 40 08 12:09:13.160 FLUSH CACHE EXT 61 00 08 00 f8 00 01 5d 50 9f 90 40 08 12:09:13.159 WRITE FPDMA QUEU= ED 61 00 08 00 f0 00 01 5d 50 9d 90 40 08 12:09:13.159 WRITE FPDMA QUEU= ED 61 00 08 00 e8 00 00 00 00 13 90 40 08 12:09:13.159 WRITE FPDMA QUEU= ED Error 3 [2] occurred at disk power-on lifetime: 2928 hours (122 days + 0 ho= urs) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 00 c0 05 10 20 40 00 Error: IDNF at LBA =3D 0xc0051020= =3D 3221557280 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 00 00 00 c0 05 10 20 40 08 09:36:05.067 WRITE FPDMA QUEU= ED 61 00 08 00 00 00 01 5d 50 9f f0 40 08 09:35:50.674 WRITE FPDMA QUEU= ED 61 00 08 00 f8 00 01 5d 50 9d f0 40 08 09:35:50.674 WRITE FPDMA QUEU= ED 61 00 08 00 f0 00 00 00 00 13 f0 40 08 09:35:50.674 WRITE FPDMA QUEU= ED 61 00 08 00 e8 00 00 00 00 11 f0 40 08 09:35:50.674 WRITE FPDMA QUEU= ED Error 2 [1] occurred at disk power-on lifetime: 1989 hours (82 days + 21 ho= urs) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 00 ae 07 ce 30 40 00 Error: IDNF at LBA =3D 0xae07ce30= =3D 2919747120 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 78 00 00 ae 07 ce 30 40 08 04:16:19.349 WRITE FPDMA QUEU= ED 61 00 08 00 78 00 01 5d 50 9f 98 40 08 04:16:05.011 WRITE FPDMA QUEU= ED 61 00 08 00 70 00 01 5d 50 9d 98 40 08 04:16:05.011 WRITE FPDMA QUEU= ED 61 00 08 00 68 00 00 00 00 13 98 40 08 04:16:05.011 WRITE FPDMA QUEU= ED 61 00 08 00 60 00 00 00 00 11 98 40 08 04:16:05.011 WRITE FPDMA QUEU= ED Error 1 [0] occurred at disk power-on lifetime: 1764 hours (73 days + 12 ho= urs) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 10 -- 51 00 00 00 00 aa 1a 86 e8 40 00 Error: IDNF at LBA =3D 0xaa1a86e8= =3D 2853865192 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 61 00 08 00 d0 00 00 aa 1a 86 e8 40 08 12:13:30.211 WRITE FPDMA QUEU= ED 61 00 08 00 d0 00 01 5d 50 9f 30 40 08 12:13:20.248 WRITE FPDMA QUEU= ED 61 00 08 00 c8 00 01 5d 50 9d 30 40 08 12:13:20.248 WRITE FPDMA QUEU= ED 61 00 08 00 c0 00 00 00 00 13 30 40 08 12:13:20.248 WRITE FPDMA QUEU= ED 61 00 08 00 b8 00 00 00 00 11 30 40 08 12:13:20.248 WRITE FPDMA QUEU= ED SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours)= LBA_of_first_error # 1 Short offline Completed without error 00% 18023 = - # 2 Short offline Completed without error 00% 2620 = - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. SCT Status Version: 3 SCT Version (vendor specific): 258 (0x0102) SCT Support Level: 1 Device State: Active (0) Current Temperature: 22 Celsius Power Cycle Min/Max Temperature: 22/22 Celsius Lifetime Min/Max Temperature: 11/41 Celsius Under/Over Temperature Limit Count: 0/0 Vendor specific: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SCT Temperature History Version: 2 Temperature Sampling Period: 1 minute Temperature Logging Interval: 1 minute Min/Max recommended Temperature: 0/60 Celsius Min/Max Temperature Limit: -41/85 Celsius Temperature History Size (Index): 478 (301) Index Estimated Time Temperature Celsius 302 2017-12-23 04:01 22 *** ... ..( 92 skipped). .. *** 395 2017-12-23 05:34 22 *** 396 2017-12-23 05:35 21 ** ... ..( 93 skipped). .. ** 12 2017-12-23 07:09 21 ** 13 2017-12-23 07:10 22 *** ... ..( 92 skipped). .. *** 106 2017-12-23 08:43 22 *** 107 2017-12-23 08:44 ? - 108 2017-12-23 08:45 21 ** ... ..( 29 skipped). .. ** 138 2017-12-23 09:15 21 ** 139 2017-12-23 09:16 22 *** ... ..( 21 skipped). .. *** 161 2017-12-23 09:38 22 *** 162 2017-12-23 09:39 ? - 163 2017-12-23 09:40 15 - 164 2017-12-23 09:41 15 - 165 2017-12-23 09:42 16 - 166 2017-12-23 09:43 16 - 167 2017-12-23 09:44 17 - ... ..( 5 skipped). .. - 173 2017-12-23 09:50 17 - 174 2017-12-23 09:51 18 - ... ..( 9 skipped). .. - 184 2017-12-23 10:01 18 - 185 2017-12-23 10:02 19 - ... ..( 7 skipped). .. - 193 2017-12-23 10:10 19 - 194 2017-12-23 10:11 20 * ... ..( 13 skipped). .. * 208 2017-12-23 10:25 20 * 209 2017-12-23 10:26 21 ** ... ..( 50 skipped). .. ** 260 2017-12-23 11:17 21 ** 261 2017-12-23 11:18 ? - 262 2017-12-23 11:19 13 - 263 2017-12-23 11:20 13 - 264 2017-12-23 11:21 14 - ... ..( 2 skipped). .. - 267 2017-12-23 11:24 14 - 268 2017-12-23 11:25 15 - 269 2017-12-23 11:26 15 - 270 2017-12-23 11:27 16 - 271 2017-12-23 11:28 16 - 272 2017-12-23 11:29 17 - ... ..( 4 skipped). .. - 277 2017-12-23 11:34 17 - 278 2017-12-23 11:35 18 - 279 2017-12-23 11:36 ? - 280 2017-12-23 11:37 22 *** ... ..( 20 skipped). .. *** 301 2017-12-23 11:58 22 *** SCT Error Recovery Control: Read: 70 (7.0 seconds) Write: 70 (7.0 seconds) Device Statistics (GP/SMART Log 0x04) not supported Pending Defects log (GP Log 0x0c) not supported SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x0001 2 0 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 1 Transition from drive PhyRdy to drive PhyNRdy 0x000a 2 1 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x8000 4 911 Vendor specific --MP_/4F00pud+2Z/GXgo0SACKCEb-- --Sig_/mdXl02WhP_PB/BOqOogssmV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWj49UAAKCRDS528fyFhY lFXHAf4iBVK6BUfo1fH//mGlWP5OpL6cSFmFPT00k+3uPWqR/PU2BRrCTalDXFRx rVO0b7UNBt6tBLBylvTBtcfjCx75Af4l/rTR42dmRiyGUXWf55Y+jiX52PfrhRBL 44zSdBOAk44ejHU8MUV84SI6TYDcI22Di/yf4hhReLZRkV4iP/ia =WeZR -----END PGP SIGNATURE----- --Sig_/mdXl02WhP_PB/BOqOogssmV-- From owner-freebsd-current@freebsd.org Sat Dec 23 12:29:25 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 E2499EA4A73 for ; Sat, 23 Dec 2017 12:29:25 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id B9C2C1ECC for ; Sat, 23 Dec 2017 12:29:25 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 3B9E527386 for ; Sat, 23 Dec 2017 07:29:20 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 71C03127EBC for ; Sat, 23 Dec 2017 06:29:18 -0600 (CST) Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error To: freebsd-current@freebsd.org References: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> <4d58b06a-0dbe-af05-1bd2-e87929e3b7a5@digiware.nl> <20171223122608.4ea4f097@thor.intern.walstatt.dynvpn.de> From: Karl Denninger Message-ID: Date: Sat, 23 Dec 2017 06:29:15 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171223122608.4ea4f097@thor.intern.walstatt.dynvpn.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040402010205050904010300" 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: Sat, 23 Dec 2017 12:29:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040402010205050904010300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/2017 05:25, O. Hartmann wrote: > Am Thu, 14 Dec 2017 12:05:20 +0100 > Willem Jan Withagen schrieb: > >> On 13/12/2017 17:47, Rodney W. Grimes wrote: >>>> On Tue, 12 Dec 2017 14:58:28 -0800 >>>> Cy Schubert wrote: >>>> I think people responding to my thread made it clear that the WD Gre= en >>>> isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and= >>>> the fact, that they have serviced now more than 25000 hours, it woul= d >>>> be wise to replace them with alternatives. =20 >>> I think someone had an apm command that turns off the head park, >>> that would do wonders for drive life. On the other hand, I think >>> if it was my data and I saw that the drive had 2M head load cycles >>> I would be looking to get out of that driv with any data I could >>> not easily replace. If it was well backed up or easily replaced >>> my worries would be less. =20 >> WD made their first series of Green disks green by aggressively turnin= g=20 >> them into sleep state. Like when few secs there was nog activity they = >> would park the head, spin it down, and sleep the disk... >> Access would need to undo the whole series of command. >> >> This could be reset by writing in one of the disks registers. I rememb= er=20 >> doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of=20 >> startups. I still have 'm around, but only use them for things that ar= e=20 >> not valuable at all. Some have died over time, but about half of them = >> still seem to work without much trouble. >> >> WD used to have a .exe program to actually do this. But that did not >> work on later disks. And turning things of on those disks was=20 >> impossible/a lot more complex. >> >> This type of disk worked quite a long time in my ZFS setup. Like a few= =20 >> years, but I turned parking of as soon as there was a lot of turmoil=20 >> about this in the community. >> Now I using WD reds for small ZFS systems, and WD red Pro for large=20 >> private storage servers. Professional server get HGST He disks, a bit = >> more expensive, but very little fallout. >> >> --WjW > Hello fellows. > > First of all, I managed it over the past week+ to replace all(!) drives= with new ones. I > decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) i= nstead of WD RED > 4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in t= he next days. > > Apart from the very long resilvering time (the first drive, the Western= Digital WD RED > 4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although = considered faster > (7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - exc= ept, as mentioned, > the exorbitant times of recovery. > > A very interesting point in this story is: as you could see, the WD Cav= iar Green 3TB > drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour= =2E When replacing > the drives, I figured out, that one of the four drives was already a We= stern Digital RED > 3TB NAS drive, but investigating its "193 Load_Cycle_Count" revealed, = that this drive > also had a unusual high reload count - see "smartctl -x" output attache= d. It seems, as > you already stated, that the APM feature responsible for this isn't ava= ilable. The drive > has been purchased Q4/2013. > > The HGST drives are very(!) noisy, th ehead movement induces a notable = ringing, while the > WD drive(s) are/were really silent. The power consumption of the HGST d= rives is higher. > But apart from that, I'm disappointed about the fact that WD has also i= mplemented this > "timebomb" Load_Cycle_Count issue. > > Thanks a lot for your help and considerations! > > Kind regards, > Oliver I have a fairly large number of HGST "NAS" drives in service across multiple locations (several dozens units total.)=C2=A0 I don't like their= 5Tb models much (they're slow comparatively for an unknown reason) but the 4Tb and 6Tb models I have in the field, while noisy and somewhat more power-hungry (the latter comes from the 7200 rpm speed) have yet to suffer a failure. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040402010205050904010300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjIzMTIyOTE1 WjBPBgkqhkiG9w0BCQQxQgRAd16W/qLGQSZfNfO0pvlVajM8ixp1OAynE4WMt0Mc4CsTILyj JN/xkb6dEUn76Al8HuRYVer5ewTEOBNmNmqa5zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBNq/M3NuFJ83UNDfulZDtq+gc0VF1fKH81FXwSbdBRk4x70Mzz078KVq0gKyBia0x9 3kRfCyX+3CA6DASr6Lv+ZSZo70o8WHFwohO3A5w4eycgQUFSnBxguF4ZuO8oyAY6hRUlwQw5 wc836xO9w7mplrVNs8xhnqNcCY25bgKb/scCJ1w3lrD3dtsdxqjh1Gwmu62pp35bIsXCgksN ykVaV29bTQoXAaU0mhuJ6HZmhGnWizOJ3ShTGxDJPaO/AMQXMTXZIRYPgtC3FaPRRUZDl1jF Qt5x7BwS+KH47SYAXhvaDys9Jq6HKG9sH86zKTGdxCqSrkYM10wX+gWWE2ThRzuUJGWdDVEO G3mKyDE+fW1XqqelsSlOvUdXmo4n4ESiGKfWgDiB/b2ghgIxXiX3SI25M+hQwqejTYF1wwkZ fQDKwXo0eQ5ra/ukxYKRJ9B0IjaSYqBgOpTAuiwTEuSIZLcXk9XCjc/8MeK9EsVJwONm6c+t Ug0+uJI5kB9q1BEuDKk+EWeZzilVN94q/G7P3mapmc2Vhwn+k9B9EHkSPuUF3b0D+QS15vto 6BhQUDOn3t/6XvJF8N14sz2IwHT3Tu7wLqfJ1OWczBeLim1BhebENrtcwQ2wFsy5x6rg7lBw sf/a0hwjbmtg9YxG5aWIZ9pOY0ev8N5AHrZ6HXbmGAAAAAAAAA== --------------ms040402010205050904010300-- From owner-freebsd-current@freebsd.org Sat Dec 23 12:42:50 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 65F96EA4F36 for ; Sat, 23 Dec 2017 12:42:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C5AA2890 for ; Sat, 23 Dec 2017 12:42:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1280510B4D; Sat, 23 Dec 2017 13:42:41 +0100 (CET) From: Dimitry Andric Message-Id: <962D6B67-8D38-4483-B8D3-933FA483C364@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DDCC5B33-4547-4515-B30A-CD363706BC5C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unable to build 12-current/amd64 Date: Sat, 23 Dec 2017 13:42:40 +0100 In-Reply-To: <20171223095633.GA52398@server.rulingia.com> Cc: freebsd-current@FreeBSD.org To: Peter Jeremy References: <20171223095633.GA52398@server.rulingia.com> 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: Sat, 23 Dec 2017 12:42:50 -0000 --Apple-Mail=_DDCC5B33-4547-4515-B30A-CD363706BC5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Dec 2017, at 10:56, Peter Jeremy wrote: >=20 > Since r326496, buildworld on my 12-current/amd64 system has = consistently > died as follows. ... > /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: = fatal error: 'emmintrin.h' file not found > #include > ^~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/src/lib/clang/libclang >=20 > I'm building on a 12.0-CURRENT VirtualBox guest at r326430. I've = checked > that my /usr/src is clean and deleted /usr/obj to no effect. I have = dug > into SourceManager.cpp and the #include is protected by a #if = __SSE2__, > which is relying on clang internal checks to define (and my CPU = supports > SSE2). Does anyone have any ideas to explain what is going on? First of all, does your host system have emmintrin.h? E.g. what is the output of "find /usr/lib/clang -name emmintrin.h" ? Second, I think this scenario might be possible if you force -march or other CPU type flags into CFLAGS, instead of using CPUTYPE. What is the contents of your make.conf, and other build environment variables? -Dimitry --Apple-Mail=_DDCC5B33-4547-4515-B30A-CD363706BC5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWj5PQAAKCRCwXqMKLiCW oxRyAKCiP0ouoCHXmY3YebYv1Cs7miJmIgCgsB4PPI+FmPoCl87k8ezV+DT2w9Q= =R+Nv -----END PGP SIGNATURE----- --Apple-Mail=_DDCC5B33-4547-4515-B30A-CD363706BC5C-- From owner-freebsd-current@freebsd.org Sat Dec 23 22:49:15 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 9A310EA786F for ; Sat, 23 Dec 2017 22:49:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-118.reflexion.net [208.70.210.118]) (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 571E079891 for ; Sat, 23 Dec 2017 22:49:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9868 invoked from network); 23 Dec 2017 22:49:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 23 Dec 2017 22:49:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 23 Dec 2017 17:49:13 -0500 (EST) Received: (qmail 14159 invoked from network); 23 Dec 2017 22:49:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Dec 2017 22:49:12 -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 348B2EC8171; Sat, 23 Dec 2017 14:49:12 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: UEFI booting survey [and compared ubldr.bin booting behavior] Date: Sat, 23 Dec 2017 14:49:11 -0800 References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> <2822699E-DDD5-4604-8567-974AE30659A3@dsl-only.net> <6EFC9D27-02B8-4441-9B9B-E380EFECED78@dsl-only.net> To: Warner Losh , FreeBSD Current , freebsd-arm@freebsd.org In-Reply-To: <6EFC9D27-02B8-4441-9B9B-E380EFECED78@dsl-only.net> Message-Id: <6F3E827F-CACD-4117-80DA-BC9A59604760@dsl-only.net> 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: Sat, 23 Dec 2017 22:49:15 -0000 [Just adding notes about what ubldr.bin does with and without loaderdev being specified (correctly). Overall it does not appear to me that the ubldr.bin based contexts can fully avoid the "systems with multiple partitions that might be right" issue.] On 2017-Dec-20, at 2:47 AM, Mark Millard wrote: > On 2017-Dec-19, at 9:10 PM, Warner Losh wrote: >=20 >> 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.] >>=20 >> On 2017-Dec-19, at 7:26 PM, Warner Losh wrote: >>=20 >>> 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 >>>>> /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. >>>=20 >>> No: There are no kernel files on the usdcard. See the complete >>> file list of its only UFS partition above. No dtb files either. >>>=20 >>> [On a rpi2 ubldr.bin is copied to the msdosfs, where it >>> is actually put to use.] >>=20 >> OK. Looks like the uboot code has the same bogus 'let's search = everything' code that I'm removing from the UEFI case. >=20 > Could be. My case was so limited that it does not show if > the search would continue if multiple USB drives were > present vs. stopping at the first even if the files would > not be found there (for example). >=20 >> 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. >=20 > Just FYI, the /usr/src/stand/common/boot.c comments say about > the /etc/fstab use: >=20 > * Try to find the /etc/fstab file on the filesystem (rootdev), > * which should be be the root filesystem, and parse it to find > * out what the kernel ought to think the root filesystem is. > * > * If we're successful, set vfs.root.mountfrom to : > * so that the kernel can tell both which VFS and which node to use > * to mount the device. If this variable's already set, don't > * overwrite it. > . . . > /* Build the : and save it in = vfs.root.mountfrom */ >=20 > This would fit with your description: finding any > kernel, as you have described, and then feeding it > the : text to find other things. >=20 > [I have not yet identified the code that goes looking > around for the first /boot/kernel/kernel that it > can find that appears to be some form of kernel.] >=20 >>>> /etc/fstab on the card points to the usb drive for /. >>>=20 >>> True. And that is were the kernel and dtb come from, >>> not the usdcard. >>=20 >> Right, but that's not how ubldr finds them. >=20 > If the kernel loads the dtb file, it might use the > : that it was given to find > /boot/dtb/ to look up the dtb file? >=20 > (That would still leave an arbitrary kernel being > loaded first if more than one is around.) >=20 >>> For reference loader.config has: >>>=20 >>> # 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" >>>=20 >>> (So no vfs.root.mountfrom .) >>=20 >> What does config.txt have? >=20 > The rpi2 CONFIG.TXT on the msdosfs has: >=20 > # more /media/CONFIG.TXT > init_uart_clock=3D3000000 > enable_uart=3D1 > kernel=3Du-boot.bin > kernel7=3Du-boot.bin >=20 > (Unchanged by me: simply copied over from > the sysutils materials for the rpi2.) >=20 >>>> This is all standard loader behavior. >>>=20 >>> 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. >=20 > Looks like not-desired in its current form. >=20 >>>> It won't change. In your case, you aren't even using UEFI, so it = doubly won't change. >>>=20 >>> 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 . >>>=20 >>> 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. >>=20 >> You should try, but you may need one additional line to explicitly = declare things. >>=20 >>>> 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... >>>=20 >>> The lack of depending on the "random order" status may well >>> be true. >>>=20 >>> 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. >=20 > [That last rpi2 should have been a rpi3.] >=20 >> 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. >=20 >> But as someone that deploys systems with multiple partitions that = might be right, I hate random :( >=20 > Understandable. >=20 >> Warner >=20 > Thanks much. I understand a bit more now. >=20 >>> Warner >>>>=20 >>>>>> (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 >>>=20 Looking at the ubldr.bin code it appears that the only way to avoid the ubldr.bin "find first in some order" is to have set loaderdev to indicate where to get the loader scripts and kernel from. Otherwise it will do the general probing, for example: . . . FreeBSD/armv7 U-Boot loader, Revision 1.2 DRAM: 948MB Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0p1: . . . Matches up with: . . . device_types[] =3D { { "disk", DEV_TYP_STOR }, { "ide", DEV_TYP_STOR | DT_STOR_IDE }, { "mmc", DEV_TYP_STOR | DT_STOR_MMC }, { "sata", DEV_TYP_STOR | DT_STOR_SATA }, { "scsi", DEV_TYP_STOR | DT_STOR_SCSI }, { "usb", DEV_TYP_STOR | DT_STOR_USB }, { "net", DEV_TYP_NET } }; . . . /* * Parse a device string into type, unit, slice and partition numbers. A * returned value of -1 for type indicates a search should be done for = the * first loadable device, otherwise a returned value of -1 for unit * indicates a search should be done for the first loadable device of = the * given type. * =20 * The returned values for slice and partition are interpreted by * disk_open(). =20 * * Valid device strings: For device types: * * DEV_TYP_STOR, DEV_TYP_NET * DEV_TYP_STOR, DEV_TYP_NET * : DEV_TYP_STOR, DEV_TYP_NET * : DEV_TYP_STOR * :. DEV_TYP_STOR * :. DEV_TYP_STOR * * For valid type names, see the device_types array, above. * =20 * Slice numbers are 1-based. 0 is a wildcard. */ =20 static void get_load_device(int *type, int *unit, int *slice, int *partition) { char *devstr; const char *p; char *endp; =20 *type =3D -1; *unit =3D -1; *slice =3D 0; *partition =3D -1; =20 devstr =3D ub_env_get("loaderdev"); if (devstr =3D=3D NULL) { printf("U-Boot env: loaderdev not set, will probe all = devices.\n"); return; } printf("U-Boot env: loaderdev=3D'%s'\n", devstr); . . . It appears that loaderdev's notation depends on the : having a stable interpretation if it is to avoid picking different things based on what combination of other devices happen to be plugged in at the time. Stablility require binding, say, a unit 0 to a specific place even when the place was not populated. (Unlikely?) This suggests that notation is specific to each device type. But I'm not aware of a place to go look up a device type and get a definition for how will be bound to plugged in devices. It is not clear to me what happens with in the notation when the : identifies something with just, say, gpt partitioning. (No slice layer.) Listing 0 (the slice wildcard) could match a device with some non-gpt structure. An explicit, say, 1 could as well but would also have no slice to refer to for gpt partitioning. Overall it does not appear to me that the ubldr.bin based contexts can fully avoid the "systems with multiple partitions that might be right" issue when what is connected can change from boot to boot: There just is not the right kind of context for avoiding the issue. Still an explicit loaderdev use in some styles of usage could make mismatches less likely. =3D=3D=3D Mark Millard markmi at dsl-only.net