Re: UEFI boot hangs after loader

[Warner Losh]

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() call
> 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 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  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  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’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  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 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  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.
>> 

Re: UEFI boot hangs after loader

[Harry Newton]

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  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 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  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  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’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  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 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  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  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 

Re: Facing kernel panic during early boot from 12.0 ALPHA9

[Mark Johnston]

On Fri, Oct 26, 2018 at 07:35:14PM +0530, Rajesh Kumar wrote:
> Hi Mark,
> 
> Thanks for the inputs. With the two patches you pointed out, I could able
> to compile from current, install and boot properly without any panic.
> 
> Will these changes be taken into stable/12 and be part of upcoming 12.0
> releases?

Yes, I will attempt to get them into 12.0.

> On Thu, Oct 25, 2018 at 11:01 PM Mark Johnston  wrote:
> 
> > On Tue, Oct 23, 2018 at 07:10:02PM +0530, Rajesh Kumar wrote:
> > > Hi Mark,
> > >
> > > > From the db> prompt, could you please run "show page" and "show pageq",
> > > > and post the output?
> > >
> > > The system gets hung when it runs to db prompt. I only have the option to
> > > force shutdown at that point.  Is there any other way, I can collect what
> > > you need?
> >
> > Just a followup for the list: the issue should be fixed by the
> > following two patches:
> > https://reviews.freebsd.org/D17418
> > https://reviews.freebsd.org/D17704
> >
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

[Oleg Lelchuk]

libtorrent still can't be built with the new openssl

On Sat, Oct 13, 2018 at 4:40 AM Ronald Klop  wrote:

> On Sat, 13 Oct 2018 02:00:16 +0200, Don Lewis 
> wrote:
>
> > On 11 Oct, Don Lewis wrote:
> >> On 11 Oct, Don Lewis wrote:
> >>> On 11 Oct, freebsd.curr...@clogic.com.ua wrote:
>  On 2018-10-10 06:14, Michael Butler wrote:
> > On 10/9/18 5:34 PM, Glen Barber wrote:
> >> OpenSSL has been updated to version 1.1.1 as of r339270.
> >>
> >> It is important to rebuild third-party packages before running:
> >>
> >>  # make -C /usr/src delete-old && make -C /usr/src delete-old-libs
> >>
> >> Thank you for your patience while this work was in progress, and
> >> thank
> >> you to all involved for their hard work in getting things ready for
> >> this
> >> update.
> >
> > So far, I've found two ports that will no longer build. They are:
> >
> > net-mgmt/net-snmp
> > security/opencryptoki
> >
> > I simply chose those that were linked to /usr/lib/libssl.so.8 where
> > the
> > openssl update creates libssl.so.9. There may be more I haven't found
> > yet,
> >
> >   imb
> 
>  You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to
>  use openssl from ports.
>  Anyway, I think apps from ports need to use openssl from ports.
> >>>
> >>> I've been doing this for a long time, but I still see a fair amount of
> >>> breakage with the new base OpenSSL.  I suspect that some ports are
> >>> incorrectly stumbling across the new bits in base even though they
> >>> shouldn't be looking there.
> >>
> >> security/p5-Net-SSLeay is hardwired to use base OpenSSL, so changing the
> >> default version can't be done to unbreak p5-IO-Socket-SSL.
> >>
> >> devel/libsoup appears to allow the OpenSSL version to be set, but
> >> doesn't
> >> have an option for GSSAPI, so it attempts to use base GSSAPI with ports
> >> OpenSSL which is not a valid combo.
> >>
> >> emulators/virtualbox-ose is hardwired to use base OpenSSL.
> >
> > I now think the problem with virtualbox-ose is not the port.  Rather it
> > is the fact that that the base libssl.so and the libssl.so installed by
> > the security/openssl have the same shared library version number even
> > though they are radically different OpenSSL versions.
>
>
> I added this to libmap.conf:
> cat /etc/libmap.conf
> # $FreeBSD: head/libexec/rtld-elf/libmap.conf 338741 2018-09-18 00:25:00Z
> brd $
> includedir /usr/local/etc/libmap.d
> libssl.so.8 libssl.so.9
> libcrypto.so.8  libcrypto.so.9
>
> This made pkg run again. And now I'm waiting for the next pkg build to
> run
> pkg upgrade -f and upgrade everything.
> I guess that will solve all issues.
>
> Ronald.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1

[Rebecca Cran]

On 10/26/18 10:48 AM, Dag-Erling Smørgrav wrote:

Rebecca Cran  writes:

After installing 12.0-BETA1, on the first boot I noticed a warning
about $local_unbound_tls not being set properly.

Ah, I should probably have added it to /etc/defaults/rc.conf.  Can you
do that (just set it to “no”) and let me know if it helps?



That worked: the warning disappeared.


--

Rebecca

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1

[Dag-Erling Smørgrav]

Rebecca Cran  writes:
> After installing 12.0-BETA1, on the first boot I noticed a warning
> about $local_unbound_tls not being set properly.

Ah, I should probably have added it to /etc/defaults/rc.conf.  Can you
do that (just set it to “no”) and let me know if it helps?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Facing kernel panic during early boot from 12.0 ALPHA9

[Rajesh Kumar]

Hi Mark,

Thanks for the inputs. With the two patches you pointed out, I could able
to compile from current, install and boot properly without any panic.

Will these changes be taken into stable/12 and be part of upcoming 12.0
releases?


On Thu, Oct 25, 2018 at 11:01 PM Mark Johnston  wrote:

> On Tue, Oct 23, 2018 at 07:10:02PM +0530, Rajesh Kumar wrote:
> > Hi Mark,
> >
> > > From the db> prompt, could you please run "show page" and "show pageq",
> > > and post the output?
> >
> > The system gets hung when it runs to db prompt. I only have the option to
> > force shutdown at that point.  Is there any other way, I can collect what
> > you need?
>
> Just a followup for the list: the issue should be fixed by the
> following two patches:
> https://reviews.freebsd.org/D17418
> https://reviews.freebsd.org/D17704
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DRM: radeonkms no longer usable following a switch to stable, FreeBSD 12.0-BETA1

[Graham Perrin]

On 22/10/2018 04:34, Graham Perrin wrote:
> …
> /usr/local/bin/xauth: (stdin):1:  bad "remove" command line
> /usr/local/bin/xauth: (stdin):2:  bad "add" command line
> /usr/local/bin/xauth: (stdin):1:  bad "remove" command line
> /usr/local/bin/xauth: (stdin):2:  bad "add" command line
> …
>
> What next? Any suggestions?

tl;dr worked around by stepping away from stable; I stepped up to 13.0-CURRENT.

Summary information:  
.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"