From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6591699875972251648 X-Received: by 2002:a1c:200f:: with SMTP id g15-v6mr403852wmg.1.1534948642074; Wed, 22 Aug 2018 07:37:22 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:aa82:: with SMTP id h2-v6ls453306wrc.5.gmail; Wed, 22 Aug 2018 07:37:21 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaDTz3ctdagMCOf7lnx9dKXuLGIGJhrV27/ABlFSguKGoXU8y7Zf1I0l97k2li40pLjj5rI X-Received: by 2002:adf:9d1e:: with SMTP id k30-v6mr921104wre.20.1534948641531; Wed, 22 Aug 2018 07:37:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534948641; cv=none; d=google.com; s=arc-20160816; b=YhMQJB8FaCxOzPVry54z/YzbJbF3ye4L746jOb66joiDrsIKXrixnqsAKw565+dCy9 HlZh9NWbflyWWQ8SOS1kaxm24JkIKdiWvlawGMLQU94Gakiapy1+u2M/ha6fAnYEOxxm tlte210VwoUoBcWLly6HJFJBIczwDAiVHwnj47NOR+PO+VutXDBoldJ1Za9GGUtyG1GM q7lkVhQOMnVvGUBI7YgQnwQaBrBsdxe73bUDv3Vmf1DCA8yu9IWKsct/3FgQDduJCu68 NvzMfnmC1l1SkE7PGuoYcQX7Ls5XexVfUDM0C85/JP10lORkY8556mEchVFtsPJpyn27 xtPA== 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 :arc-authentication-results; bh=X1N2/CY5S8SOTFQw9chG1bDh7JhWSlt9cIMus+xbLMg=; b=HPmr+5UTKjOoK53pUM0ZHF1rlvH3MFhQiJdB+M3OwkUP8SA9BxLHNwla9u/IiJIcye lboaJR6+vyUCDl+5x8iShEsvaaYFE+f9TymXO51iCkB99rgDV8ZmjFG6Dvxx5Mg2jbjX 4i64hEYJ4Y/eubuagQRipFGMfdQnLKWMFsSMzEA9HarlyVM781ID418fqT5bPzjTrscO 6du6Xkn2u03djrH0SxhUPG6OF3xY6hpL8BWPmhOPrxgWrtF3YQvADKQzm4Un+z9rNAVj K6hncPFeKWeqFMku+naKBgLxoTwF7ZcBGL40WP26AGz/6fb2/vtevTCORbW+tJHj1LRY rfAw== 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 Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id e18-v6si86272wrp.1.2018.08.22.07.37.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 07:37:21 -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 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w7MEbK5t029319 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Aug 2018 16:37:20 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id w7MEbKjh026528; Wed, 22 Aug 2018 16:37:20 +0200 Subject: Re: Minimizing isar-image-base To: Alexander Smirnov , isar-users References: <0228b199-d672-6610-0180-c8a84542366c@siemens.com> From: Jan Kiszka Message-ID: <4db9adeb-b649-2d51-0e91-28d781297cf3@siemens.com> Date: Wed, 22 Aug 2018 16:37:19 +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; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: jc1ve1Affjch Hi Alex, On 2018-08-21 21:36, Alexander Smirnov wrote: > Hi Jan, > > On 20.08.2018 10:22, Jan Kiszka wrote: >> Hi all, >> >> a couple of questions on what we pre-install into the de-facto >> standard base image for everything that builds on Isar: >> >> - Why do we pre-install init, but only for >= stretch? >> > > IIRC, for jessie and wheezy, the list of pre-installed packages was > created based on attempt to boot the board. So it's just a result of > experiment, no references to official Debian sources. init is needed (just tried that), but I think it should go into the distro conf because all Debian-based images need it, and only Raspian seems to do something else. > >> - Why do we pre-install dbus? >> > > Again, IIRC, without dbus there was dirty boot log in QEMU, some > services failed to start. I'll recheck that with stretch. > >> - Can we make apt optional? Installing it as transient package by >>    default, e.g. What would happen if a downstream image then puts it >>    into PREINSTALL again? Should we filter IMAGE_TRANSIENT_PACKAGES >>    against IMAGE_PREINSTALL? > > I could suppose how apt went to isar-image-base recipe, initially it was > a copy of buildchroot one. So nobody actually cares about the list of > packages, there was only one requirement - no error and warnings during > image boot in QEMU. > > In buildchroot apt is needed to populate the dependencies. > > With current Isar implementation the apt is a must package for image. > Let me explain why. Below is the whole chain to generate image: > > 1. At first, isar-debootstrap is called. This recipe fetches minimal > *pure* Debian suite for specified architecture. It's stored in > tmp/deploy folder. > 2. Image generation is started from copying this pre-fetched suite to > work folder. > 3. Then you chroot to this *pure* minimal suite. > 4. And finally all the additional packages in pre-install list are > installed via apt-get. > > So, the only way for current architecture - remove apt in post-build task. Right, this is what I had in mind. I think we already have the tooling for that, don't we? > > Hope this a bit clarifies your questions. > >> >> Alternatively, we could define some isar-image-tiny that removes >> packages from the base image, possibly also some that debootstrap >> pulls in. >> >> Ideas, suggestions? >> > > I'd support you with this idea. For example sometimes I really need > minimal QEMU image with just console, let's say 10-20MB of disk space > and 2-3 minutes to build it. > > But my proposal will be to start from requirements - which packages > should go to tiny image and why. Otherwise we will have the same > questions as above in 1-2 years :-) Sure. I think the key requirement is that the system is booting and not throwing errors (otherwise, we would have to resolve that errors differently - or keep the package). Here is the list of packages on x86-64 with current isar-base and a custom kernel (dpkg --get-selections | cut -f 1): adduser apt base-files base-passwd bash bsdutils coreutils cpio dash dbus debconf debian-archive-keyring debianutils diffutils dmsetup dpkg e2fslibs:amd64 e2fsprogs findutils gcc-6-base:amd64 gpgv grep gzip hostname init init-system-helpers initramfs-tools initramfs-tools-core klibc-utils kmod libacl1:amd64 libapparmor1:amd64 libapt-pkg5.0:amd64 libattr1:amd64 libaudit-common libaudit1:amd64 libblkid1:amd64 libbz2-1.0:amd64 libc-bin libc-l10n libc6:amd64 libcap-ng0:amd64 libcap2:amd64 libcomerr2:amd64 libcryptsetup4:amd64 libdb5.3:amd64 libdbus-1-3:amd64 libdebconfclient0:amd64 libdevmapper1.02.1:amd64 libexpat1:amd64 libfdisk1:amd64 libgcc1:amd64 libgcrypt20:amd64 libgpg-error0:amd64 libidn11:amd64 libip4tc0:amd64 libklibc libkmod2:amd64 liblz4-1:amd64 liblzma5:amd64 libmount1:amd64 libncurses5:amd64 libncursesw5:amd64 libpam-modules:amd64 libpam-modules-bin libpam-runtime libpam0g:amd64 libpcre3:amd64 libprocps6:amd64 libseccomp2:amd64 libselinux1:amd64 libsemanage-common libsemanage1:amd64 libsepol1:amd64 libsmartcols1:amd64 libss2:amd64 libstdc++6:amd64 libsystemd0:amd64 libtinfo5:amd64 libudev1:amd64 libustr-1.0-1:amd64 libuuid1:amd64 linux-base linux-image-cip-amd64(orsomeotherkernel) locales login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl-base procps sed sensible-utils systemd systemd-sysv sysvinit-utils tar tzdata udev util-linux zlib1g:amd64 I think, besides apt, dbus and the kernel, everything comes from debootstrap's selection. Let's see what happens if I remove apt... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux