On 6/17/25 07:57, Michael Hudson-Doyle wrote:


On Tue, 17 Jun 2025 at 17:37, Heinrich Schuchardt <heinrich.schucha...@canonical.com <mailto:heinrich.schucha...@canonical.com>> wrote:



    Michael Hudson-Doyle <michael.hud...@canonical.com
    <mailto:michael.hud...@canonical.com>> schrieb am Di., 17. Juni
    2025, 05:37:



        On Tue, 3 Jun 2025 at 04:05, Juerg Haefliger
        <juerg.haefli...@canonical.com
        <mailto:juerg.haefli...@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-
            de...@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

Reply via email to