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 NewtonReceived on Tue Oct 23 2018 - 19:23:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC