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

next in thread | previous in thread | raw e-mail | index | archive | help


> On 24 Oct 2018, at 00:51, Kyle Evans <kevans@freebsd.org> wrote:
>=20
> Hi,
>=20
> 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.
>=20


Yes, thats my guess too, my guess is that since in general the uefi boot =
is working, in this case it has to be some corner case, and I would =
start checking with boot variable related code; specifically, I=E2=80=99d =
suggest to patch (temporarily) the find_currdev() in efi/loader/main.c =
to set do_bootmgr =3D false and see if that will fix the boot. Then we =
can explore what is happening in match_boot_info()=20

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.
>=20
> Thanks,
>=20
> Kyle Evans
>=20
> [0] =
https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/
>=20
> On Tue, Oct 23, 2018 at 4:23 PM Harry Newton <hn@yewbarrow.net> wrote:
>>=20
>> I set LOADER_DEFAULT_INTERP=3D4th 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.
>>=20
>> Suggestions received welcomed, and new suggestions / leads to follow =
also
>> very much welcomed.
>>=20
>> /H
>>=20
>>=20
>> On 23 October 2018 at 21:33, Harry Newton <hn@yewbarrow.net> wrote:
>>=20
>>> 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 ?
>>>=20
>>> /H
>>>=20
>>> On 23 October 2018 at 21:30, Toomas Soome <tsoome@me.com> wrote:
>>>=20
>>>> you should have the binaries in boot - just ln (or copy) one to =
loader.efi
>>>>=20
>>>> rgds,
>>>> toomas
>>>>=20
>>>>=20
>>>> On 23 Oct 2018, at 23:22, Harry Newton <hn@yewbarrow.net> wrote:
>>>>=20
>>>> 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 ?
>>>>=20
>>>>=20
>>>> On 23 October 2018 at 21:17, Toomas Soome <tsoome@me.com> wrote:
>>>>=20
>>>>> ok, in that case I=E2=80=99d suggest to test out if forth based =
one is still
>>>>> working - at least you can get the bootable system. And then there =
is a
>>>>> chance to debug the lua version too (note it should be possible to =
chain
>>>>> /boot/loader_lua.efi).
>>>>>=20
>>>>> rgds,
>>>>> toomas
>>>>>=20
>>>>>> On 23 Oct 2018, at 23:08, Harry Newton <hn@yewbarrow.net> wrote:
>>>>>>=20
>>>>>> So it's got FORTH in it, but my loader is lua based, and also =
doesn't
>>>>>> appear to read loader.rc.
>>>>>>=20
>>>>>> /H
>>>>>>=20
>>>>>> On 23 October 2018 at 21:03, Toomas Soome <tsoome@me.com> wrote:
>>>>>>=20
>>>>>>> hm. in that case, whats the content of /boot/loader.rc ?
>>>>>>>=20
>>>>>>> rgds,
>>>>>>> toomas
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 23 Oct 2018, at 23:01, Harry Newton <hn@yewbarrow.net> wrote:
>>>>>>>=20
>>>>>>> If boot menu is the screen where you get the options for various
>>>>> kernels
>>>>>>> and the picture of the daemon head, no.  It stops at the point =
in my
>>>>> email
>>>>>>> =E2=80=94 though not as I said just before the kernel is loaded =
but in point
>>>>> of
>>>>>>> fact before the menu.
>>>>>>>=20
>>>>>>> I've also rebuilt the kernel and still can't use efibootmgr =
which is
>>>>>>> puzzling me.
>>>>>>>=20
>>>>>>> /H
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 23 October 2018 at 20:56, Toomas Soome <tsoome@me.com> wrote:
>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> If the loader prompt is still usable, then next command would =
be:
>>>>> boot
>>>>>>>>=20
>>>>>>>> rgds,
>>>>>>>> toomas
>>>>>>>>=20
>>>>>>>>> On 23 Oct 2018, at 20:45, Harry Newton <hn@yewbarrow.net> =
wrote:
>>>>>>>>>=20
>>>>>>>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to =
12.0-BETA1
>>>>>>>> r339529
>>>>>>>>> by source.  Have a problem with booting which hangs after:
>>>>>>>>>=20
>>>>>>>>>>> FreeBSD EFI boot block
>>>>>>>>> Loader path: /boot/loader.efi
>>>>>>>>>=20
>>>>>>>>> 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
>>>>>>>>>=20
>>>>>>>>>  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
>>>>>>>>> -
>>>>>>>>>=20
>>>>>>>>> So it gets into loader.efi which runs but stops I think just =
before
>>>>>>>> loading
>>>>>>>>> the kernel.  Partitions:
>>>>>>>>>=20
>>>>>>>>> =3D>       40  250069600  ada0  GPT  (119G)
>>>>>>>>>       40       1600     1  efi  (800K)
>>>>>>>>>     1640       1024     2  freebsd-boot  (512K)
>>>>>>>>>     2664       1432        - free -  (716K)
>>>>>>>>>     4096    4194304     3  freebsd-swap  (2.0G)
>>>>>>>>>  4198400  245870592     4  freebsd-zfs  (117G)
>>>>>>>>> 250068992        648        - free -  (324K)
>>>>>>>>>=20
>>>>>>>>> and the EFI partition is FAT 12.
>>>>>>>>>=20
>>>>>>>>> I can't provide (at the moment) any output from efibootmgr:
>>>>>>>>>=20
>>>>>>>>> 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
>>>>>>>>>=20
>>>>>>>>> which I don't understand.
>>>>>>>>>=20
>>>>>>>>> I'm going to rebuild the kernel (currently GENERIC) and see if =
that
>>>>>>>> allows
>>>>>>>>> me to load efirt / use efibootmgr.
>>>>>>>>>=20
>>>>>>>>> In the meantime, I should be very grateful for any advice.
>>>>>>>>>=20
>>>>>>>>> ( Currently booting using a 11-RELEASE memstick image and =
dropping
>>>>> into
>>>>>>>> its
>>>>>>>>> loader to get to the installed 12-STABLE ).
>>>>>>>>>=20
>>>>>>>>> /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"
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> Harry Newton
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> 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"
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Harry Newton
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> --
>>> Harry Newton
>>>=20
>>=20
>>=20
>>=20
>> --
>> 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"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A48C6FA-805E-4B36-8C7D-A98422EBC7A5>