Re: isar-bootstrap failures with debian-buster targets

[Baurzhan Ismagulov <ibr@radix50.net>]

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?

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


With kind regards,
Baurzhan.