On Mon, 2 Jun 2025 10:54:31 -0600
Dan Bungert <daniel.bungert@canonical.com> wrote:
> On Mon, Jun 02, 2025 at 06:04:48PM +0200, Juerg Haefliger wrote:
> > linux-firmware is ever growing and I'd like to entertain the thought of
> > splitting it up.
>
> Thank you for this.
>
> > I think this means that we need to detect what's in the system and install
> > the relevant linux-<vendor>-graphics package(s). Is this
> > ubuntu-release-upgrader? subiquity? ubuntu-drivers? All of them? Anything
> > else?
>
> Surely Subiquity (and/or Curtin)) will need to be aware of this. The use case
> here does sound similar to ubuntu-drivers today. Some sort of in-archive tool
> does sound useful, we don't want people to have to do a new install to benefit
> from this, so having a tool that Subiquity can call to would certainly be
> desired. Also, to preserve offline installs, I would like to see such tool be
> able to answer firmware questions fully offline.
Ok. Thanks for that feedback. Not sure yet what to do with it though,
I'll have to ponder it ;-)
>
> > Image generation and seeds would probably be affected by this as well.
>
> Should an install ISO boot something similar today, with all the firmware
> available?
I think we want pretty much everything in the installer ISO. At least the
things that make sense for the targets. As mentioned in another reply, we
could exclude blobs for other architectures and non-essential firmwares. It
depends on the granularity and how we end up bucketizing the blobs.
> If so, we likely want a subtractive process, to remove the unneeded
> firmware packages, that way we can keep the ISO size down and not have to store
> two copies of the firmware on the ISO.
Yeah, that makes sense.
>
> To expand on the two copies of firmware bit, in the install ISO we have
> linux-firmware in the lowest squashfs layer today. This means that it is
> present in the live booted layer used at install time, and is part of what we
> rsync over to the target system. If we split firmware into more packages, then
> all the firmware would get rsynced to the target system, so we'd want to remove
> some of the firmware packages, and want the tool to indicate which ones are
> safe to remove. Alternately, we could build the ISO with the firmware packages
> in the pool again, and dynamically install only the appropriate subset, but
> that means we do need two full copies (one to boot the installer with, one in
> the package pool on the ISO).
Thanks for the elaboration. That brings back memories from when I tried to
understand the ISO build process to add support for the x13s :-) I think a
single copy like we do today is fine. The initial package split should be
transparent to all the consumers and then we optimize over time and where
it makes sense.
>
> -Dan
Thanks for the feedback. Much appreciated.
...Juerg
