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
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
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
> >>>
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:
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
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
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
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
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
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
> 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
>
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
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
> 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.
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
>
>
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
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)
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,
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
