Minimizing isar-image-base

Minimizing isar-image-base

[Jan Kiszka]

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?

- Why do we pre-install dbus?

- 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?

Alternatively, we could define some isar-image-tiny that removes 
packages from the base image, possibly also some that debootstrap pulls in.

Ideas, suggestions?

Jan

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

Re: Minimizing isar-image-base

[Jan Kiszka]

On 2018-08-20 09: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?
> 
> - Why do we pre-install dbus?
> 
> - 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?
> 
> Alternatively, we could define some isar-image-tiny that removes 
> packages from the base image, possibly also some that debootstrap pulls in.
> 
> Ideas, suggestions?
> 
> Jan
> 

Oh, and we may want to consider doing that meta/meta-isar refactoring 
now. Stuff like isar-image-base could become debian-image-base under meta.

Jan

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

Re: Minimizing isar-image-base

[Alexander Smirnov]

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 :-)

Alex

Re: Minimizing isar-image-base

[Jan Kiszka]

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

Re: Minimizing isar-image-base

[Jan Kiszka]

On 2018-08-22 16:37, [ext] Jan Kiszka wrote:
>>> - 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.

Removed it, but I'm not seeing any error messages nor does systemctl 
report failed services. Maybe the bug was solved in stretch. Christian, 
you said there is a harder dependency in reality than the "recommends" 
as Debian declares now. Any comments on this?

If it is really no longer needed, we could push the dbus dependency into 
debian-jessie.conf. Is raspbian-jessie on systemd as well? Then there as 
well.

> 
>>
>>> - 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?

We don't. IMAGE_TRANSIENT_PACKAGES is not suited.

Also, apt seems to get installed via debootstrap anyway. We should be 
fine removing it as explicit IMAGE_PREINSTALL entry. I'll propose a patch.

But we will need some explicit purging step that removes it again (and 
possibly more packages) after the image is done. And it should be under 
custom-image control, whether that step is run or not - or what the 
purge list contains. We could also use --exclude of debootstrap but that 
would imply forking the base bootstrap environment because we use the 
same for image and buildchroots so far. Probably not a good idea.

Jan

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

Re: Minimizing isar-image-base

[Alexander Smirnov]

Jan Kiszka <jan.kiszka@siemens.com> 22 августа 2018 г. 22:52:32 написал:

> On 2018-08-22 16:37, [ext] Jan Kiszka wrote:
>>>> - 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.
>
> Removed it, but I'm not seeing any error messages nor does systemctl
> report failed services.
> Maybe the bug was solved in stretch. Christian,
> you said there is a harder dependency in reality than the "recommends"
> as Debian declares now. Any comments on this?
>
> If it is really no longer needed, we could push the dbus dependency into
> debian-jessie.conf. Is raspbian-jessie on systemd as well? Then there as
> well.

One another thing changed since that time - migration from multistrap to 
debootstrap. Probably this could be the reason.

Alex

>
>>
>>>
>>>> - 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?
>
> We don't. IMAGE_TRANSIENT_PACKAGES is not suited.
>
> Also, apt seems to get installed via debootstrap anyway. We should be
> fine removing it as explicit IMAGE_PREINSTALL entry. I'll propose a patch.
>
> But we will need some explicit purging step that removes it again (and
> possibly more packages) after the image is done. And it should be under
> custom-image control, whether that step is run or not - or what the
> purge list contains. We could also use --exclude of debootstrap but that
> would imply forking the base bootstrap environment because we use the
> same for image and buildchroots so far. Probably not a good idea.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

Re: Minimizing isar-image-base

[Christian Storm]

Hi,

> >>>> - 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.
> >
> > Removed it, but I'm not seeing any error messages nor does systemctl
> > report failed services.
> > Maybe the bug was solved in stretch. Christian,
> > you said there is a harder dependency in reality than the "recommends"
> > as Debian declares now. Any comments on this?
> >
> > If it is really no longer needed, we could push the dbus dependency into
> > debian-jessie.conf. Is raspbian-jessie on systemd as well? Then there as
> > well.
> 
> One another thing changed since that time - migration from multistrap to 
> debootstrap. Probably this could be the reason.

There was a bug when debootstrap'ing that you had to explicitly install
dbus in order to make systemd happy and that was not reflected in the
packages' dependencies, hence it broke. This might have been fixed
upstream by now...


Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M�nchen, Germany

Re: Minimizing isar-image-base

[Jan Kiszka]

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