Hey again folks!
On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote:
...
We have quite a few things to do now, ideally before the freeze for
Debian 12 (bookworm), due January 2023 [2]. This list of work items is
almost definitely not complete, and Cyril and I are aiming to get
together this week and do more detailed planning for the d-i
pieces. Off the top of my head I can think of the following:
Cyril and I have just had that planning meeting, and here are the
notes. We're *not* trying to solve every problem here, just working
out the next steps needed for d-i and debian-cd in particular.
Debian firmware changes for d-i and installer images - notes ============================================================
Steve and Cyril, 2022-10-08
Netboot and firmware - what do we have to do? ---------------------------------------------
* PXE over wired ethernet should just work as-is?
* Is PXE over wifi a thing? Never seen it...
* If we need any more than simple wired, we're not going to worry
about it for bookworm
* This will likely be a problem for audio firmware
* Is netboot a common use case for partially-sighted people?
* Not going to focus on this here just *yet*, maybe we could work
on it as a later option
* Option to maybe load firmware via PXE/tftp process at early
kernel startup? Would need to investigate...
* HTTP(S) boot maybe?
Updating the sources.list of existing systems on upgrade --------------------------------------------------------
* **It's not a problem for d-i / debian-cd, we're not dealing with this here**
* automation is not likely to happen, we don't do it already
* **not** something we're trying to solve here
* having packages in both n-f and n-f-f seems like not a good solution
* worries about dak and others - we've never done this before
* Maybe move things to n-f-f and leave a transitional package in n-f?
* not sure about this either
* Let's punt on this decision for now, we can look at it again later if we have to
Detection of needed firmware
----------------------------
* We already had a solution in bullseye which was good enough, let's
keep with that?
* We're trying to solve the 99% case, and we have that now AFAIK?
* Worry about bonded network handling?
* Maybe tweak interface handling to not take down one half of a
virtual interface
* Cyril plans to work on VLAN & bonding topics anyway; easy to
hook it up/down.
* We *think* things are working ok, but we're not 100%
confident. We've not had complaints, but we don't know if that
just means we don't have users!
* Let's ask for testing to double-check that the new
firmware-included images work OK - bookworm d-i alpha 2 should be
ready with the nff changes?
* Cyril will test with 2 “d-i laptops” (same as bullseye).
What process should we follow for firmware during d-i? ------------------------------------------------------
* Several processes where we may ask for firmware: audio, network,
disks, etc.
* Do we ask about loading fw at each stage? Or just at the end?
* Three options via kernel command line? Cyril can take it.
* Allow firmware by default, then just before finish-install we
add a new screen listing firmware needed, details, write to disk
on the installed system. Cyril can take this.
* Maybe: if no firmware is needed then give a "congratulations!"
message. Cyril will not take this.
* Deny all firmware - don't attempt to load things at all, if the
system is broken then so be it
* Confirm - at each point display a prompt to the user before
loading fw
* We could **maybe** add support for changing the choice during
the installation, but let's keep it simple for now. Probably add a
question in expert mode?
* What do we do with **free* firmware here? Should we **always**
allow it?
* What happens when we have both non-free and free implementations
of firmware for given hardware?
* At some point we'll have to make a choice of which to use by
default, or allow for overriding on the kernel cmd line or
something.
* How do we handle sources.list changes (during the course of the
installation process, not on installed systems)? We might need to
enable/disable n-f-f at various times, for both the main archive
and the security archive. Cyril takes it.
* Even with fw available, we *might* get prompts where some modules
are unclear, or where we may not have the exact suggested firmware
available.
* Don't panic about this too much; we might add blacklists for
known-awkward modules later. Not a priority here (yet). We
already have one case implemented: iwl-debug-yoyo.bin (iwlwifi).
* Let's drop the question/support for an extra firmware medium -
it's not useful any more. We're going to have firmware available
directly.
* d-i should look in both n-f and n-f-f for firmware packages when
needed; debian-cd will include firmware packages from both for
now, including the symlinks in /firmware
* debian-cd should extract a list of filenames in each firmware .deb
so that d-i can be more efficient when doing its reverse
filename->package lookup later.
* Let's do something similar to existing Contents files in the
archive.
Should we add a new "firmware" d-i module or similar? -----------------------------------------------------
* Maybe for the final finish-install stuff?
* **NO** - just add an extra step in the hw-detect module that comes
up as part of finish-install to do the final summary piece
Asides
------
* Looks like it's time to tweak the isohybrid ESP handling
* Use a separate ESP so that we can support people adding more
stuff to it easily?
* Fw packages should be evaluated for architecture compatibility. If
a fw package is for a USB peripheral than we probably want it in
arch-all, but do we want (e.g.) raspi-firmware to be included on
all media? Should that be arch=armhf/arm64 maybe?
* How does Debian evaluate what goes in n-f-f? Anything that ships
redistributable firmware, I think? in /lib/firmware. Anything
that's not redistributable should not be in the archive / on
mirrors already - we're just going to follow the same path.
* d-i / debian-cd *doesn't* need to include *every* firmware package
on installation media, e.g. we probably don't need stuff like USB
JTAG device support on the netinst / first image. We may need to
add a blacklist for netinst/DVD1 to ignore those.
* The size of a typical netinst image is going to increase
noticeably here - all the firmware packages come to ~120MB or
so. m-a netinst will likely grow too big for a CD, but we don't
care that much any more there.
* i386 installer images should be going away *anyway*, so meh.
--
Steve McIntyre, Cambridge, UK.
steve@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm
afraid I'll miss my stop" -- Vivek Das Mohapatra
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)