Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Jan 2016 20:26:42 +0000
From:      Andrew Turner <andrew@fubar.geek.nz>
To:        Steven Hartland <steven@multiplay.co.uk>
Cc:        Dimitry Andric <dim@FreeBSD.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: r294248: boot stuck: EFI loader doesn't proceed
Message-ID:  <20160118202642.4f52614b@zapp>
In-Reply-To: <569CD4D6.50404@freebsd.org>
References:  <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> <20160118113411.2a4d3079@zapp> <569CD4D6.50404@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Jan 2016 12:04:38 +0000
Steven Hartland <steven@multiplay.co.uk> wrote:

> On 18/01/2016 11:34, Andrew Turner wrote:
> > On Mon, 18 Jan 2016 09:10:33 +0100
> > Dimitry Andric <dim@FreeBSD.org> wrote:
> >  
> >> On 18 Jan 2016, at 07:20, O. Hartmann <ohartman@zedat.fu-berlin.de>
> >> wrote:  
> >>> Building NanoBSD images booting off from USB Flash drives and
> >>> having two GPT partitions, booting is stuck in the UEFI loader,
> >>> presenting me with something like:
> >>>
> >>> [...]
> >>> Probing 6 block devices.....++. done
> >>>
> >>>   ZFS found no pools
> >>>   UFS found 2 partitions
> >>>
> >>> And further nothing happens. A RESET is only possible by a
> >>> hardreset - it seems the system is crashed/stuck/frozen or
> >>> something similar.
> >>>
> >>> The last images working run r293654. The issue occurs with
> >>> r294248.
> >>>
> >>> Any suggestions possible? Did I miss something?  
> >> Looks to me like fallout from the recent modularisation in r294060,
> >> and/or ZFS support in r294068.  Steven, any clue?
> >>
> >> -Dimitry
> >>  
> > I found the same issue while working on nanobsd. I'm not sure it's
> > due to the recent ZFS changes as I reverted them, but found boot1
> > still failed to load loader.efi.
> >  
> Can you update to > r294265 and test with EFI_DEBUG defined e.g.
> make buildenv -DEFI_DEBUG
> cd sys/boot/efi/boot1
> make clean
> make
> 
> Then install the new boot1.efifat to your efi partition.
> 
> Hopefully this will give some more information on what the problem
> may be.

the issue was we were caching reads from the first filesystem we looked
at. I've committed the fix in r294291 to force the code to re-read on
each filesystem it looks at.

Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160118202642.4f52614b>