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 <kevans_at_freebsd.org> wrote: > On Thu, May 2, 2019 at 11:42 AM Kyle Evans <kevans_at_freebsd.org> wrote: > > > > On Thu, May 2, 2019 at 11:40 AM Larry Rosenman <ler_at_lerctr.org> 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 <ler_at_lerctr.org> 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 <ler_at_lerctr.org> wrote: > > > >>>> >> > > > >>>> >>> On 05/02/2019 8:29 am, Warner Losh wrote: > > > >>>> >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman <ler_at_lerctr.org> > > > >>>> 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_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" -- Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>Received on Fri May 03 2019 - 09:40:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC