Re: non-free firmware and d-i
Joey Hess <joeyh@debian.org> writes:
> Wouter Verhelst wrote:
>> * 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.
>
> d-i doesn't have a tftp client, adding one would bloat the image (one
> client for network downloads should be enough).
>
> AFAIK, there's no way to figure out where the system booted from. If
> there is, it's probably hardware-dependent.
>
> If you have a working linux network driver, d-i is already perfectly
> capable of downloading drivers, including non-free drivers, from a
> Debian mirror (see followups to my post), so this is a non-solution anyway.
As for figuring out where to get the file from you simply ask the
bootp/dhcp/pxe server. That already told the biod where to get files
and you just have to adjust the filename for the udeb.tar.
But if the network card needs firmware to work under linux it usualy
still manages to support netboot. But once linux takes over the card
can't be used anymore. And if the network card works under linux you
can just fetch udebs via http. So tftp won't help there.
>> 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.
I have no floppy drive nor any disk that works reliable. I have a
cdrom in only one system. My USB stick is lost somewhere in my room
where I can never find it when I need it. The harddisk tends to be
empty when I want to install and the network needs firmware.
Damn, I'm stuck.
While I can solve the problem in various ways it is not very practical
to do so. A non-free netboot image or a way to append the non-free
firmware to the netboot image would be much more convenient (and not
hard to provide to our users).
> There are lots of use-cases you may not be taking into account.
> Sometimes it's just not *practical* to use certian boot methods, even if
> the hardware supports them. Or you just can't afford to run around to
> all of the hundereds of machines you're netbooting for automated
> installs and stick a usb key in them for the firmware. There are many
> outre situations where d-i shines because it has a lot of flexability
> and can support many different installation approaches; when we remove
> some of that flexability, it does end up harming d-i.
>
>> 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 stand by my original estimate..
I don't believe adding non-free images to D-I that would include all
the firmware and drivers that are currently on D-I and omiting
whatever gets split out to non-free in the main image would take your
estimated 6 month. I estimate more like one weekend of work.
By adding the non-free udebs (the subset relevant to each image) to
the initramfs you don't loose access to the udebs, no hardware support
is dropped. And once you can get udebs you automatically get main and
non-free udebs already giving you all the remaining non-free drivers
and firmware that could be split out. Again no hardware support is
lost.
What changes is that the free images are castrated and the actualy
usable images get called non-free. But not the amount of hardware D-I
can support.
>> I'd be willing to do the hard work here, if needs be.
>
> I'm glad someone's interested in working on it!
>
> --
> see shy jo
MfG
Goswin
Reply to: