> 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
>>> milan@d.o used with:
>>> https://packages.debian.org/sid/e2fslibs1.41-dev
>> 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.

> http://git.ozlabs.org/?p=yaboot.git;a=commitdiff;h=b5f28817d6d68c2cb2a3e5eaefe4633b085557b6
> 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: 
> http://git.ozlabs.org/?p=yaboot.git;a=blob;f=second/file.c;h=fd081a3010d3ba4710349144da54ac73fe23cb3f;hb=0e48da7ef41c6fc36f80f44e5e4a329000412f88#l485.
> 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