On Tue, Feb 13, 2018 at 10:16 AM, John Paul Adrian Glaubitz
>> On Feb 13, 2018, at 7:39 AM, Mark Cave-Ayland
>> <mark.cave-ayl...@ilande.co.uk> wrote:
>>> On 12/02/18 10:55, John Paul Adrian Glaubitz wrote:
>>>> On 02/12/2018 11:52 AM, Mathieu Malaterre wrote:
>>>> From the look at the error message, I thought this was the hack
>>>> firstname.lastname@example.org used with:
>>> Again, we're talking about booting the CD, not the installed system.
>>> There is no ext2/3/4 involved here. The bug you mentioned exists
>>> because Yaboot doesn't handle ext4.
>> The above package provided the key: the link error I was seeing was because
>> the default e2fslibs package only provides .so libraries. Extracting the
>> static library from the above package was enough to get my compile to
> Ok, I wasn’t paying too much attention to the linker errors. We have to
> verify then that Yaboot actually still builds on unstable.
>> Anyhow I can confirm that the bug I see is present in 1.3.17 and not 1.3.16,
>> and with the magic of git bisect I managed to isolate it down to this commit:
> I can upload a version of Yaboot today with this patch reverted provided that
> Yaboot still builds fine on unstable without the hack you used.
I call it a hack, but really this is the best long term solution there
is. Yaboot is filled with empty stub, that one had to add over and
over. Using a fixed version of e2fslib made the symptoms go away.
Please check with email@example.com for the gory details, hopefully I am not
too far from the reality. I would not spent any time on yaboot anyway.
>> The first thing to notice is that prom_claim_chunk_top() introduced in the
>> previous commit has an obvious mistake which means it allocates memory
>> outside the top of its region. This is easily fixed, but doesn't appear to
>> solve my problem.
>> Building a full debug version and stepping through with gdb shows that the
>> problem is the failure of strdup() to copy the incoming configuration here:
>> From what I can tell the malloc() succeeds, however the memory being
>> returned doesn't appear to be writeable(!). That's about as far as I managed
>> to get last night, but it might be that this particular bug is related to
>> something in the OpenBIOS memory layout.