Re: isar-bootstrap failures with debian-buster targets

[Jan Kiszka <jan.kiszka@siemens.com>]

On 03.09.19 18:23, [ext] Jan Kiszka wrote:
> On 03.09.19 17:44, Baurzhan Ismagulov wrote:
>> On Tue, Aug 27, 2019 at 09:10:21AM +0200, Jan Kiszka wrote:
>>>> FWIW, this also occurred on an internal Jenkins machine (stretch host, stretch
>>>> workspace, no docker). This happening only with buster target, we have only two
>>>> candidates: bug in qemu or bug Debian, no?
>>>
>>> Yeah, stretch host does not seem to make a difference. I've seen it
>>> meanwhile also with the stretch-based kas image.
>>>
>>> Should we try to file bug? Question is: against which component? debootstrap?
>>
>> I think the best candidate would be the package containing the binary that
>> fails -- presumably apt.
>>
>> For me, the questions are:
>>
>> 1. Can we rule out qemu in some way?
>>
>> 2. Is it reproducible in a simple way?
> 
> Well, for me at least: Just started the OrangePi Zero build of jailhouse-images, 
> which is now buster-based, and it failed again. I suspect I can trigger this now 
> for a couple of times in a row.
> 
>>
>> I.e., ideally, it should be reproducible from the command line on the host
>> natively, otherwise we'll probably end up just having reported the problem --
>> which is admittedly also necessary.
>>
> 
> That's not where I am yet, only seeing it on my SUSE host.
> 
>>
>> That said, the links below (at least one of which appears to be an automated
>> translation from English) refer to the same problem in the context of
>> Singularity, which would point rather into the direction of qemu. What is
>> actually the size of RAM available to the guest in our case? Apt has the
>> history of requiring considerable amounts of RAM.
>>
>> 1. https://issue.life/questions/51632062
>> 2. https://bug200.com/post/51632062
>>
> 
> Well, we only saw the issue with armhf and mipsel so far, right? I did a lot of 
> arm64 builds recently on the very same machine, which are qemu-based, and none 
> failed this way. I do not know how much virtual memory qemu-user leaves the 
> application, but it is already constrained to 32-bit.
> 
> Hmm, there some tunables to qemu-user. I'm currently playing with 
> QEMU_RESERVED_VA, will keep you posted...
> 

Nope, would have been too easy: Even QEMU_RESERVED_VA=4000M, which is close to 
the maximum, makes no difference.

I also tried to reproduce outside of the container, but that did not work so 
far. At least, that reduces the probability that the kernel is the key.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux