> On Feb 13, 2018, at 7:39 AM, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
>> 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
>>> email@example.com 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.
> 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.