On Thu, 2022-12-08 at 08:26 -0500, Stephen Smoogen wrote:
> >
> The only ideas I have seen which 'work'* is to ship a minimal set of
> drivers for some 'chosen' hardware and then you have a bloated kitchen-sink
> iso which has all the drivers in it. The chosen hardware could be a
> 'defined' virtual environment which needs a minimal set of firmware,
> languages, etc. Everything else can be done in the install for getting
> languages, extra firmware, etc. The kitchen-sink.iso is going to be one
> which we know is going to be large.
>
> Now I have doubled the QA, releng, and product work.. I would say we would
> focus most of the work on the mini-installer, but we all know that all the
> work will be in the kitchen-sink one.
Well, if the two images are just "with firmware" and "without firmware"
I suppose in a way the testing load shouldn't be too awful, because we
can be pretty confident of the possible behaviours - nothing except the
kernel should do anything with kernel firmware files, after all, so
you're kinda limited to "it works fine", "some hardware doesn't work
because the firmware isn't there", and the occasional "kernel blew up
because firmware was missing which it really shouldn't do", which is
bad but at least easy to spot and workaround ("you gotta boot with the
firmware, sorry"). We could probably rely mostly on automated testing
to confirm that both images at least work properly in expected cases.
Also it's general not too onerous for us to test "some random alternate
path through the installer" because we have to run several install
tests on bare metal anyway so we can just kinda add it to the 'matrix'
there - "OK, for the firmware RAID install test I'll try booting the
no-firmware route", that knocks out two tests in one. (Of course you're
assuming that firmware RAID handling isn't somehow broken when booting
with the firmware, but that seems sufficiently unlikely not to worry
about :>)
If we want to get fancy, I suppose we could ship a single ISO, but with
two filesystem images - one the main installer environment, one
containing /lib/firmware - and just have a boot arg that (tells dracut
to) mounts the firmware one, and a boot menu option to *not* do it (not
pass the boot arg), which saves memory as long as the system doesn't
need the firmwares. But then of course someone will say "hey, why don't
we build a second ISO without the firmware image included at all, so we
have a small ISO for people who know they don't need it?" and you're
back at option 1. We also I guess have to think about how things work
for things like PXE installs, and maybe update the documentation
there...
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
_______________________________________________
Anaconda-devel mailing list -- anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to anaconda-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
