Re: Mount Root fails: r347007

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Fri, 3 May 2019 20:08:24 +0900
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