From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6546059049526362112 X-Gmail-Labels: Topic type: DISCUSSION X-Received: by 2002:a19:d103:: with SMTP id i3-v6mr30355lfg.2.1524149829630; Thu, 19 Apr 2018 07:57:09 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.110.15 with SMTP id j15ls757618ljc.1.gmail; Thu, 19 Apr 2018 07:57:09 -0700 (PDT) X-Google-Smtp-Source: AIpwx48q9vanKt74G60WBNE+QhVfi469D8JlyA56sZIL0tgbivYRWS1JEj9BWfLCBUFj/Q2hl0ks X-Received: by 10.46.151.80 with SMTP id f16mr229154ljj.4.1524149828997; Thu, 19 Apr 2018 07:57:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524149828; cv=none; d=google.com; s=arc-20160816; b=g648EJrRXvtDvI5JzDd0gaq1DSLxUVZqcEC0gx2nbFk/Oa6flatz8S4GviFbyCqhyO TCZ1L9dNeBLZ8Fo4IELlao2dD5zxPqk9NjEAipkVRbOEX/UsR6uj1BfN75etV1rjmQKU YrvJpF0HT0txtT99eH2KNn/aBJ8MgIyH77zcEg1ghQbhATLezEQvVPj4zLDsfWwxjkG0 dtEPJKg3xGyLcdb/Y1k9BxJKHiLyfjqoJsXpfCUIymvIICODDrakBY5NKE63wWS/BpJJ u02cXsRYQJX//rNnmLSMvieBaVn6vzE8bINGDHQk8/FUDCoDX/OAnDeTVmw3eJ0I25lD R88Q== 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:openpgp:from:references:cc:to:subject :arc-authentication-results; bh=aQJjvxt4JXnuWEkJe+n6LE8vTl4ZuDOgU2kHry0wGZU=; b=xi0hG1QnXdEeLF5ah1UHbgnT66xpcgrds9PEE98RfJ9ATnnCYvf7khGhHskjC6Ghei kUeBsBmckrxo0+SyA5DmQk0Ll7ARgp1scZSb+yYmjpRVb230H6ohUswr6lnXjDFGL33H f2zIIwzoeoDV+kBrg/C6erNHOgAsZOTKe87d3T/2NCqBUBklqFB+aSfsAsjjaFpKHXLc cYwWA0BBP62jbd8YbqYJVeMyZDXzdl19gp9QlG8wfqHr/LYPSNGL6Tsh8ONSRe2U27Cg ACD9J1gTJ/q/T7ADC6zsoc1CDTXYVJtuNVhD6yglD+dQDq2OThKfwj3PZKqUbaBJOq9l Yjkw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id u13-v6si48440lff.5.2018.04.19.07.57.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 07:57:08 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w3JEv8hQ005158 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Apr 2018 16:57:08 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w3JEv7Yc017110; Thu, 19 Apr 2018 16:57:08 +0200 Subject: Re: building custom kernel fails To: Jon Nettleton , Alexander Smirnov Cc: isar-users References: <20180419111904.7436c6a0@mmd1pvb1c.ad001.siemens.net> <20180419123812.7c8f9a0f@mmd1pvb1c.ad001.siemens.net> <20180419154713.35046708@mmd1pvb1c.ad001.siemens.net> From: Jan Kiszka Openpgp: preference=signencrypt Message-ID: <1f25fc5c-77fe-2d9b-7c9b-62ce2e3d136e@siemens.com> Date: Thu, 19 Apr 2018 16:57:07 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 8NhSmrSgcH4O On 2018-04-19 16:40, Jon Nettleton wrote: > > On Thu, Apr 19, 2018 at 4:35 PM Alexander Smirnov > wrote: > > On 04/19/2018 05:26 PM, Jon Nettleton wrote: > > > > On Thu, Apr 19, 2018 at 3:47 PM Henning Schild > > > >> wrote: > > > >     Am Thu, 19 Apr 2018 13:27:36 +0000 > >     schrieb Jon Nettleton >>: > > > >      > On Thu, Apr 19, 2018 at 12:38 PM Henning Schild > >      > > >> > >     wrote: > >      > > >      > > Am Thu, 19 Apr 2018 09:33:28 +0000 > >      > > schrieb Jon Nettleton > >     >>: > >      > > > >      > > > On Thu, Apr 19, 2018 at 11:19 AM Henning Schild > >      > > > > >      >> wrote: > >      > > > > >      > > > > Am Thu, 19 Apr 2018 00:32:21 -0700 > >      > > > > schrieb > >>: > >      > > > > > >      > > > > > I am now building a custom debian package from our > kernel > >      > > > > > sources, the kernel compile goes fine.  The deb-pkg is > >      > > > > > failing because the number of files passed to xarg > is too > >      > > > > > long. > >      > > > > > > >      > > > > > Error message is. > >      > > > > > > >      > > > > > 2018-04-19 07:11:17 - INFO     - | Using default > distribution > >      > > > > > of 'unstable' in the changelog > >      > > > > > 2018-04-19 07:11:17 - INFO     - | Install > lsb-release or set > >      > > > > > $KDEB_CHANGELOG_DIST explicitly > >      > > > > > 2018-04-19 07:11:17 - INFO     - | /usr/bin/xargs: > md5sum: > >      > > > > > Argument list too long > >      > > > > > 2018-04-19 07:11:17 - INFO     - | > >      > > > > > scripts/package/Makefile:90: recipe for target > 'deb-pkg' > >      > > > > > failed 2018-04-19 07:11:17 - INFO     - | make[1]: *** > >      > > > > > [deb-pkg] Error 126 2018-04-19 07:11:17 - INFO     - | > >      > > > > > Makefile:1347: recipe for target 'deb-pkg' failed > >      > > > > > 2018-04-19 07:11:17 - INFO     - | make: *** [deb-pkg] > >     Error 2 > >      > > > > > 2018-04-19 07:11:17 - INFO     - | WARNING: exit code 2 > >     from a > >      > > > > > shell command. > >      > > > > > > >      > > > > > looks like on large kernel builds the file lists > will need to > >      > > > > > be broken up. > >      > > > > > > >      > > > > > >      > > > > I have seen that before. It happens in buildchroot > when using > >      > > > > qemu-arm-static binfmt magic. Something in that chain > seems to > >      > > > > cause problems for very long argument lists. > >      > > > > In my case it was a "make clean" and i removed the > files from > >      > > > > outside the buildchroot. But since it now happened > again it is > >      > > > > probably something worth looking into. > >      > > > > > >      > > > > Henning > >      > > > > > >      > > > > >      > > > Oh interesting.  I wonder if this has something to do > with the > >      > > > binfmt support in CentOS vs Debian.  I will look into > it and > >      > > > report back. > >      > > > >      > > I saw it on Gentoo building in a debian docker container. > So i > >     guess > >      > > the problem might be related to the binfmt wrapping in > general, not > >      > > distro specific. > >      > > > >      > > Henning > >      > > > >      > > > >      > It looks like that was the problem.  I just went through > the pain of > >      > building qemu 2.9.1 for Centos7...and all the dependencies > that were > >      > needed by it.   That has fixed the custom kernel build issues. > >      > Thanks for all the pointers. > >      > > >      > I would say for now if anyone asks you can consider Centos > 7 a no > >      > go.  If there is interest I may add a build to Copr for > other users. > >      > Fedora 26 and newer should be fine. > > > >     Isar calls "random" sudos all over the place. Someone actually > allowing > >     this on a productive system surprises me ... to say the least. > > > >     My advise it to use a VM or container to run Isar in, and in > that case > >     going for Debian9 is easy. One example, used by many of us, is > >     https://hub.docker.com/r/kasproject/kas-isar/ > > > >     Henning > > > > > > Yes that is what I am  using to build with.  I can only imagine > that the > > newer build of qemu brings in a configuration to the host os that is > > required for things to build properly. > > > > My host OS is Fedora for many years, so I use chroot to work with > Debian > environment (for Isar as well): > > $ sudo debootstrap jessie debian8-isar/ http://ftp.debian.org/debian > $ sudo chroot debian8-isar > > This also could be an option. > > Alex > > > yes very true, thanks.  I am specifically interested in using docker > containers to build images so I can bring up a build farm for customers > that want to build production images.  My main builder is x86_64 however > I am looking forward to comparing the performance of that machine vs our > "new" ARM64 server boards. We are looking into very similar questions. We have a build infrastructure ready based on gitlab-ci (you can find the yml file in Isar, in fact), and we would also be happy to recommend public CI like Travis or Shippable for Isar builds. As pointed out in the other branch of this thread, there are some challenges preventing unprivileged builds right now. That is at least the need to mount images or paths inside the container and the need to configure binfmt according to Debian expectations. If you have a CI system where you can spawn a VM on each build and that VM can run a (privileged) Docker container, you could move forward already despite of this. Would be our plan B here, but it's not set up with three clicks either. >  Of course I can run run debootstrap within > the container first, but since CIP is using Kas I also want to use that > infrastructure. Using kas quickly pays off when it come to managing sources and versions of your dependencies, or providing your users a way to put a layer on top of your released configuration. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux