Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Oct 2018 10:19:32 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Toomas Soome <tsoome@me.com>
Cc:        Harry Newton <hn@yewbarrow.net>, FreeBSD Current <freebsd-current@freebsd.org>,  Kyle Evans <kevans@freebsd.org>
Subject:   Re: UEFI boot hangs after loader
Message-ID:  <CANCZdfo_FEwpMVBZL4Nfs6r=1=fLccpU43QuO3H7yPyDYZ8A6w@mail.gmail.com>
In-Reply-To: <3A48C6FA-805E-4B36-8C7D-A98422EBC7A5@me.com>
References:  <CAKAm69Fw%2BX3Xik6rUcEOrr0TtxypEc2D05%2B5g9JGh=N2VxZGpA@mail.gmail.com> <282E6F72-6573-4F0E-81AB-25110855EBB7@me.com> <CAKAm69EMraV0KaPEbsxTcEpwFjpNZtW-sc42mmSq=9vv%2BiyGzQ@mail.gmail.com> <2950121D-C985-4F2E-A512-FB73CFDF48BC@me.com> <CAKAm69Gd1yq0Lss2nByjkkfiTPCAW6wvaKPF8LVqbw%2BvbEnxUQ@mail.gmail.com> <4457A5DC-A577-4782-B1E8-306236908D5D@me.com> <CAKAm69EF98FZnh0KHkArPGX=_7OZT369kQr3J5YigE-0mOsgqA@mail.gmail.com> <B5749B46-02E5-4B48-858B-EE2743281154@me.com> <CAKAm69HrTh%2BibMi8GHV9CpUa2=2jsof2AXk5LeOE0TwRxTWc3w@mail.gmail.com> <CAKAm69FEOCWwEPr3ZLVOYHuVyZYNACbXhzhwH_4VgC0DV9B7jw@mail.gmail.com> <CACNAnaGrk9tN0Pg0HeODRuSnqGCaSZSBQtvV6JscVh%2B7hBCN%2BQ@mail.gmail.com> <3A48C6FA-805E-4B36-8C7D-A98422EBC7A5@me.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 24, 2018 at 9:36 AM Toomas Soome <tsoome@me.com> wrote:

>
>
> > On 24 Oct 2018, at 00:51, Kyle Evans <kevans@freebsd.org> wrote:
> >
> > Hi,
> >
> > I suspect 4th vs. lua has no impact here, given the output shown --
> > can you throw one of the installer images [0] on some removable media
> > and give that a shot for booting? If that works, we can explore UEFI
> > variables from there.
> >
>
>
> Yes, thats my guess too, my guess is that since in general the uefi boot
> is working, in this case it has to be some corner case, and I would start
> checking with boot variable related code; specifically, I=E2=80=99d sugge=
st to
> patch (temporarily) the find_currdev() in efi/loader/main.c to set
> do_bootmgr =3D false and see if that will fix the boot. Then we can explo=
re
> what is happening in match_boot_info()
>

I think there's a BootXXXX variable that we're poking our nose into and
falling into cloud-koo-koo land. That's really the only substantial bit of
free-form data that we're touching, and so it's the biggest risk. There's
also a piece of data in efibootmgr -v hanging... There's a lot of sanity
checking in the code, but we'll likely find there's one missing.

Warner


> rgds,
> toomas
>
> > efibootmgr will only work on a successful UEFI boot, unfortunately- if
> > we didn't make uefi loader -> kernel transition, then we don't have
> > access to runtime services.
> >
> > Thanks,
> >
> > Kyle Evans
> >
> > [0]
> https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/
> >
> > On Tue, Oct 23, 2018 at 4:23 PM Harry Newton <hn@yewbarrow.net> wrote:
> >>
> >> I set LOADER_DEFAULT_INTERP=3D4th and went in /usr/src/stand and re-ma=
de
> the
> >> binaries in /boot but this doesn't solve the problem.  It did copy
> >> /boot/loader_4th.efi to /boot/loader.efi which is (according to uefi(8=
)
> >> which is what is called from /boot/boot1.efi and which contains the
> strings
> >> I see on the console before the hang.  But it must then call / read
> >> something else and I don't think it can find it.  Not sure why it
> doesn't
> >> produce an error message.  I *think* it may be something to do with EF=
I
> >> variables, but as efibootmgr doesn't work I can't explore this, despit=
e
> >> efirt being in the kernel.
> >>
> >> Suggestions received welcomed, and new suggestions / leads to follow
> also
> >> very much welcomed.
> >>
> >> /H
> >>
> >>
> >> On 23 October 2018 at 21:33, Harry Newton <hn@yewbarrow.net> wrote:
> >>
> >>> Right ... I've the binaries in /boot, freshly made.  This might be a
> silly
> >>> question ... do I not need to copy them (or dd the boot1.efifat image=
)
> to
> >>> the EFI partition ?
> >>>
> >>> /H
> >>>
> >>> On 23 October 2018 at 21:30, Toomas Soome <tsoome@me.com> wrote:
> >>>
> >>>> you should have the binaries in boot - just ln (or copy) one to
> loader.efi
> >>>>
> >>>> rgds,
> >>>> toomas
> >>>>
> >>>>
> >>>> On 23 Oct 2018, at 23:22, Harry Newton <hn@yewbarrow.net> wrote:
> >>>>
> >>>> Yes ... so as everything is built, can I just alter
> LOADER_DEFAULT_INTERP
> >>>> in /etc/make.conf and then reinstall just the loader and boot parts
> onto
> >>>> the UEFI partition ?  If so, how ?
> >>>>
> >>>>
> >>>> On 23 October 2018 at 21:17, Toomas Soome <tsoome@me.com> wrote:
> >>>>
> >>>>> ok, in that case I=E2=80=99d suggest to test out if forth based one=
 is still
> >>>>> working - at least you can get the bootable system. And then there
> is a
> >>>>> chance to debug the lua version too (note it should be possible to
> chain
> >>>>> /boot/loader_lua.efi).
> >>>>>
> >>>>> rgds,
> >>>>> toomas
> >>>>>
> >>>>>> On 23 Oct 2018, at 23:08, Harry Newton <hn@yewbarrow.net> wrote:
> >>>>>>
> >>>>>> So it's got FORTH in it, but my loader is lua based, and also
> doesn't
> >>>>>> appear to read loader.rc.
> >>>>>>
> >>>>>> /H
> >>>>>>
> >>>>>> On 23 October 2018 at 21:03, Toomas Soome <tsoome@me.com> wrote:
> >>>>>>
> >>>>>>> hm. in that case, whats the content of /boot/loader.rc ?
> >>>>>>>
> >>>>>>> rgds,
> >>>>>>> toomas
> >>>>>>>
> >>>>>>>
> >>>>>>> On 23 Oct 2018, at 23:01, Harry Newton <hn@yewbarrow.net> wrote:
> >>>>>>>
> >>>>>>> If boot menu is the screen where you get the options for various
> >>>>> kernels
> >>>>>>> and the picture of the daemon head, no.  It stops at the point in
> my
> >>>>> email
> >>>>>>> =E2=80=94 though not as I said just before the kernel is loaded b=
ut in
> point
> >>>>> of
> >>>>>>> fact before the menu.
> >>>>>>>
> >>>>>>> I've also rebuilt the kernel and still can't use efibootmgr which
> is
> >>>>>>> puzzling me.
> >>>>>>>
> >>>>>>> /H
> >>>>>>>
> >>>>>>>
> >>>>>>> On 23 October 2018 at 20:56, Toomas Soome <tsoome@me.com> wrote:
> >>>>>>>
> >>>>>>>> Do you get boot menu? if so, press esc to get to ok prompt, then
> type
> >>>>>>>> start - if its bootfort based loader, it will load the kernel an=
d
> >>>>> modules.
> >>>>>>>> lsmod will then list the loaded files.
> >>>>>>>>
> >>>>>>>> If the loader prompt is still usable, then next command would be=
:
> >>>>> boot
> >>>>>>>>
> >>>>>>>> rgds,
> >>>>>>>> toomas
> >>>>>>>>
> >>>>>>>>> On 23 Oct 2018, at 20:45, Harry Newton <hn@yewbarrow.net> wrote=
:
> >>>>>>>>>
> >>>>>>>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BET=
A1
> >>>>>>>> r339529
> >>>>>>>>> by source.  Have a problem with booting which hangs after:
> >>>>>>>>>
> >>>>>>>>>>> FreeBSD EFI boot block
> >>>>>>>>> Loader path: /boot/loader.efi
> >>>>>>>>>
> >>>>>>>>> Initializing modules: ZFS UFS
> >>>>>>>>> Probing 5 block devices ... done
> >>>>>>>>> ZFS found the following pools: zroot
> >>>>>>>>> UFS found no partitions
> >>>>>>>>> Consoles: EFI console
> >>>>>>>>> FreeBSD/amd64 EFI loader, Revision 1.1
> >>>>>>>>>
> >>>>>>>>>  Command line arguments: loader.efi
> >>>>>>>>>  EFI version 2.31
> >>>>>>>>>  EFI Firmware: American Megatrends (rev 4.654)
> >>>>>>>>>  Console: efi(0)
> >>>>>>>>>  Load Path: HD(4, GPT [ ... ]
> >>>>>>>>>  Load Device: Pci Root [ ... ]
> >>>>>>>>>  Boot Current: 0001
> >>>>>>>>>  Boot Order: 0001 [x]
> >>>>>>>>>  Boot Info Path: HS(1, GPT,  [ ... ]  /\EFI\BOOT\BOOTX64.EFI
> >>>>>>>>> -
> >>>>>>>>>
> >>>>>>>>> So it gets into loader.efi which runs but stops I think just
> before
> >>>>>>>> loading
> >>>>>>>>> the kernel.  Partitions:
> >>>>>>>>>
> >>>>>>>>> =3D>       40  250069600  ada0  GPT  (119G)
> >>>>>>>>>       40       1600     1  efi  (800K)
> >>>>>>>>>     1640       1024     2  freebsd-boot  (512K)
> >>>>>>>>>     2664       1432        - free -  (716K)
> >>>>>>>>>     4096    4194304     3  freebsd-swap  (2.0G)
> >>>>>>>>>  4198400  245870592     4  freebsd-zfs  (117G)
> >>>>>>>>> 250068992        648        - free -  (324K)
> >>>>>>>>>
> >>>>>>>>> and the EFI partition is FAT 12.
> >>>>>>>>>
> >>>>>>>>> I can't provide (at the moment) any output from efibootmgr:
> >>>>>>>>>
> >>>>>>>>> root@gryphon:~ # efibootmgr -v
> >>>>>>>>> efibootmgr: efi variables not supported on this system. root?
> >>>>> kldload
> >>>>>>>> efirt?
> >>>>>>>>> root@gryphon:~ # kldload efirt
> >>>>>>>>> kldload: can't load efirt: module already loaded or in kernel
> >>>>>>>>>
> >>>>>>>>> which I don't understand.
> >>>>>>>>>
> >>>>>>>>> I'm going to rebuild the kernel (currently GENERIC) and see if
> that
> >>>>>>>> allows
> >>>>>>>>> me to load efirt / use efibootmgr.
> >>>>>>>>>
> >>>>>>>>> In the meantime, I should be very grateful for any advice.
> >>>>>>>>>
> >>>>>>>>> ( Currently booting using a 11-RELEASE memstick image and
> dropping
> >>>>> into
> >>>>>>>> its
> >>>>>>>>> loader to get to the installed 12-STABLE ).
> >>>>>>>>>
> >>>>>>>>> /Harry
> >>>>>>>>> _______________________________________________
> >>>>>>>>> freebsd-current@freebsd.org mailing list
> >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>>>>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
> >>>>>>>> reebsd.org"
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Harry Newton
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Harry Newton
> >>>>>> _______________________________________________
> >>>>>> freebsd-current@freebsd.org mailing list
> >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
> >>>>> reebsd.org"
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Harry Newton
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Harry Newton
> >>>
> >>
> >>
> >>
> >> --
> >> Harry Newton
> >> _______________________________________________
> >> 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=
"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo_FEwpMVBZL4Nfs6r=1=fLccpU43QuO3H7yPyDYZ8A6w>