From owner-freebsd-current@freebsd.org Fri Oct 26 21:58:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71D0310C9366 for ; Fri, 26 Oct 2018 21:58:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07CEA6CE23 for ; Fri, 26 Oct 2018 21:58:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2a.google.com with SMTP id k77so659893vke.12 for ; Fri, 26 Oct 2018 14:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6zlTyI7yuSOjETaweh2KiDv1j6DMK626FozdzCg0D+Q=; b=iSodRC8TT5Iu3OVTaroZkUdaoyZsW9OAxTf2dCrfKEHhgoyLSasInmTswaya6V/xbE Z+G1ylwyEr5YlZBmJjUpV75SBP2zUr0hoT44OuvvuX7iD0Ih2rk36vdHMzgzRUv5Prxt jjFt/U0xjdI07Rl/ayGGdnEx7bm7y8QpV2/VCu9qSylYlMfOXjB9uPul0H8HQxCwwXnL yKI233wj06aMkocGZ+C4N6hxUti47McMFCFRZQDxVHtwOIhVkL7GQTbVoodwZ60Ff2nb Hx+FtF1w4PEZV2Isya7bR0J3MVBUvGrMijR1NlJJC2R9n91OCz9LhoTDo8QqnRwnSlyG XixQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6zlTyI7yuSOjETaweh2KiDv1j6DMK626FozdzCg0D+Q=; b=YLuYWqXY30nGVOh0xD5ryoRp17jnD8yYBhDh262TEXAbW2b40VW/oKmj+ze+lsoSkq rd1sukREZN9lA8IHHJWXgm8w7XiTwBIJgpro0rl3tnm6eBfqp72wSUds83Y5GvzSiDnB RMGhbYD5aiVsB5GWiEhVckY0Pa4jpLQMFIQH+ISCYdUcmHDYLgrZmMwY9OT9hRFLOT6X 5+Ld4hZj3ECd/8AbMCZfgcZE+A6tDfvRHFZUsEutxbzCaUIROipyIYM/YEzlF1Zz2qYB 75sdPAu6/28AFSl6Ti/Mkget4TaFLrkXbecsFRvbM0Qw5674YZwat1B/lMgrL37TxhwL dsHQ== X-Gm-Message-State: AGRZ1gJMVhxuuxR0glnJbOyKa99KrXtOZUE0XYKFHQck8nDqCwVIqars i9FVBWsz4RzZMS9nMX7m0YsKYfjrpZnran4sJ20htw== X-Google-Smtp-Source: AJdET5e2Na/Bj8RdeVHxjDuQWlIKm86KJlaQbeXg/OWHA0qiSYtnbl7nNGgBTipO+hD3bc4aSm/tDtvBAonHt2ds5hw= X-Received: by 2002:a1f:b547:: with SMTP id e68-v6mr2398077vkf.72.1540591104076; Fri, 26 Oct 2018 14:58:24 -0700 (PDT) MIME-Version: 1.0 References: <282E6F72-6573-4F0E-81AB-25110855EBB7@me.com> <2950121D-C985-4F2E-A512-FB73CFDF48BC@me.com> <4457A5DC-A577-4782-B1E8-306236908D5D@me.com> <3A48C6FA-805E-4B36-8C7D-A98422EBC7A5@me.com> In-Reply-To: From: Warner Losh Date: Fri, 26 Oct 2018 15:58:04 -0600 Message-ID: Subject: Re: UEFI boot hangs after loader To: Harry Newton Cc: Toomas Soome , FreeBSD Current , Kyle Evans Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 21:58:25 -0000 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 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 wrote: > >> >> >> > On 24 Oct 2018, at 00:51, Kyle Evans 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 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 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 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 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 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 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 wrote: >> >>>>>> >> >>>>>>> hm. in that case, whats the content of /boot/loader.rc ? >> >>>>>>> >> >>>>>>> rgds, >> >>>>>>> toomas >> >>>>>>> >> >>>>>>> >> >>>>>>> On 23 Oct 2018, at 23:01, Harry Newton 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 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 >> 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 >