[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#295651: Better support for essential third-party modules during installation

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

Reply to: