On Tue, Feb 13, 2018 at 10:16 AM, John Paul Adrian Glaubitz
<> wrote:
>> On Feb 13, 2018, at 7:39 AM, Mark Cave-Ayland 
>> <> 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
>>>> milan@d.o 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 
>> succeed.
> 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 milan@d.o 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.
>> ATB,
>> Mark.


Reply via email to