From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6727995572123336704 X-Received: by 2002:a19:8017:: with SMTP id b23mr20320488lfd.132.1567525493941; Tue, 03 Sep 2019 08:44:53 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:3608:: with SMTP id d8ls2006338lja.0.gmail; Tue, 03 Sep 2019 08:44:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqzoyY5y/gO9XYTkGBZpulazDbvg6EqLOKUT/+YEZgPOkA51WSrYoBaZmr0R9t/GeU+MnlxP X-Received: by 2002:a2e:3201:: with SMTP id y1mr10148078ljy.177.1567525493297; Tue, 03 Sep 2019 08:44:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567525493; cv=none; d=google.com; s=arc-20160816; b=yOUta0IL/m77Y5voTVtABi3JeCIBmJga2DJFz61lA10r0TvSfMmOEFsFQoPDvKF9mW ERZiyavuQWhuJGEqcJ1JS5tNC9lV/XCgVM8Q8ZaLAL2n4yc6AQWHc6d77Pz0GlkZoEPj IKkJAY0GOWVR5qbErGXAccRU9B6tWvVRxOXMBbhQAHyvJHj+tg1zehYOyLupomoHtb6O LCZNxO0WMyh7qoYUcv1raSSaGbo6TEXN16xrbykw1L+8uawjOhnHUZO6rZHk+LG02wp8 TEizEOTyHJ2RgGuAqcIPYDC9PoTszXNaBGkHrMvOQ4KpEwYiepp63x4I03uuyseEcQ0b WVEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=4lheMg1n3PoKk+D0nSXBSvDALK5rLROw9PVSTtRgKm8=; b=KEYW38ya4VDmCRlokNfpkKt9+3V7UoYR6J3hwuEynSaDWnS4SDHtpFWgBDwl5YGr1i EKso7uHvSYFB1bHHqGLGtxOPbPmJi9J3ACiLuCSV3OjkoGdDRaU7uKKfsZp3B2yhvHH/ KCpgVUtCZdeCYo6aj7QHo9w1FP9po04xBzSWp9g6cZFkZhqKr9jxLpOVnrwhBJ89o410 GmG67ShrHhz5gHWLEX++hqax0hKvpoCt1T4Ioju9BLAv6jxl51u3hxNIEuW1YlA8N1uI r+YArCQdecuY1cSHLyU+8kAo8kBQiUNjJuhFCHpKjtuUyqMTH5KENQpcY/1wELZDmwyC gLpw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id o30si560010lfi.0.2019.09.03.08.44.53 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Sep 2019 08:44:53 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x83Fim7V011972 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 3 Sep 2019 17:44:49 +0200 Date: Tue, 3 Sep 2019 17:44:47 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: isar-bootstrap failures with debian-buster targets Message-ID: <20190903154447.GE6062@yssyq.m.ilbers.de> Mail-Followup-To: isar-users 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b671fed-4dbc-1beb-e9bd-3f67b1a804df@siemens.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: X2GiKhiA60uP 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.