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_at_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() call > does not return. > > /H > > On 24 October 2018 at 07:32, Toomas Soome <tsoome_at_me.com> wrote: > >> >> >> > On 24 Oct 2018, at 00:51, Kyle Evans <kevans_at_freebsd.org> wrote: >> > >> > Hi, >> > >> > I suspect 4th vs. lua has no impact here, given the output shown -- >> > can you throw one of the installer images [0] on some removable media >> > and give that a shot for booting? If that works, we can explore UEFI >> > variables from there. >> > >> >> >> Yes, thats my guess too, my guess is that since in general the uefi boot >> is working, in this case it has to be some corner case, and I would start >> checking with boot variable related code; specifically, I’d suggest to >> patch (temporarily) the find_currdev() in efi/loader/main.c to set >> do_bootmgr = false and see if that will fix the boot. Then we can explore >> what is happening in match_boot_info() >> >> rgds, >> toomas >> >> > efibootmgr will only work on a successful UEFI boot, unfortunately- if >> > we didn't make uefi loader -> kernel transition, then we don't have >> > access to runtime services. >> > >> > Thanks, >> > >> > Kyle Evans >> > >> > [0] >> https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/ >> > >> > On Tue, Oct 23, 2018 at 4:23 PM Harry Newton <hn_at_yewbarrow.net> wrote: >> >> >> >> I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and re-made >> the >> >> binaries in /boot but this doesn't solve the problem. It did copy >> >> /boot/loader_4th.efi to /boot/loader.efi which is (according to uefi(8) >> >> which is what is called from /boot/boot1.efi and which contains the >> strings >> >> I see on the console before the hang. But it must then call / read >> >> something else and I don't think it can find it. Not sure why it >> doesn't >> >> produce an error message. I *think* it may be something to do with EFI >> >> variables, but as efibootmgr doesn't work I can't explore this, despite >> >> efirt being in the kernel. >> >> >> >> Suggestions received welcomed, and new suggestions / leads to follow >> also >> >> very much welcomed. >> >> >> >> /H >> >> >> >> >> >> On 23 October 2018 at 21:33, Harry Newton <hn_at_yewbarrow.net> wrote: >> >> >> >>> Right ... I've the binaries in /boot, freshly made. This might be a >> silly >> >>> question ... do I not need to copy them (or dd the boot1.efifat >> image) to >> >>> the EFI partition ? >> >>> >> >>> /H >> >>> >> >>> On 23 October 2018 at 21:30, Toomas Soome <tsoome_at_me.com> wrote: >> >>> >> >>>> you should have the binaries in boot - just ln (or copy) one to >> loader.efi >> >>>> >> >>>> rgds, >> >>>> toomas >> >>>> >> >>>> >> >>>> On 23 Oct 2018, at 23:22, Harry Newton <hn_at_yewbarrow.net> wrote: >> >>>> >> >>>> Yes ... so as everything is built, can I just alter >> LOADER_DEFAULT_INTERP >> >>>> in /etc/make.conf and then reinstall just the loader and boot parts >> onto >> >>>> the UEFI partition ? If so, how ? >> >>>> >> >>>> >> >>>> On 23 October 2018 at 21:17, Toomas Soome <tsoome_at_me.com> wrote: >> >>>> >> >>>>> ok, in that case I’d suggest to test out if forth based one is still >> >>>>> working - at least you can get the bootable system. And then there >> is a >> >>>>> chance to debug the lua version too (note it should be possible to >> chain >> >>>>> /boot/loader_lua.efi). >> >>>>> >> >>>>> rgds, >> >>>>> toomas >> >>>>> >> >>>>>> On 23 Oct 2018, at 23:08, Harry Newton <hn_at_yewbarrow.net> wrote: >> >>>>>> >> >>>>>> So it's got FORTH in it, but my loader is lua based, and also >> doesn't >> >>>>>> appear to read loader.rc. >> >>>>>> >> >>>>>> /H >> >>>>>> >> >>>>>> On 23 October 2018 at 21:03, Toomas Soome <tsoome_at_me.com> wrote: >> >>>>>> >> >>>>>>> hm. in that case, whats the content of /boot/loader.rc ? >> >>>>>>> >> >>>>>>> rgds, >> >>>>>>> toomas >> >>>>>>> >> >>>>>>> >> >>>>>>> On 23 Oct 2018, at 23:01, Harry Newton <hn_at_yewbarrow.net> wrote: >> >>>>>>> >> >>>>>>> If boot menu is the screen where you get the options for various >> >>>>> kernels >> >>>>>>> and the picture of the daemon head, no. It stops at the point in >> my >> >>>>> email >> >>>>>>> — though not as I said just before the kernel is loaded but in >> point >> >>>>> of >> >>>>>>> fact before the menu. >> >>>>>>> >> >>>>>>> I've also rebuilt the kernel and still can't use efibootmgr which >> is >> >>>>>>> puzzling me. >> >>>>>>> >> >>>>>>> /H >> >>>>>>> >> >>>>>>> >> >>>>>>> On 23 October 2018 at 20:56, Toomas Soome <tsoome_at_me.com> wrote: >> >>>>>>> >> >>>>>>>> Do you get boot menu? if so, press esc to get to ok prompt, then >> type >> >>>>>>>> start - if its bootfort based loader, it will load the kernel and >> >>>>> modules. >> >>>>>>>> lsmod will then list the loaded files. >> >>>>>>>> >> >>>>>>>> If the loader prompt is still usable, then next command would be: >> >>>>> boot >> >>>>>>>> >> >>>>>>>> rgds, >> >>>>>>>> toomas >> >>>>>>>> >> >>>>>>>>> On 23 Oct 2018, at 20:45, Harry Newton <hn_at_yewbarrow.net> >> wrote: >> >>>>>>>>> >> >>>>>>>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to >> 12.0-BETA1 >> >>>>>>>> r339529 >> >>>>>>>>> by source. Have a problem with booting which hangs after: >> >>>>>>>>> >> >>>>>>>>>>> FreeBSD EFI boot block >> >>>>>>>>> Loader path: /boot/loader.efi >> >>>>>>>>> >> >>>>>>>>> Initializing modules: ZFS UFS >> >>>>>>>>> Probing 5 block devices ... done >> >>>>>>>>> ZFS found the following pools: zroot >> >>>>>>>>> UFS found no partitions >> >>>>>>>>> Consoles: EFI console >> >>>>>>>>> FreeBSD/amd64 EFI loader, Revision 1.1 >> >>>>>>>>> >> >>>>>>>>> Command line arguments: loader.efi >> >>>>>>>>> EFI version 2.31 >> >>>>>>>>> EFI Firmware: American Megatrends (rev 4.654) >> >>>>>>>>> Console: efi(0) >> >>>>>>>>> Load Path: HD(4, GPT [ ... ] >> >>>>>>>>> Load Device: Pci Root [ ... ] >> >>>>>>>>> Boot Current: 0001 >> >>>>>>>>> Boot Order: 0001 [x] >> >>>>>>>>> Boot Info Path: HS(1, GPT, [ ... ] /\EFI\BOOT\BOOTX64.EFI >> >>>>>>>>> - >> >>>>>>>>> >> >>>>>>>>> So it gets into loader.efi which runs but stops I think just >> before >> >>>>>>>> loading >> >>>>>>>>> the kernel. Partitions: >> >>>>>>>>> >> >>>>>>>>> => 40 250069600 ada0 GPT (119G) >> >>>>>>>>> 40 1600 1 efi (800K) >> >>>>>>>>> 1640 1024 2 freebsd-boot (512K) >> >>>>>>>>> 2664 1432 - free - (716K) >> >>>>>>>>> 4096 4194304 3 freebsd-swap (2.0G) >> >>>>>>>>> 4198400 245870592 4 freebsd-zfs (117G) >> >>>>>>>>> 250068992 648 - free - (324K) >> >>>>>>>>> >> >>>>>>>>> and the EFI partition is FAT 12. >> >>>>>>>>> >> >>>>>>>>> I can't provide (at the moment) any output from efibootmgr: >> >>>>>>>>> >> >>>>>>>>> root_at_gryphon:~ # efibootmgr -v >> >>>>>>>>> efibootmgr: efi variables not supported on this system. root? >> >>>>> kldload >> >>>>>>>> efirt? >> >>>>>>>>> root_at_gryphon:~ # kldload efirt >> >>>>>>>>> kldload: can't load efirt: module already loaded or in kernel >> >>>>>>>>> >> >>>>>>>>> which I don't understand. >> >>>>>>>>> >> >>>>>>>>> I'm going to rebuild the kernel (currently GENERIC) and see if >> that >> >>>>>>>> allows >> >>>>>>>>> me to load efirt / use efibootmgr. >> >>>>>>>>> >> >>>>>>>>> In the meantime, I should be very grateful for any advice. >> >>>>>>>>> >> >>>>>>>>> ( Currently booting using a 11-RELEASE memstick image and >> dropping >> >>>>> into >> >>>>>>>> its >> >>>>>>>>> loader to get to the installed 12-STABLE ). >> >>>>>>>>> >> >>>>>>>>> /Harry >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> freebsd-current_at_freebsd.org mailing list >> >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >>>>>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_f >> >>>>>>>> reebsd.org" >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Harry Newton >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Harry Newton >> >>>>>> _______________________________________________ >> >>>>>> freebsd-current_at_freebsd.org mailing list >> >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_f >> >>>>> reebsd.org" >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Harry Newton >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Harry Newton >> >>> >> >> >> >> >> >> >> >> -- >> >> Harry Newton >> >> _______________________________________________ >> >> freebsd-current_at_freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to " >> freebsd-current-unsubscribe_at_freebsd.org" >> >> > > > -- > Harry Newton >Received on Fri Oct 26 2018 - 19:58:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC