Date: Fri, 26 Oct 2018 15:58:04 -0600 From: Warner Losh <imp@bsdimp.com> To: Harry Newton <hn@yewbarrow.net> Cc: Toomas Soome <tsoome@me.com>, FreeBSD Current <freebsd-current@freebsd.org>, Kyle Evans <kevans@freebsd.org> Subject: Re: UEFI boot hangs after loader Message-ID: <CANCZdfr_rZSUpLfWGd=CjOYEx4g%2BMrdvOgDqbrchV1DCHm4VjA@mail.gmail.com> In-Reply-To: <CAKAm69GSF9o6XAFMdiChXKs5eSsUs7H7W%2Bt5DRDSNMbPWAPaXA@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> <3A48C6FA-805E-4B36-8C7D-A98422EBC7A5@me.com> <CAKAm69GSF9o6XAFMdiChXKs5eSsUs7H7W%2Bt5DRDSNMbPWAPaXA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <hn@yewbarrow.net> 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() ca= ll > does not return. > > /H > > On 24 October 2018 at 07:32, Toomas Soome <tsoome@me.com> wrote: > >> >> >> > On 24 Oct 2018, at 00:51, Kyle Evans <kevans@freebsd.org> wrote: >> > >> > Hi, >> > >> > I suspect 4th vs. lua has no impact here, given the output shown -- >> > can you throw one of the installer images [0] on some removable media >> > and give that a shot for booting? If that works, we can explore UEFI >> > variables from there. >> > >> >> >> Yes, thats my guess too, my guess is that since in general the uefi boot >> is working, in this case it has to be some corner case, and I would star= t >> checking with boot variable related code; specifically, I=E2=80=99d sugg= est 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 expl= ore >> what is happening in match_boot_info() >> >> rgds, >> toomas >> >> > efibootmgr will only work on a successful UEFI boot, unfortunately- if >> > we didn't make uefi loader -> kernel transition, then we don't have >> > access to runtime services. >> > >> > Thanks, >> > >> > Kyle Evans >> > >> > [0] >> https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/ >> > >> > On Tue, Oct 23, 2018 at 4:23 PM Harry Newton <hn@yewbarrow.net> wrote: >> >> >> >> I set LOADER_DEFAULT_INTERP=3D4th and went in /usr/src/stand and re-m= ade >> 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 E= FI >> >> variables, but as efibootmgr doesn't work I can't explore this, despi= te >> >> efirt being in the kernel. >> >> >> >> Suggestions received welcomed, and new suggestions / leads to follow >> also >> >> very much welcomed. >> >> >> >> /H >> >> >> >> >> >> On 23 October 2018 at 21:33, Harry Newton <hn@yewbarrow.net> wrote: >> >> >> >>> Right ... I've the binaries in /boot, freshly made. This might be a >> silly >> >>> question ... do I not need to copy them (or dd the boot1.efifat >> image) to >> >>> the EFI partition ? >> >>> >> >>> /H >> >>> >> >>> On 23 October 2018 at 21:30, Toomas Soome <tsoome@me.com> wrote: >> >>> >> >>>> you should have the binaries in boot - just ln (or copy) one to >> loader.efi >> >>>> >> >>>> rgds, >> >>>> toomas >> >>>> >> >>>> >> >>>> On 23 Oct 2018, at 23:22, Harry Newton <hn@yewbarrow.net> wrote: >> >>>> >> >>>> Yes ... so as everything is built, can I just alter >> LOADER_DEFAULT_INTERP >> >>>> in /etc/make.conf and then reinstall just the loader and boot parts >> onto >> >>>> the UEFI partition ? If so, how ? >> >>>> >> >>>> >> >>>> On 23 October 2018 at 21:17, Toomas Soome <tsoome@me.com> wrote: >> >>>> >> >>>>> ok, in that case I=E2=80=99d suggest to test out if forth based on= e is still >> >>>>> working - at least you can get the bootable system. And then there >> is a >> >>>>> chance to debug the lua version too (note it should be possible to >> chain >> >>>>> /boot/loader_lua.efi). >> >>>>> >> >>>>> rgds, >> >>>>> toomas >> >>>>> >> >>>>>> On 23 Oct 2018, at 23:08, Harry Newton <hn@yewbarrow.net> wrote: >> >>>>>> >> >>>>>> So it's got FORTH in it, but my loader is lua based, and also >> doesn't >> >>>>>> appear to read loader.rc. >> >>>>>> >> >>>>>> /H >> >>>>>> >> >>>>>> On 23 October 2018 at 21:03, Toomas Soome <tsoome@me.com> wrote: >> >>>>>> >> >>>>>>> hm. in that case, whats the content of /boot/loader.rc ? >> >>>>>>> >> >>>>>>> rgds, >> >>>>>>> toomas >> >>>>>>> >> >>>>>>> >> >>>>>>> On 23 Oct 2018, at 23:01, Harry Newton <hn@yewbarrow.net> wrote: >> >>>>>>> >> >>>>>>> If boot menu is the screen where you get the options for various >> >>>>> kernels >> >>>>>>> and the picture of the daemon head, no. It stops at the point i= n >> my >> >>>>> email >> >>>>>>> =E2=80=94 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 whic= h >> is >> >>>>>>> puzzling me. >> >>>>>>> >> >>>>>>> /H >> >>>>>>> >> >>>>>>> >> >>>>>>> On 23 October 2018 at 20:56, Toomas Soome <tsoome@me.com> wrote: >> >>>>>>> >> >>>>>>>> Do you get boot menu? if so, press esc to get to ok prompt, the= n >> type >> >>>>>>>> start - if its bootfort based loader, it will load the kernel a= nd >> >>>>> modules. >> >>>>>>>> lsmod will then list the loaded files. >> >>>>>>>> >> >>>>>>>> If the loader prompt is still usable, then next command would b= e: >> >>>>> boot >> >>>>>>>> >> >>>>>>>> rgds, >> >>>>>>>> toomas >> >>>>>>>> >> >>>>>>>>> On 23 Oct 2018, at 20:45, Harry Newton <hn@yewbarrow.net> >> wrote: >> >>>>>>>>> >> >>>>>>>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to >> 12.0-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: >> >>>>>>>>> >> >>>>>>>>> =3D> 40 250069600 ada0 GPT (119G) >> >>>>>>>>> 40 1600 1 efi (800K) >> >>>>>>>>> 1640 1024 2 freebsd-boot (512K) >> >>>>>>>>> 2664 1432 - free - (716K) >> >>>>>>>>> 4096 4194304 3 freebsd-swap (2.0G) >> >>>>>>>>> 4198400 245870592 4 freebsd-zfs (117G) >> >>>>>>>>> 250068992 648 - free - (324K) >> >>>>>>>>> >> >>>>>>>>> and the EFI partition is FAT 12. >> >>>>>>>>> >> >>>>>>>>> I can't provide (at the moment) any output from efibootmgr: >> >>>>>>>>> >> >>>>>>>>> root@gryphon:~ # efibootmgr -v >> >>>>>>>>> efibootmgr: efi variables not supported on this system. root? >> >>>>> kldload >> >>>>>>>> efirt? >> >>>>>>>>> root@gryphon:~ # kldload efirt >> >>>>>>>>> kldload: can't load efirt: module already loaded or in kernel >> >>>>>>>>> >> >>>>>>>>> which I don't understand. >> >>>>>>>>> >> >>>>>>>>> I'm going to rebuild the kernel (currently GENERIC) and see if >> that >> >>>>>>>> allows >> >>>>>>>>> me to load efirt / use efibootmgr. >> >>>>>>>>> >> >>>>>>>>> In the meantime, I should be very grateful for any advice. >> >>>>>>>>> >> >>>>>>>>> ( Currently booting using a 11-RELEASE memstick image and >> dropping >> >>>>> into >> >>>>>>>> its >> >>>>>>>>> loader to get to the installed 12-STABLE ). >> >>>>>>>>> >> >>>>>>>>> /Harry >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> freebsd-current@freebsd.org mailing list >> >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >>>>>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@= f >> >>>>>>>> reebsd.org" >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Harry Newton >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Harry Newton >> >>>>>> _______________________________________________ >> >>>>>> freebsd-current@freebsd.org mailing list >> >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >> >>>>> reebsd.org" >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Harry Newton >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Harry Newton >> >>> >> >> >> >> >> >> >> >> -- >> >> Harry Newton >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to " >> freebsd-current-unsubscribe@freebsd.org" >> >> > > > -- > Harry Newton >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr_rZSUpLfWGd=CjOYEx4g%2BMrdvOgDqbrchV1DCHm4VjA>