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

[Warner Losh]

On Tue, Sep 27, 2016 at 2:14 AM, Allan Jude <allanjude at freebsd.org> wrote:
> 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.

OK. Thanks Allan. Since I didn't test gel-booting, I can believe it
failed there. Please let me know if you need more help or followup.

Warner