Re: non-free firmware and d-i
On Tue, Sep 05, 2006 at 04:07:10PM -0400, Joey Hess wrote:
> Wouter Verhelst wrote:
> > Since the most central point of disagreement seems to be around the need
> > to support non-free firmware from the installation (whether by doing
> > that through supporting the non-free repository, or by just dropping
> > these firmware blobs in main, or whatnot), I'm trying to understand what
> > is going on. Problem is, I don't see what the issues are, since I'm not
> > /that/ comfortable with d-i development. Is there a detailed explanation
> > somewhere?
>
> Did you see my post on -vote about it? <20060823181559.GA1093@kitenet.net>
No; reading it now, thanks.
> > I'll call "customization disks" for the time being: a low-priority d-i
> > menu item (on the same level as the "start a shell" option) which, when
> > activated, allows the user to load additional udebs from a floppy disk,
> > a usb key, a CD-ROM disk, or whatever.
>
> d-i already supports driver disks, see floppy-retriever and the code in
> hw-detect to prompt for a driver floppy if necessary hardware is not
> detected.
Missed that. Which is stupid, since I had been looking at the powerpc
driver disks last week, as you pointed out on IRC.
> Even extending this to support USB and CDs does not cover all cases, my
> outline in the post above includes some points where this approach will
> fail.
Right.
So there are cases of:
* CD-ROM drives needing firmware somewhere along the path (IDE/SATA
controller, drive itself perhaps?, more stuff...)
* hard disks requiring firmwhare somewhere along the same path
* network interface cards requiring firmware.
* USB too?
Any of those may have been used to boot from, although in some cases the
firmware or BIOS in the system can handle reading and booting from the
device while Linux can't use it without non-free firmware.
However, I think it's fair to assume that at this point, most systems
will support at least _one_ of the above devices that does not require
non-free firmware. Even the NSLU2, which currently is the only device
(AFAIK) that has a special installer image containing non-free firmware
blobs, also supports USB storage devices through which firmware could
potentially be added.
Your mail suggests a number of things, but I feel most of those are
redundant; it should be possible to do just a subset.
What I'm suggesting:
* Still support loading from cd, usb, floppy, or hard disk, as before.
* Stop providing driver disk images, requring people to create them
themselves by copying .udeb files onto a physical floppy disk or
cdrom (Rationale: this will help people understand what's really going
on, rather than have them assume that the driver disk image is
something very special which it isn't. I know I thought so before you
just told me on IRC that they only contained udebs...)
* Support loading driver udebs from the same medium as from where we're
installing, by (if appropriate) umounting and replacing the
installation medium by a medium containing nothing but driver udebs,
or whatever. This is possible; the install CD-ROM isn't the root
filesystem, so it's possible to controlledly umount it, and properly
remount it afterwards.
* In case we're installing from the network, download (using a TFTP
client) a tarball with udebs from the same TFTP server we've booted
from (which would require us to figure out somehow where we booted
from). I *think* all netboot schemes involve TFTP, or am I wrong
there?
This would sidestep having to fix libd-i and anna, although it's
obviously not a proper fix for the long term.
* Document for developers not involved in d-i how they can create udebs
containing NIC firmware blobs or similar, and make it clear that
*they*, not necessarily the d-i team, will have to do this if they
want their hardware to be supported in the installer.
With that, the only use case you're not supporting then is the case of a
hypothetical device which can be booted with use of the device's
firmware, but which can *not* use *any* of the relevant hardware (be it
floppy, cdrom, usb, hard disk, or network) unless at least one bit of
non-free software or whatever is loaded.
As a first argument, it can be questioned whether Debian really is the
right OS for such devices.
Even so, should people really want to use such devices, and considering
the fact that they are still quite rare at this point in time (most
modern devices that support Linux have USB; there are no USB hosts
adapters AFAIK which require firmware, and USB mass storage is
standardized), I think it's not unreasonable to require a slightly
higher level of understanding. For these cases, we could properly
document how to do the "cat firmware.cpio >> initramfs" step for at
least netbooting, possibly also for other install methods.
With that, I'd think we'd be covering all cases; and while it'd still
require some work, I think it's going to be significantly less than what
you suggested in your first mail.
I'd be willing to do the hard work here, if needs be.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: