svn commit: r305353 - in head/sys/boot: i386 i386/boot0 i386/boot2 i386/btx/btx i386/btx/btxldr i386/cdboot i386/gptboot i386/gptzfsboot i386/mbr i386/pmbr i386/pxeldr i386/zfsboot pc98 pc98/boot0 ...

[Allan Jude]

On 2016-09-27 01:02, Warner Losh wrote:
> On Mon, Sep 26, 2016 at 11:00 AM, John Baldwin <jhb at freebsd.org> wrote:
>> On Saturday, September 24, 2016 02:56:05 PM Warner Losh wrote:
>>> On Fri, Sep 23, 2016 at 4:17 PM, Allan Jude <allanjude at freebsd.org> wrote:
>>>> On 09/03/16 11:26 AM, Warner Losh wrote:
>>>>> Author: imp
>>>>> Date: Sat Sep  3 15:26:28 2016
>>>>> New Revision: 305353
>>>>> URL: https://svnweb.freebsd.org/changeset/base/305353
>>>>>
>>>>> Log:
>>>>>   Don't use -N to set the OMAGIC with data and text writeable and data
>>>>>   not page aligned. To do this, use the ld script gnu ld installs on my
>>>>>   system.
>>>>>
>>>>>   This is imperfect: LDFLAGS_BIN and LD_FLAGS_BIN describe different
>>>>>   things. The loader script could be better named and take into account
>>>>>   other architectures. And having two different mechanisms to do
>>>>>   basically the same thing needs study. However, it's blocking forward
>>>>>   progress on lld, so I'll work in parallel to sort these out.
>>>>>
>>>>>   Differential Revision: https://reviews.freebsd.org/D7409
>>>>>   Reviewed by: emaste
>>>>>
>>>>
>>>> This breaks booting on my Lenovo laptop. The BTX client crashes and
>>>> dumps the registers.
>>>>
>>>> Reverting this commit solved it.
>>>>
>>>> Is there something I can do to help investigate this?
>>>
>>> I assume you bisected all boot loader changes and it fails across this
>>> commit? If not, that's the first step.
>>>
>>> If so, perhaps the place to start is with the dump?
>>
>> The dump is a good place to start, but it would also be useful to know
>>
>> 1) Which stage dies (e.g. can you get into the gptboot/boot2 prompt meaning
>>    it it is probably btxldr.S dying trying to parse a.out header from
>>    /boot/loader vs are you dying before that point meaning it is in boot1.S
>>    or gptldr.S)?
> 
> Yes. This is absolutely critical. Until we know what dies, what the
> trace backs are, what options were in effect and how the binaries were
> broken there's little more that I can do because it works for me
> everywhere I've tried it.
> 
>> 2) Once we know which stage, it would be good to compare the a.out headers
>>    and possibly the contents of the relevant binaries.  The aforementioned
>>    .S files all parse the a.out header in assembly as well as the BTX
>>    header (they assume that BTX itself is present in the bits loaded from
>>    disk immediately followed by the binary header).  That code isn't very
>>    flexible and it doesn't seem far fetched for this change to break it.
> 
> I just wonder why it works on the amd64 servers and laptops, the i386
> laptops and in qemu for me,  but fails for the OP. If it broke a.out,
> I contend it would break for everybody since a.out headers are 'hit
> dinosaur over the head' level of complexity and subtly.  While I don't
> doubt there's a problem, I suspect it is very specific to a particular
> set of laptops that were on the edge before and this kicks us over the
> edge just enough to stomp on some area that was protected before.
> 
> Warner
> 

It works fine for me with a regular boot, but when booting a GELI
encrypted disk, is dies.

It is in boot2, before it reads the loader.

Specifically, it seems to be at the call to: enc_xform_aes_xts.reinit
[opencrypto aes_xts_reinit()]

Now that I am back home, I'll try to narrow it down further, and look at
the difference between gptzfsboot compiled with and without the
different LD flags.

It works perfectly fine with the makefile changes reverted.

-- 
Allan Jude