In the 2.6.11 kernel, the kernel team chose to drop some popular NIC
drivers which have non-free firmware. This included the tg3 driver,
which is apparently too hard to patch to a firmwareless state anymore.
Some of these modules (the ones whose firmware has a license allowing
distribution at all) will eventually be uploaded in a
kernel-modules-nonfree-2.6.11 package. d-i trunk is already set up to
build udebs of those.
But making a udeb is only the first step. We need to find a way to let
users use this udeb. One way would be to require them to use a driver
floppy. But floppies suck. Since my main i386 d-i test machine uses tg3
and I do not want to have to use driver floppies for all my d-i work, I
looked for a better way[1].
I considered just adding the nic-modules-nonfree udeb to the
package-lists, but I doubt we want all the d-i images to be in non-free.
I considered making an alternate d-i images build that includes the
non-free modules, done in paralell to the free build. But I suspect the
end result would be that nearly everyone would just use the non-free
build when possible, to avoid trouble. And we'd still not be able to
include it on debian CDs.
So I got to thinking about letting the user assemble the peices; adding
non-free udebs to d-i images if they desired to. This seemed to strike
the right balance between convenience and idealology. How to implement
it?
The 2.6 kernel has the new initramfs filesystem, which is a cpio archive
appended to the kernel. One neat thing is that it can really be multiple
cpio archives; the kernel assembles them all into one filesystem on
boot. This would let us ship a cpio of non-free drivers and the user
just appends this to thier kernel+initramfs image. It will even work for
supplying non-free firmware files to in-kernel drivers.
That's elegant, but not perfect, since it would only work if the user
can modify the kernel file. It would allow adding non-free drivers to
netboot images on i386, maybe to usb images, but not to iso images. On
other arches that have piggybacked netboot kernel images, it might not
work (dunno). So you'd still need a driver floppy for isos and floppy
installs on i386, and maybe for netboot too on !i386 (some of which
arches don't have floppies..). It also wouldn't work for 2.4, if they
begin removing firmware from that kernel too..
Apparently there's also the possibility for a smart bootloader to load
user-supplied cpio files and pass them to the kernel as it's booting,
which might fill in some of these holes, but I don't know of any boot
loaders that can do it yet.
A similar idea is adding code to the installer to let the user append
cpios, or udebs, or whatever format we choose to installer images and
have the installer look for such things at the end of its boot image,
CD, whatever. That should be doable for CDs. I don't think it will work
for initrd images on at least i386[2]. Using regular udebs is attractive,
but if we have to mix this with initramfs to cover (most) image types
then they'd better for cpios, for consistency.
Another approach entirely is to write a program that can take
$RANDOM_DI_IMAGE, unpack it, add $RANDOM_UDEB, and repack it. We'd need
to make the program available on the web or something for users w/o a
debian system to run it on, though. And dealing with all image types of
all architectures would be a lot of work.
Of course, even though my main reason for wanting d-i to support
something like this is because of non-free firmware, there would be
other applications, including debugging, easier image customisation, and
adding initrd-preseed files.
Anyway, I hope we can solve this soon, I'm dying to get sid d-i using
2.6.11 ...
--
see shy jo
[1] Better aside from digging up another NIC card that is.
[2] Since the initrd.gz is unzipped and the content becomes /dev/root;
anything appended to the end on initrd.gz is discarded.
Attachment:
signature.asc
Description: Digital signature