From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6727995572123336704 X-Received: by 2002:a17:906:ce52:: with SMTP id se18mr19894329ejb.263.1567530127572; Tue, 03 Sep 2019 10:02:07 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6402:326:: with SMTP id q6ls2004420edw.0.gmail; Tue, 03 Sep 2019 10:02:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJt7fOr5qRXJYeYEE7So8MvYMhoX0ehekx7J60LTKlvGcp5jpppRt8V522GDGqjDAPTHwg X-Received: by 2002:a50:9f42:: with SMTP id b60mr4358766edf.192.1567530126684; Tue, 03 Sep 2019 10:02:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567530126; cv=none; d=google.com; s=arc-20160816; b=l6bRoU6ciZcNwuKeQSVHtcndYn9CVxylB3gSbL5ZRxVp3gpp8Zrii7x5MXPFaN730J 0kQlof6+ziUNiDnTMIlvEzh0ZP0G6XFuOqMHTP/ocBbn5T2ILLqJFXBtj9hjLSinyEH2 /ZHQQZeUPEMwl/GhTVbt/pdc5E0ACq72i0/x5JysCGsYYiEiOCQAQLGxW4SqHTkauQAj N4BzWGx6D7JkFLiiKHUISj1SSdSrg/Y1ZyaI7zIlzJ1Vnb/pVldhluzaA8e5ONhs5pN4 95yoQzVH9JfwUBAGfXr1DXKXQd3MDEpHiAGv3MgAyQq0j8jm6z6Iyys0IKF13qNKOikB jDLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=70Zgk/mLnmACSchGHUyFYA3WoB8eggh29EfCvbqk5tY=; b=YVJiHeOevNjLgLujaCnV2FGyLj5sgcN0RK1KM22rA8r2WJhr/vi07qEV/jqlhsqoO7 QohmKpygnqgiFHZ4P2brPBJenrZGoEuU0SDShZSzKA+Uzhd1kkSZCdKOivxU4yxGSWfu kRbbg0XuRAo7XsXDCIW2jblA7tQbtbMNVpIBJjWk2I/qdSkf0sBBXOcndzf6qHC92+I7 k0+ZRMLRsCOCx9iE+g16D2MSz6Ht98tmt91zCPXcjvX8+iXny3oJn4rwrTILHM3dHKIk GgvP+wI41bwNE1Q8Ag6HQrJznFZbUIvyl6YdwY+8v12w1qebuhKzkbXHCShmq3odgtl2 cMKg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id d14si482611edb.4.2019.09.03.10.02.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Sep 2019 10:02:06 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x83H26OH008096 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 3 Sep 2019 19:02:06 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x83H26xx011737 for ; Tue, 3 Sep 2019 19:02:06 +0200 Subject: Re: isar-bootstrap failures with debian-buster targets To: isar-users@googlegroups.com References: <20190822144706.GA6062@yssyq.m.ilbers.de> <00b7f2ea-a868-c06e-e64f-e735482be819@siemens.com> <20190822152700.GB6062@yssyq.m.ilbers.de> <20190827043332.GJ6062@yssyq.m.ilbers.de> <5b671fed-4dbc-1beb-e9bd-3f67b1a804df@siemens.com> <20190903154447.GE6062@yssyq.m.ilbers.de> From: Jan Kiszka Message-ID: Date: Tue, 3 Sep 2019 19:02:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: Bf/gl1Qm2RJ/ 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