Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
Adrian,
On Tue, Feb 13, 2018 at 10:16 AM, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
>> On Feb 13, 2018, at 7:39 AM, Mark Cave-Ayland <mark.cave-ayland@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
Reply to: