--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: Better support for essential third-party modules during installation
- From: Tore Anderson <tore@debian.org>
- Date: Thu, 17 Feb 2005 09:21:55 +0100
- Message-id: <200502170921.55057.tore@debian.org>
Package: debian-installer
Severity: wishlist
I recently had to install a system that had a RAID controller whose
corresponding module isn't included in the default kernel, so it has to
be compiled manually. I am amazed at how hard this was to do.
First, I had to compile the module for the kernel d-i uses,
2.6.8-1-386. However, the corresponding kernel-headers package appears
to have been removed from the archive. I'll not even touch on any
possible GPL issues, but it is at the very least very unpractial for
those who would like to compile third-party modules matching the ABI of
the kernel installed by default. I gather this is a rather common
thing to do, so I'd really like to see the kernel-headers package of
the d-i kernel stick around in the archive even if newer kernel images
are uploaded. Fortunately, I found the necessary packages at
<http://snapshot.debian.net>, and was able to compile the module.
Having copied the module to a floopy disk, I started the installation.
I soon found that d-i unfortunately does not have a "Preload essential
modules from floppy" like b-f had, so I figured I'd do it manually.
Inserting the module worked just fine, and I got block devices I could
continue installing to. Which didn't work so well; after installing
the base system the installation as a whole failed due to mkinitrd's
inability to find my custom module in /target/lib/modules/2.6.8-1-386.
"Well duh!" I thought, and mkfs'ed the partition once more, and after
remounting it I created the /target/lib/modules/2.6.8-1-386/local
directory and copied the module from the floppy there, before
restarting the installation of the base system. However, this for some
bizarre reason made the kernel-image's preinst (I think) fail. I
wonder if that is a genuine bug in the kernel-images, as they certainly
do not ship any /lib/modules/2.6.8-1-386/local subdir so there was no
file conflict, but I do not remember the exact error message. In any
case, the installation was aborted.
After some more thinking, I finally figured out how to make it work.
Before starting yet another base system install, I started the
following command sequence on the second terminal:
until test -d /target/lib/modules/2.6.8-1-386; do :; done; \
mkdir /target/lib/modules/2.6.8-1-386/local; \
cp /floppy/mod.ko /target/lib/modules/2.6.8-1-386/local
..thus exploiting the delay between unpacking and the mkinitrd
invocation from the postinst to copy the module in place. This worked
just fine, and allowed me to finish the installation and end up with a
system booting and functioning perfectly.
However, the process was annoyingly clunky, and even if I was able to
make it work, I do not think the average user will be very happy about
this procedure - and it'll probably grow more and more useful during
as new hardware is released during the lifespan of Sarge. So it'd be
really great if you could add support for loading third-party modules
directly from the installer, like b-f had.
Kind regards,
--
Tore Anderson
--- End Message ---