public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alexander Smirnov <asmirnov@ilbers.de>,
	isar-users <isar-users@googlegroups.com>
Subject: Re: Minimizing isar-image-base
Date: Wed, 22 Aug 2018 16:37:19 +0200	[thread overview]
Message-ID: <4db9adeb-b649-2d51-0e91-28d781297cf3@siemens.com> (raw)
In-Reply-To: <aae8703b-c573-e1f8-e6a1-32a95ad4961e@ilbers.de>

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

  reply	other threads:[~2018-08-22 14:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-20  7:22 Jan Kiszka
2018-08-20  7:24 ` Jan Kiszka
2018-08-21 19:36 ` Alexander Smirnov
2018-08-22 14:37   ` Jan Kiszka [this message]
2018-08-22 19:52     ` Jan Kiszka
2018-08-22 20:43       ` Alexander Smirnov
2018-08-23  6:29         ` Christian Storm
2018-08-28 13:45   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4db9adeb-b649-2d51-0e91-28d781297cf3@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=asmirnov@ilbers.de \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox