Adrian, On Tue, Feb 13, 2018 at 10:16 AM, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > >> 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.
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. >> 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. > Thanks
