> On 24 Oct 2018, at 10:13, Harry Newton <hn_at_yewbarrow.net> 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 <kevans_at_freebsd.org <mailto: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. > > 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/ <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:freebsd-current_at_freebsd.org> mailing list > > >>> >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current> > > >>> >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_f > > >>> >>> reebsd.org <http://reebsd.org/>" > > >>> >>> > > >>> >>> > > >>> >> > > >>> >> > > >>> >> -- > > >>> >> Harry Newton > > >>> >> > > >>> >> > > >>> >> > > >>> > > > >>> > > > >>> > -- > > >>> > Harry Newton > > >>> > _______________________________________________ > > >>> > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> mailing list > > >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current> > > >>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_f > > >>> reebsd.org <http://reebsd.org/>" > > >>> > > >>> > > >> > > >> > > >> -- > > >> Harry Newton > > >> > > >> > > >> > > > > > > > > > -- > > > Harry Newton > > > > > > > > > > > -- > > Harry Newton > > _______________________________________________ > > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org <mailto:freebsd-current-unsubscribe_at_freebsd.org>" > > > > -- > Harry NewtonReceived on Wed Oct 24 2018 - 14:55:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC