Re: UEFI boot hangs after loader

From: Harry Newton <hn_at_yewbarrow.net>
Date: Fri, 26 Oct 2018 22:47:19 +0100
So patching out find_currdev() in efi/loader/main.c allows the machine to
boot.  The hang occurs in the call to efi_devpath_name() in
match_boot_info() because the (last) call to ConvertDevicePathToText() call
does not return.

/H

On 24 October 2018 at 07:32, Toomas Soome <tsoome_at_me.com> wrote:

>
>
> > On 24 Oct 2018, at 00:51, Kyle Evans <kevans_at_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’d suggest to
> patch (temporarily) the find_currdev() in efi/loader/main.c to set
> do_bootmgr = false and see if that will fix the boot. Then we can explore
> what is happening in match_boot_info()
>
> 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_at_yewbarrow.net> wrote:
> >>
> >> I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and re-made
> 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 EFI
> >> variables, but as efibootmgr doesn't work I can't explore this, despite
> >> 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_at_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_at_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_at_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_at_me.com> wrote:
> >>>>
> >>>>> ok, in that case I’d 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_at_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_at_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_at_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
> >>>>>>> — though not as I said just before the kernel is loaded but 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_at_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 and
> >>>>> 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_at_yewbarrow.net> wrote:
> >>>>>>>>>
> >>>>>>>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BETA1
> >>>>>>>> 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:
> >>>>>>>>>
> >>>>>>>>> =>       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_at_gryphon:~ # efibootmgr -v
> >>>>>>>>> efibootmgr: efi variables not supported on this system. root?
> >>>>> kldload
> >>>>>>>> efirt?
> >>>>>>>>> root_at_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_at_freebsd.org mailing list
> >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>>>>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_f
> >>>>>>>> reebsd.org"
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Harry Newton
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Harry Newton
> >>>>>> _______________________________________________
> >>>>>> 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_f
> >>>>> reebsd.org"
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Harry Newton
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Harry Newton
> >>>
> >>
> >>
> >>
> >> --
> >> Harry Newton
> >> _______________________________________________
> >> 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"
>
>


-- 
Harry Newton
Received on Fri Oct 26 2018 - 19:47:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC