> 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.
> 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? 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.
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).
-Dan
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
