From owner-freebsd-current@freebsd.org Fri May 3 11:40:53 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40F83158CDC8 for ; Fri, 3 May 2019 11:40:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 49E816D18A; Fri, 3 May 2019 11:40:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-96-116.dz.commufa.jp [124.18.96.116]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id x43B8PZv089986; Fri, 3 May 2019 20:08:25 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 3 May 2019 20:08:24 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: kevans@freebsd.org, ler@lerctr.org, imp@bsdimp.com Subject: Re: Mount Root fails: r347007 Message-Id: <20190503200824.45314daf9f9d0e21b169e0e7@dec.sakura.ne.jp> In-Reply-To: References: <20190502040229.ysm45il3n2mdsfg6@ler-imac.local> <33e20e5367966cb4f5c2856f3eda192f@lerctr.org> <4419741bbbc2fafe9efde97fb5bf6d8b@lerctr.org> <6fd7b2d4dcbbbe07a2e9639e3657906d@lerctr.org> <5084541f31224d3fb91796f0b4096bb7@lerctr.org> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49E816D18A X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; MX_GOOD(-0.01)[dec.sakura.ne.jp]; RECEIVED_SPAMHAUS_PBL(0.00)[116.96.18.124.zen.spamhaus.org : 127.0.0.10]; IP_SCORE(0.43)[ipnet: 210.188.224.0/19(0.72), asn: 9370(1.49), country: JP(-0.06)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.75)[0.752,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.997,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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, 03 May 2019 11:40:53 -0000 Thanks! I'd just been preparing for PR. ;-) Some additional notes: *The reason stoppes booting would be different. The last screen seen was like below. === Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk1p5: FreeBSD/amd64 EFI loader, Revision 1.1 Command line arguments: loader.efi EFI version: 2.00 EFI Firmware: Lenovo (rev 0.4960) Console: efi (0) Load Path: HD(5,GPT,6D6A5FEB-6370-11E5-8AD1-0021CC6F1820,0x1E6 ) Load Device: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(5 370-11E5-8AD1-0021CC6F1820,0x1E65000,0x75558000) BootCurrent: 000b BootOrder: 0006 0007 0008 0009 000a 000b[*] 000c 000d 000e 000 2 0013 BootInfo path: BootOptionProtocol(5962AF91-4456-419F-A7B9-1F4F 00) Ignoring Boot000b: Only one DP found Trying ZFS pool Setting currdev to zfs:(valid pool/dataset shown here) Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local _ === My ThinkPad T420 hangs just after showing above screen. (pool name and dataset name is rewritten. ;-)) After applying same fix with committed patch, I could confirm OK if loader.efi is kicked by bootx64.efi (renamed boot1.efi). Both stock and patched (with latest ugly-hacked BUG 207940 [1]) ones were confirmed OK. *Once loader.efi (even if fixed one) is copied to (ESP-root)/efi/boot/bootx64.efi, it forcibly looks for loader.efi.lua from UFS (ada0p4) before ZFS pool (ada0p5) and boot fails. (Screenshot is not taken, but drops to mountroot: prompt. Different as fixed problem, but maybe like Larry was hit.) The UFS partition was used for test and emergency purpose when I was testing current boot1.efi, and intentionally kept stable/11 to detect situations like this (with boot failure). This means loader.efi is currently NOT a reasonable replacement for boot1.efi. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 One more additional notes: ada0 is used for stable/12 as regular use. ada1 is currently used to try -head. Regards. On Thu, 2 May 2019 13:20:09 -0500 Kyle Evans wrote: > On Thu, May 2, 2019 at 11:42 AM Kyle Evans wrote: > > > > On Thu, May 2, 2019 at 11:40 AM Larry Rosenman wrote: > > > > > > On 05/02/2019 11:34 am, Larry Rosenman wrote: > > > > On 05/02/2019 11:10 am, Larry Rosenman wrote: > > > >> On 05/02/2019 10:58 am, Warner Losh wrote: > > > >>> On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: > > > >>> > > > >>>> On 05/02/2019 9:41 am, Larry Rosenman wrote: > > > >>>> > On 05/02/2019 9:24 am, Warner Losh wrote: > > > >>>> >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: > > > >>>> >> > > > >>>> >>> On 05/02/2019 8:29 am, Warner Losh wrote: > > > >>>> >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman > > > >>>> wrote: > > > >>>> >>> > > > > >>>> >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a > > > >>>> mountroot > > > >>>> >>> >> prompt. If I answer it with the same BootFS I booted from > > > >>>> >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. > > > >>>> >>> >> > > > >>>> >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt > > > >>>> >>> >> > > > >>>> >>> >> What else do we need? > > > >>>> >>> >> > > > >>>> >>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions > > > >>>> >>> >> and that did *NOT* change anything. > > > >>>> >>> >> > > > >>>> >>> >> Ideas? > > > >>>> >>> >> > > > >>>> >>> > > > > >>>> >>> > BIOS or UEFI booting? > > > >>>> >>> > > > >>>> >>> UEFI boot. > > > >>>> >>> > > > >>>> >> > > > >>>> >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? > > > >>>> >> > > > >>>> >> Can you get the output of 'show' in the boot loader? > > > >>>> >> > > > >>>> >> Also, is there a way you can try one or two of the versions in between > > > >>>> >> 346487 and 347007 to try to narrow the changes down a bit? > > > >>>> >> > > > >>>> >> Warner > > > >>>> > > > > >>>> > show output in 4 screenshots: > > > >>>> > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > > >>>> > > > > >>>> > What's the easiest way to try some of the other revisions? And which > > > >>>> > would > > > >>>> > you suggest? (I'm set up for meta-mode). > > > >>>> working with Kyle Evans on IRC, and backing /boot/loader.efi to > > > >>>> r346487 > > > >>>> lets the system boot > > > >>>> normally. > > > >>>> > > > >>> > > > >>> OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set > > > >>> in > > > >>> your successfully booted system with kenv? > > > >>> > > > >> > > > >> 2 things: r346675 still works, and vfs.root.mountfrom *IS* set. > > > > r346879 does *NOT* work. Stepping back to r346759 > > > r346759 *WORKS*. So it's r346879 that breaks it. > > > > > > > Hi, > > > > Head back to -head and try applying [0] -- this block was accidentally > > reintroduced, and I wouldn't be surprised if the double-initialization > > has some weird side effect. > > > > [0] https://people.freebsd.org/~kevans/loader.diff > > To round things off: this patch was confirmed working and committed as r347023. > _______________________________________________ > 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" -- Tomoaki AOKI