image-installer: Why does the iso not contain the 'minimal' set of packages?

[Matthias-SE]

Hi,

I'm playing around with the image-builder in order to build a custom iso-image (type: image-installer). To my surprise, the created iso-image does not really contain a "minimal" OS. To be more precise: it contains more packages than an installation from an original RHEL iso, where I'm selecting the "minimal" environment. For example, the image-builder iso installs also cockpit-system and cockpit-ws. This behavior is also documented in the docs for rhel-9.6/image-installer:

os:
    include:
      - '@core'
      - authselect-compat
      - chrony
      - cockpit-system
      - cockpit-ws
      - dhcp-client
      - ...

My questions:

• What is the reasoning behind this (design?) decision?
• Is there an option to obtain a "real" minimal iso? Or do I have to uninstall unwanted packages afterwards? Is there an easy why to know which packages are required and which are crucial for the OS?

BR,
Matthias

[achilleas-k]

Hello,

Thanks for opening this discussion.

What is the reasoning behind this (design?) decision?

I had to go back a bit to find this and refresh my memory: osbuild/osbuild-composer@280b063

"The package set is intended to replicate a default RHEL installation, but may need some changes."

I believe the cockpit packages are part of the default, or at least were at the time. These RHEL 9 docs do mention that "Red Hat Enterprise Linux 9 includes the web console installed by default in many installation variants". Beyond that, comparing that original RHEL 8.5 package set with the latest one in RHEL 10, it doesn't seem to have changed much and the cockpit packages in particular are still there.

Is there an option to obtain a "real" minimal iso?

This is a bigger topic but the simple answer is no, not right now. We've experimented with ways to give users the option of minimising the package set with a simple blueprint option, but it never made it to production. I'm willing to revisit it though and we have some work in progress that gives users more advanced ways of modifying the built-in image definitions.

Or do I have to uninstall unwanted packages afterwards? Is there an easy why to know which packages are required and which are crucial for the OS?

One issue with this image in particular (as opposed to our disk images and especially the ones meant for specific cloud platforms) is that we don't know in advance where the image will be deployed. Of course, we could trim the package set down to the absolute minimum and let the user decide on details, but we also like having "sane defaults" for most use cases (for example, we include lvm2, which isn't useful if you're not doing lvm partitioning, but given that lvm partitioning is very common on RHEL bare metal installations, we decided it's more convenient to include it). Looking at the 9.6 docs you linked to, I'd say the following are not crucial for the OS:

• all cockpit packages
• qemu-guest-agent (this one should be removed actually)
• qemu-img
• rsync
• tcpdump
• tar
• xz

The iwl*-firmware packages depend on system hardware.

Some of the others might not be crucial, but are likely useful for most systems (e.g. chrony).

I'd be curious to know (and it might help get us back to thinking about this minimisation effort) if you have any thoughts on how a minimal installation option might look like for the user. Would a blueprint option (minimal: true|false) be convenient, or would you rather have a separate image type (minimal-image-installer for example)? Or perhaps something else?

[supakeen]

This is a bigger topic but the simple answer is no, not right now. We've experimented with ways to give users the option of minimising the package set with a simple blueprint option, but it never made it to production. I'm willing to revisit it though and we have some work in progress that gives users more advanced ways of modifying the built-in image definitions.

Is this still necessary now that we do allow users to (experimentally) override the entire package set for image types through definitions?

[achilleas-k]

No, but I didn't know we officially supported that yet :)

[supakeen]

I'm playing around with the image-builder in order to build a custom iso-image (type: image-installer). To my surprise, the created iso-image does not really contain a "minimal" OS. To be more precise: it contains more packages than an installation from an original RHEL iso, where I'm selecting the "minimal" environment. For example, the image-builder iso installs also cockpit-system and cockpit-ws.

It is correct that the image-installer type is a bit funky. It was introduced a while ago and likely doesn't cleanly map on any selectable package sets from the RHEL boot.iso.

Setting aside the historical reasons for why this package set was chosen to me it is unlikely (to me) that we were to change this; as users might have started depending or expecting it.

---

If you want to build an image-installer that has a different (smaller) package set for the installed system you can use the experimental definition overrides.

Alternatively you can take a boot.iso (or dvd.iso if you want to be offline) from RHEL and use kickstarts to specify which packages are to be installed.