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