>
>
> On Tue, 17 Jun 2025 at 17:37, Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com
> <mailto:heinrich.schuchardt@canonical.com>> wrote:
>
>
>
> Michael Hudson-Doyle <michael.hudson@canonical.com
> <mailto:michael.hudson@canonical.com>> schrieb am Di., 17. Juni
> 2025, 05:37:
>
>
>
> On Tue, 3 Jun 2025 at 04:05, Juerg Haefliger
> <juerg.haefliger@canonical.com
> <mailto:juerg.haefliger@canonical.com>> wrote:
>
> Hi,
>
> linux-firmware is ever growing and I'd like to entertain the
> thought of
> splitting it up. Not as fine grained as Debian but only
> split out the bigger
> GPU blobs (for now):
>
> - linux-firmware (provides the bulk of the blobs)
> - linux-<vendor>-graphics (similar to Debian, provides
> vendor specific
> graphics related firmwares)
>
>
> This sounds like a good plan for me. I've long been a bit
> agitated about how much of the server installer ISO is taken up
> by firmware -- it's something on the order of 25% of the total
> size! (~500MiB out of a total of ~2GiB). Would the server installer
>
>
> On virtual machines you most probably don't want any firmware. On
> tiny embeded systems you would only want the strictly necessary
> firmware.
>
>
> Neither of those use cases are really in the target zone for the server
> installer though.
The use cases you have in mind seem to differ from mine:
All RISC-V boards use the server installer. We don't have any other
installer.
And for sure I am using a server installer to get Ubuntu onto my ARM
embedded boards. What other installer should I use for a headless setup?
In virt-manager I use the server installer ISO to create new RISC-V
virtual machines.
>
> In an installer an advanced user might prefer a choice between
> firmware for detected hardware and give me all.
>
>
> I have a very vague notion of making it easier for people to make or at
> least get installers that are more tailored for their needs (like if you
> are doing a netboot install you probably don't really want the pool on
> the install media) but nothing at all concrete there..
In most cases I would very much prefer a net installer to a full
installer image. An EFI application of less than 1 MiB should be all you
need to bootstrap an installation.
Best regards
Heinrich
>
> be able to get away without the -graphics blobs? (i.e. are
> systems in practice to operate a vt without any firmware at all?)
>
> Cheers,
> mwh
>
>
> Both Ethernet and WiFi have failed for me due to missing firmware.
>
> On internal GPUs of ARM and RISC-V SoCs you might not get a usable
> desktop without firmware.
>
>
> Yes but for the server installer that's fine I think.
>
> Cheers,
> mwh
>
> Best regards
>
> Heinrich
>
>
> This obviously can't break users so I'm trying to understand
> which pieces
> need to be updated for seamless release upgrades and new
> installations. 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?
>
> Image generation and seeds would probably be affected by
> this as well.
>
> Does anyone see any (other) issues with this?
>
> Thanks
> ...Juerg
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com <mailto:ubuntu-
> devel@lists.ubuntu.com>
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-devel <https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-devel>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com <mailto:ubuntu-devel@lists.ubuntu.com>
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-devel <https://lists.ubuntu.com/mailman/
> listinfo/ubuntu-devel>
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
