Re: Minimizing isar-image-base

[Jan Kiszka <jan.kiszka@siemens.com>]

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.
> 
>> - Why do we pre-install dbus?
>>
> 
> Again, IIRC, without dbus there was dirty boot log in QEMU, some 
> services failed to start.
> 
>> - 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.
> 
> 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 :-)

FWIW, below is the list that the debian:stretch-slim docker container 
installs. It does not contain a kernel, obviously, and it apparently 
does not use systemd. It still has apt installed, though. Under that 
conditions, it ends up with some 60 MB on x86.

Here is also more information on how they produce that rootfs:
https://github.com/debuerreotype/debuerreotype

Jan

---

adduser
apt
base-files
base-passwd
bash
bsdutils
coreutils
dash
debconf
debian-archive-keyring
debianutils
diffutils
dpkg
e2fslibs:amd64
e2fsprogs
findutils
gcc-6-base:amd64
gpgv
grep
gzip
hostname
init-system-helpers
libacl1:amd64
libapt-pkg5.0:amd64
libattr1:amd64
libaudit-common
libaudit1:amd64
libblkid1:amd64
libbz2-1.0:amd64
libc-bin
libc6:amd64
libcap-ng0:amd64
libcomerr2:amd64
libdb5.3:amd64
libdebconfclient0:amd64
libfdisk1:amd64
libgcc1:amd64
libgcrypt20:amd64
libgpg-error0:amd64
liblz4-1:amd64
liblzma5:amd64
libmount1:amd64
libncursesw5:amd64
libpam-modules:amd64
libpam-modules-bin
libpam-runtime
libpam0g:amd64
libpcre3: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
login
lsb-base
mawk
mount
multiarch-support
ncurses-base
ncurses-bin
passwd
perl-base
sed
sensible-utils
sysvinit-utils
tar
tzdata
util-linux
zlib1g:amd64

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux