Re: UEFI boot hangs after loader

[Yuri Pankov]

Warner Losh wrote:
> On Sun, Oct 28, 2018, 10:39 AM Yuri Pankov  wrote:
> 
>> Jung-uk Kim wrote:
>>> On 18. 10. 24., Warner Losh wrote:
 On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:

> gryphon# efivar -N --hex $(efivar | grep Boot0002)
> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
> 00e0: 7f ff 04 00 00 00 42 4f
> gryphon#
>

 Perfect. I'll decode this and see if I can figure out where we're going
>> AFU.
>>>
>>> It looks familiar.
>>>
>>> http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa
>>
>> I have an output looking similar, but not exactly:
>>
>> : 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00
>> 0010: 4f 00 53 00 00 00 04 01 2a 00 01 00 00 00 28 00
>> 0020: 00 00 00 00 00 00 00 40 06 00 00 00 00 00 f1 84
>> 0030: d7 13 ca da e8 11 94 1d 30 85 a9 40 0a 5c 02 02
>> 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
>> 0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00
>> 0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00
>> 0070: 7f ff 04 00 aa 55 18 0f
>>
>> Same problem with ASUS P8H77-I.
>>
> 
> Do the latest fixes help?

Sorry, I missed those commits and was using 20181026 snapshot, which
obviously didn't include them.  Now, just to be sure, I built memstick
image from latest checkout, and yes, both installer and installed system
are able to boot, thank you!



signature.asc
Description: OpenPGP digital signature

Re: UEFI boot hangs after loader

[Harry Newton]

The patch you emailed fixed it for me ... was there something else I've
missed ?


On 28 October 2018 at 16:40, Warner Losh  wrote:

>
>
> On Sun, Oct 28, 2018, 10:39 AM Yuri Pankov  wrote:
>
>> Jung-uk Kim wrote:
>> > On 18. 10. 24., Warner Losh wrote:
>> >> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton 
>> wrote:
>> >>
>> >>> gryphon# efivar -N --hex $(efivar | grep Boot0002)
>> >>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
>> >>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
>> >>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
>> >>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
>> >>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
>> >>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
>> >>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
>> >>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
>> >>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
>> >>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
>> >>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
>> >>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
>> >>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
>> >>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
>> >>> 00e0: 7f ff 04 00 00 00 42 4f
>> >>> gryphon#
>> >>>
>> >>
>> >> Perfect. I'll decode this and see if I can figure out where we're
>> going AFU.
>> >
>> > It looks familiar.
>> >
>> > http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-
>> a3e0-f91b410052fa
>>
>> I have an output looking similar, but not exactly:
>>
>> : 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00
>> 0010: 4f 00 53 00 00 00 04 01 2a 00 01 00 00 00 28 00
>> 0020: 00 00 00 00 00 00 00 40 06 00 00 00 00 00 f1 84
>> 0030: d7 13 ca da e8 11 94 1d 30 85 a9 40 0a 5c 02 02
>> 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
>> 0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00
>> 0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00
>> 0070: 7f ff 04 00 aa 55 18 0f
>>
>> Same problem with ASUS P8H77-I.
>>
>
> Do the latest fixes help?
>
> Warner
>
>>
>> >>> On 24 October 2018 at 15:09, Warner Losh  wrote:
>> >>>
>> 
>> 
>>  On Wed, Oct 24, 2018 at 7:05 AM Harry Newton 
>> wrote:
>> 
>> > Booted with the installer image makes efibootmgr to work as you
>> said:
>> >
>> > gryphon# efibootmgr -v
>> > BootCurrent: 0002
>> > Timeout : 2 seconds
>> > BootOrder : 0001, 0002
>> > Boot0001* UEFI OS
>> >
>> > HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/
>> File(\EFI\BOOT\BOOTX64.EFI)
>> > ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>> >
>> > However it (efibootmgr) hangs and doesn't return to the shell,
>> though it
>> > is
>> > interruptible with ^C.
>> >
>> > The partition listed against Boot0001 is my efi partition.
>> >
>> 
>>  Can you do something like:
>> 
>>  sudo efivar -N --hex `sudo efivar | grep Boot0002`
>> 
>>  so I can have an example of a naughty boot variable? That's almost
>>  certainly causing the heart-burn.
>> 
>>  Warner
>> 
>> 
>> 
>> > /H
>> >
>> > On 23 October 2018 at 22:51, Kyle Evans  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.
>> >>
>> >> 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 
>> 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 
>> 

Re: UEFI boot hangs after loader

[Warner Losh]

On Sun, Oct 28, 2018, 10:39 AM Yuri Pankov  wrote:

> Jung-uk Kim wrote:
> > On 18. 10. 24., Warner Losh wrote:
> >> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:
> >>
> >>> gryphon# efivar -N --hex $(efivar | grep Boot0002)
> >>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
> >>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
> >>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
> >>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
> >>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
> >>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
> >>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
> >>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
> >>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
> >>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
> >>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
> >>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
> >>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
> >>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
> >>> 00e0: 7f ff 04 00 00 00 42 4f
> >>> gryphon#
> >>>
> >>
> >> Perfect. I'll decode this and see if I can figure out where we're going
> AFU.
> >
> > It looks familiar.
> >
> > http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa
>
> I have an output looking similar, but not exactly:
>
> : 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00
> 0010: 4f 00 53 00 00 00 04 01 2a 00 01 00 00 00 28 00
> 0020: 00 00 00 00 00 00 00 40 06 00 00 00 00 00 f1 84
> 0030: d7 13 ca da e8 11 94 1d 30 85 a9 40 0a 5c 02 02
> 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
> 0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00
> 0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00
> 0070: 7f ff 04 00 aa 55 18 0f
>
> Same problem with ASUS P8H77-I.
>

Do the latest fixes help?

Warner

>
> >>> On 24 October 2018 at 15:09, Warner Losh  wrote:
> >>>
> 
> 
>  On Wed, Oct 24, 2018 at 7:05 AM Harry Newton 
> wrote:
> 
> > Booted with the installer image makes efibootmgr to work as you said:
> >
> > gryphon# efibootmgr -v
> > BootCurrent: 0002
> > Timeout : 2 seconds
> > BootOrder : 0001, 0002
> > Boot0001* UEFI OS
> >
> >
> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
> > ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
> >
> > However it (efibootmgr) hangs and doesn't return to the shell,
> though it
> > is
> > interruptible with ^C.
> >
> > The partition listed against Boot0001 is my efi partition.
> >
> 
>  Can you do something like:
> 
>  sudo efivar -N --hex `sudo efivar | grep Boot0002`
> 
>  so I can have an example of a naughty boot variable? That's almost
>  certainly causing the heart-burn.
> 
>  Warner
> 
> 
> 
> > /H
> >
> > On 23 October 2018 at 22:51, Kyle Evans  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.
> >>
> >> 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 
> 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 
> 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 

Re: UEFI boot hangs after loader

[Yuri Pankov]

Jung-uk Kim wrote:
> On 18. 10. 24., Warner Losh wrote:
>> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:
>>
>>> gryphon# efivar -N --hex $(efivar | grep Boot0002)
>>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
>>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
>>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
>>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
>>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
>>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
>>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
>>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
>>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
>>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
>>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
>>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
>>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
>>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
>>> 00e0: 7f ff 04 00 00 00 42 4f
>>> gryphon#
>>>
>>
>> Perfect. I'll decode this and see if I can figure out where we're going AFU.
> 
> It looks familiar.
> 
> http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa

I have an output looking similar, but not exactly:

: 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00
0010: 4f 00 53 00 00 00 04 01 2a 00 01 00 00 00 28 00
0020: 00 00 00 00 00 00 00 40 06 00 00 00 00 00 f1 84
0030: d7 13 ca da e8 11 94 1d 30 85 a9 40 0a 5c 02 02
0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00
0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00
0070: 7f ff 04 00 aa 55 18 0f

Same problem with ASUS P8H77-I.

>>> On 24 October 2018 at 15:09, Warner Losh  wrote:
>>>


 On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:

> Booted with the installer image makes efibootmgr to work as you said:
>
> gryphon# efibootmgr -v
> BootCurrent: 0002
> Timeout : 2 seconds
> BootOrder : 0001, 0002
> Boot0001* UEFI OS
>
> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>
> However it (efibootmgr) hangs and doesn't return to the shell, though it
> is
> interruptible with ^C.
>
> The partition listed against Boot0001 is my efi partition.
>

 Can you do something like:

 sudo efivar -N --hex `sudo efivar | grep Boot0002`

 so I can have an example of a naughty boot variable? That's almost
 certainly causing the heart-burn.

 Warner



> /H
>
> On 23 October 2018 at 22:51, Kyle Evans  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.
>>
>> 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  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  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  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  wrote:
>
> Yes ... so as everything is built, can I just alter
>> LOADER_DEFAULT_INTERP
> in 

Re: UEFI boot hangs after loader

[Warner Losh]

I've recreated something like this in efivar as well...  I need to study
the code for how to improve it to have sanity limits... I hope to have a
patch soon...  Thanks for this data point. I think I'm on the right track.

Warner

On Fri, Oct 26, 2018 at 3:47 PM Harry Newton  wrote:

> 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  wrote:
>
>>
>>
>> > On 24 Oct 2018, at 00:51, Kyle Evans  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  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  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  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  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  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  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  wrote:
>> >>
>> >>> hm. in that case, whats the content of /boot/loader.rc ?
>> >>>
>> >>> rgds,
>> >>> toomas
>> >>>
>> >>>
>> >>> On 23 Oct 2018, at 23:01, Harry Newton  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  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.
>> 

Re: UEFI boot hangs after loader

[Harry Newton]

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  wrote:

>
>
> > On 24 Oct 2018, at 00:51, Kyle Evans  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  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  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  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  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  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  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  wrote:
> >>
> >>> hm. in that case, whats the content of /boot/loader.rc ?
> >>>
> >>> rgds,
> >>> toomas
> >>>
> >>>
> >>> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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 

Re: UEFI boot hangs after loader

[Warner Losh]

On Wed, Oct 24, 2018 at 11:47 AM Jung-uk Kim  wrote:

> On 18. 10. 24., Warner Losh wrote:
> > On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:
> >
> >> gryphon# efivar -N --hex $(efivar | grep Boot0002)
> >> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
> >> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
> >> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
> >> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
> >> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
> >> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
> >> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
> >> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
> >> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
> >> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
> >> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
> >> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
> >> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
> >> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
> >> 00e0: 7f ff 04 00 00 00 42 4f
> >> gryphon#
> >>
> >
> > Perfect. I'll decode this and see if I can figure out where we're going
> AFU.
>
> It looks familiar.
>
> http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa
>
> Jung-uk Kim
>

His loader variable works for me (sigh). Your loader variable doesn't. I
totally forgot you'd sent that as well. Thanks for the pointer. It's quite
helpful.

Warner


> >> On 24 October 2018 at 15:09, Warner Losh  wrote:
> >>
> >>>
> >>>
> >>> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:
> >>>
>  Booted with the installer image makes efibootmgr to work as you said:
> 
>  gryphon# efibootmgr -v
>  BootCurrent: 0002
>  Timeout : 2 seconds
>  BootOrder : 0001, 0002
>  Boot0001* UEFI OS
> 
> 
> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
>  ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
> 
>  However it (efibootmgr) hangs and doesn't return to the shell, though
> it
>  is
>  interruptible with ^C.
> 
>  The partition listed against Boot0001 is my efi partition.
> 
> >>>
> >>> Can you do something like:
> >>>
> >>> sudo efivar -N --hex `sudo efivar | grep Boot0002`
> >>>
> >>> so I can have an example of a naughty boot variable? That's almost
> >>> certainly causing the heart-burn.
> >>>
> >>> Warner
> >>>
> >>>
> >>>
>  /H
> 
>  On 23 October 2018 at 22:51, Kyle Evans  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.
> >
> > 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 
> 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  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  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  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 ?
> 

Re: UEFI boot hangs after loader

[Jung-uk Kim]

On 18. 10. 24., Warner Losh wrote:
> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:
> 
>> gryphon# efivar -N --hex $(efivar | grep Boot0002)
>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
>> 00e0: 7f ff 04 00 00 00 42 4f
>> gryphon#
>>
> 
> Perfect. I'll decode this and see if I can figure out where we're going AFU.

It looks familiar.

http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa

Jung-uk Kim

>> On 24 October 2018 at 15:09, Warner Losh  wrote:
>>
>>>
>>>
>>> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:
>>>
 Booted with the installer image makes efibootmgr to work as you said:

 gryphon# efibootmgr -v
 BootCurrent: 0002
 Timeout : 2 seconds
 BootOrder : 0001, 0002
 Boot0001* UEFI OS

 HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
 ada0p1:/EFI/BOOT/BOOTX64.EFI (null)

 However it (efibootmgr) hangs and doesn't return to the shell, though it
 is
 interruptible with ^C.

 The partition listed against Boot0001 is my efi partition.

>>>
>>> Can you do something like:
>>>
>>> sudo efivar -N --hex `sudo efivar | grep Boot0002`
>>>
>>> so I can have an example of a naughty boot variable? That's almost
>>> certainly causing the heart-burn.
>>>
>>> Warner
>>>
>>>
>>>
 /H

 On 23 October 2018 at 22:51, Kyle Evans  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.
>
> 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  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  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  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  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  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 
 wrote:
>>

Re: UEFI boot hangs after loader

[Harry Newton]

Thanks — please let me if there's anything I can do to help.

On 24 October 2018 at 18:25, Warner Losh  wrote:

>
>
> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:
>
>> gryphon# efivar -N --hex $(efivar | grep Boot0002)
>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
>> 00e0: 7f ff 04 00 00 00 42 4f
>> gryphon#
>>
>
> Perfect. I'll decode this and see if I can figure out where we're going
> AFU.
>
> Warner
>
>
>> On 24 October 2018 at 15:09, Warner Losh  wrote:
>>
>>>
>>>
>>> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:
>>>
 Booted with the installer image makes efibootmgr to work as you said:

 gryphon# efibootmgr -v
 BootCurrent: 0002
 Timeout : 2 seconds
 BootOrder : 0001, 0002
 Boot0001* UEFI OS
 HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/
 File(\EFI\BOOT\BOOTX64.EFI)
 ada0p1:/EFI/BOOT/BOOTX64.EFI (null)

 However it (efibootmgr) hangs and doesn't return to the shell, though
 it is
 interruptible with ^C.

 The partition listed against Boot0001 is my efi partition.

>>>
>>> Can you do something like:
>>>
>>> sudo efivar -N --hex `sudo efivar | grep Boot0002`
>>>
>>> so I can have an example of a naughty boot variable? That's almost
>>> certainly causing the heart-burn.
>>>
>>> Warner
>>>
>>>
>>>
 /H

 On 23 October 2018 at 22:51, Kyle Evans  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.
 >
 > 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 
 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  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  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  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  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
 > > >>> 

Re: UEFI boot hangs after loader

[Warner Losh]

On Wed, Oct 24, 2018 at 10:33 AM Harry Newton  wrote:

> gryphon# efivar -N --hex $(efivar | grep Boot0002)
> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
> 00e0: 7f ff 04 00 00 00 42 4f
> gryphon#
>

Perfect. I'll decode this and see if I can figure out where we're going AFU.

Warner


> On 24 October 2018 at 15:09, Warner Losh  wrote:
>
>>
>>
>> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:
>>
>>> Booted with the installer image makes efibootmgr to work as you said:
>>>
>>> gryphon# efibootmgr -v
>>> BootCurrent: 0002
>>> Timeout : 2 seconds
>>> BootOrder : 0001, 0002
>>> Boot0001* UEFI OS
>>>
>>> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>>>
>>> However it (efibootmgr) hangs and doesn't return to the shell, though it
>>> is
>>> interruptible with ^C.
>>>
>>> The partition listed against Boot0001 is my efi partition.
>>>
>>
>> Can you do something like:
>>
>> sudo efivar -N --hex `sudo efivar | grep Boot0002`
>>
>> so I can have an example of a naughty boot variable? That's almost
>> certainly causing the heart-burn.
>>
>> Warner
>>
>>
>>
>>> /H
>>>
>>> On 23 October 2018 at 22:51, Kyle Evans  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.
>>> >
>>> > 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  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  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  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  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  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 
>>> wrote:
>>> > > >>> >
>>> > > >>> > So it's got FORTH in it, but my loader is lua based, and also
>>> > doesn't
>>> > > >>> > appear to read 

Re: UEFI boot hangs after loader

[Toomas Soome]

> On 24 Oct 2018, at 10:13, Harry Newton  wrote:
> 
> Booted with the installer image makes efibootmgr to work as you said:
> 
> gryphon# efibootmgr -v
> BootCurrent: 0002
> Timeout : 2 seconds 
> BootOrder : 0001, 0002 
> Boot0001* UEFI OS 
> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
>  ada0p1:/EFI/BOOT/BOOTX64.EFI (null) 
> 
> However it (efibootmgr) hangs and doesn't return to the shell, though it is 
> interruptible with ^C.
> 
> The partition listed against Boot0001 is my efi partition.

My guess is that the loader.efi is hung by exactly the same reason - there is 
some bad (unexpected) value, also the printed out (null) hints about weirdness 
there, because we normally get (null) when NULL pointer was passed to printf(). 
So either we should debug the loader.efi or efibootmgr to identify why it is 
hung and fix the code to avoid it. 

rgds,
toomas

> 
> /H
> 
> On 23 October 2018 at 22:51, Kyle Evans  > 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.
> 
> 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  > 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  > > 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  > > > 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  > >> > 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  > >> > 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  > >>> > > 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  > >>> > > wrote:
> > >>> >
> > >>> >> hm. in that case, whats the content of /boot/loader.rc ?
> > >>> >>
> > >>> >> rgds,
> > >>> >> toomas
> > >>> >>
> > >>> >>
> > >>> >> On 23 Oct 2018, at 23:01, Harry Newton  > >>> >> > 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  > >>> >> > wrote:
> > >>> >>
> > >>> >>> Do you get boot menu? if so, press esc to get to ok prompt, then 
> > >>> >>> type
> > >>> >>> start - 

Re: UEFI boot hangs after loader

[Harry Newton]

gryphon# efivar -N --hex $(efivar | grep Boot0002)
: 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00
0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00
0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00
0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00
0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00
0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05
0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00
0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90
0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff
0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19
00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00
00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00
00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00
00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00
00e0: 7f ff 04 00 00 00 42 4f
gryphon#

On 24 October 2018 at 15:09, Warner Losh  wrote:

>
>
> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:
>
>> Booted with the installer image makes efibootmgr to work as you said:
>>
>> gryphon# efibootmgr -v
>> BootCurrent: 0002
>> Timeout : 2 seconds
>> BootOrder : 0001, 0002
>> Boot0001* UEFI OS
>> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/
>> File(\EFI\BOOT\BOOTX64.EFI)
>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>>
>> However it (efibootmgr) hangs and doesn't return to the shell, though it
>> is
>> interruptible with ^C.
>>
>> The partition listed against Boot0001 is my efi partition.
>>
>
> Can you do something like:
>
> sudo efivar -N --hex `sudo efivar | grep Boot0002`
>
> so I can have an example of a naughty boot variable? That's almost
> certainly causing the heart-burn.
>
> Warner
>
>
>
>> /H
>>
>> On 23 October 2018 at 22:51, Kyle Evans  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.
>> >
>> > 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  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  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  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  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  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 
>> 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 
>> wrote:
>> > > >>> >
>> > > >>> >> hm. in that case, whats the content of /boot/loader.rc ?
>> > > >>> >>
>> > > >>> >> rgds,
>> > > >>> >> toomas
>> > > >>> >>
>> > > >>> >>
>> > > >>> >> On 23 Oct 2018, at 23:01, Harry 

Re: UEFI boot hangs after loader

[Warner Losh]

On Wed, Oct 24, 2018 at 9:36 AM Toomas Soome  wrote:

>
>
> > On 24 Oct 2018, at 00:51, Kyle Evans  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()
>

I think there's a Boot 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  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  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  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  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  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  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  wrote:
> >>
> >>> hm. in that case, whats the content of /boot/loader.rc ?
> >>>
> >>> rgds,
> >>> toomas
> >>>
> >>>
> >>> On 23 Oct 2018, at 23:01, Harry Newton  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  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  wrote:
> >
> > Just upgraded my Asus UX303L (amd64) from 11-STABLE to 

Re: UEFI boot hangs after loader

[Toomas Soome]

> On 24 Oct 2018, at 00:51, Kyle Evans  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  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  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  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  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  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  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  wrote:
>> 
>>> hm. in that case, whats the content of /boot/loader.rc ?
>>> 
>>> rgds,
>>> toomas
>>> 
>>> 
>>> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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 

Re: UEFI boot hangs after loader

[Warner Losh]

On Wed, Oct 24, 2018 at 7:05 AM Harry Newton  wrote:

> Booted with the installer image makes efibootmgr to work as you said:
>
> gryphon# efibootmgr -v
> BootCurrent: 0002
> Timeout : 2 seconds
> BootOrder : 0001, 0002
> Boot0001* UEFI OS
>
> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>
> However it (efibootmgr) hangs and doesn't return to the shell, though it is
> interruptible with ^C.
>
> The partition listed against Boot0001 is my efi partition.
>

Can you do something like:

sudo efivar -N --hex `sudo efivar | grep Boot0002`

so I can have an example of a naughty boot variable? That's almost
certainly causing the heart-burn.

Warner



> /H
>
> On 23 October 2018 at 22:51, Kyle Evans  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.
> >
> > 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  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  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  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  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  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  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  wrote:
> > > >>> >
> > > >>> >> hm. in that case, whats the content of /boot/loader.rc ?
> > > >>> >>
> > > >>> >> rgds,
> > > >>> >> toomas
> > > >>> >>
> > > >>> >>
> > > >>> >> On 23 Oct 2018, at 23:01, Harry Newton 
> 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 
> 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
> > > >>> >>>
> > > >>> 

Re: UEFI boot hangs after loader

[Harry Newton]

Re the efibootmgr hang: it appears to be in / under the call to
efidp_format_device_path()  in efibootmgr.c which is called with -v.
Without -v:

gryphon# efibootmgr
BootCurrent: 0002
Timeout : 2 seconds
BootOrder : 0001, 0002
Boot0001* UEFI OS +
Boot0002* UEFI: USB Flash Memory1.00
gryphon#



On 24 October 2018 at 08:13, Harry Newton  wrote:

> Booted with the installer image makes efibootmgr to work as you said:
>
> gryphon# efibootmgr -v
> BootCurrent: 0002
> Timeout : 2 seconds
> BootOrder : 0001, 0002
> Boot0001* UEFI OS HD(1,GPT,b19ccd5d-7c6a-11e7-
> ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>
> However it (efibootmgr) hangs and doesn't return to the shell, though it
> is interruptible with ^C.
>
> The partition listed against Boot0001 is my efi partition.
>
> /H
>
> On 23 October 2018 at 22:51, Kyle Evans  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.
>>
>> 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-IM
>> AGES/12.0/
>>
>> On Tue, Oct 23, 2018 at 4:23 PM Harry Newton  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  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  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  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  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  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  wrote:
>> > >>> >
>> > >>> >> hm. in that case, whats the content of /boot/loader.rc ?
>> > >>> >>
>> > >>> >> rgds,
>> > >>> >> toomas
>> > >>> >>
>> > >>> >>
>> > >>> >> On 23 Oct 2018, at 23:01, Harry Newton  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  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 

Re: UEFI boot hangs after loader

[Harry Newton]

Booted with the installer image makes efibootmgr to work as you said:

gryphon# efibootmgr -v
BootCurrent: 0002
Timeout : 2 seconds
BootOrder : 0001, 0002
Boot0001* UEFI OS
HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
ada0p1:/EFI/BOOT/BOOTX64.EFI (null)

However it (efibootmgr) hangs and doesn't return to the shell, though it is
interruptible with ^C.

The partition listed against Boot0001 is my efi partition.

/H

On 23 October 2018 at 22:51, Kyle Evans  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.
>
> 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  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  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  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  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  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  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  wrote:
> > >>> >
> > >>> >> hm. in that case, whats the content of /boot/loader.rc ?
> > >>> >>
> > >>> >> rgds,
> > >>> >> toomas
> > >>> >>
> > >>> >>
> > >>> >> On 23 Oct 2018, at 23:01, Harry Newton  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  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 
> 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
> > 

Re: UEFI boot hangs after loader

[Kyle Evans]

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.

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  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  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  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  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  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  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  wrote:
> >>> >
> >>> >> hm. in that case, whats the content of /boot/loader.rc ?
> >>> >>
> >>> >> rgds,
> >>> >> toomas
> >>> >>
> >>> >>
> >>> >> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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)
> >>> 

Re: UEFI boot hangs after loader

[Harry Newton]

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  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  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  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  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  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  wrote:
>>> >
>>> >> hm. in that case, whats the content of /boot/loader.rc ?
>>> >>
>>> >> rgds,
>>> >> toomas
>>> >>
>>> >>
>>> >> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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)
>>>   40964194304 3  freebsd-swap  (2.0G)
>>>    4198400  245870592 4  freebsd-zfs  (117G)
>>>  250068992648- 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.
>>> 
>>> 

Re: UEFI boot hangs after loader

[Harry Newton]

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  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  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  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  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  wrote:
>> >
>> >> hm. in that case, whats the content of /boot/loader.rc ?
>> >>
>> >> rgds,
>> >> toomas
>> >>
>> >>
>> >> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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)
>>   40964194304 3  freebsd-swap  (2.0G)
>>    4198400  245870592 4  freebsd-zfs  (117G)
>>  250068992648- 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
>
>
>


-- 

Re: UEFI boot hangs after loader

[Toomas Soome]

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  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  > 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  > > 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  > > wrote:
> > 
> >> hm. in that case, whats the content of /boot/loader.rc ?
> >> 
> >> rgds,
> >> toomas
> >> 
> >> 
> >> On 23 Oct 2018, at 23:01, Harry Newton  >> > 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  >> > 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   > 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)
>   40964194304 3  freebsd-swap  (2.0G)
>    4198400  245870592 4  freebsd-zfs  (117G)
>  250068992648- 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 

Re: UEFI boot hangs after loader

[Harry Newton]

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  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  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  wrote:
> >
> >> hm. in that case, whats the content of /boot/loader.rc ?
> >>
> >> rgds,
> >> toomas
> >>
> >>
> >> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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)
>   40964194304 3  freebsd-swap  (2.0G)
>    4198400  245870592 4  freebsd-zfs  (117G)
>  250068992648- 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@
> freebsd.org"
>
>


-- 
Harry Newton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI boot hangs after loader

[Toomas Soome]

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  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  wrote:
> 
>> hm. in that case, whats the content of /boot/loader.rc ?
>> 
>> rgds,
>> toomas
>> 
>> 
>> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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)
  40964194304 3  freebsd-swap  (2.0G)
   4198400  245870592 4  freebsd-zfs  (117G)
 250068992648- 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-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI boot hangs after loader

[Harry Newton]

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  wrote:

> hm. in that case, whats the content of /boot/loader.rc ?
>
> rgds,
> toomas
>
>
> On 23 Oct 2018, at 23:01, Harry Newton  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  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  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)
>> >   40964194304 3  freebsd-swap  (2.0G)
>> >4198400  245870592 4  freebsd-zfs  (117G)
>> >  250068992648- 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-unsubscr...@freebsd.org"

Re: UEFI boot hangs after loader

[Toomas Soome]

hm. in that case, whats the content of /boot/loader.rc ?

rgds,
toomas

> On 23 Oct 2018, at 23:01, Harry Newton  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  > 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  > > 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)
> >   40964194304 3  freebsd-swap  (2.0G)
> >4198400  245870592 4  freebsd-zfs  (117G)
> >  250068992648- 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-unsubscr...@freebsd.org 
> > "
> 
> 
> 
> 
> -- 
> Harry Newton

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI boot hangs after loader

[Harry Newton]

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  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  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)
> >   40964194304 3  freebsd-swap  (2.0G)
> >4198400  245870592 4  freebsd-zfs  (117G)
> >  250068992648- 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@
> freebsd.org"
>
>


-- 
Harry Newton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI boot hangs after loader

[Toomas Soome]

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  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)
>   40964194304 3  freebsd-swap  (2.0G)
>4198400  245870592 4  freebsd-zfs  (117G)
>  250068992648- 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-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"