Re: Building UDEBs for drivers
On Sunday 14 August 2005 00:58, Steve Langasek wrote:
> Hi Mark,
>
> On Fri, Aug 12, 2005 at 02:06:38PM -0700, Allyn, MarkX A wrote:
> > I have an internal corporate requirement to come up with a driver update
> > disk (cd or floppy) that can be used with Debian stable (Sarge) that
> > contains either deb's or udeb's or both for three device driver modules.
> >
> > These modules need to be loaded into both the install kernel (the kernel
> > that is booted from the installer CD) as well as the installed kernel. We
> > are using the 2.6.8-2-386 kernel (obtained via typing linux26 at the
> > initial CD boot).
> >
> > Without these modules, I am unable to do an install as the present
> > 2.6.8-232 kernel in Debian sarge does not have device drivers for my hard
> > drives.
> >
> > I have been able to create loadable modules for the device drivers that
> > can be loaded into an already running kernel (after installation) and
> > they work okey.
> >
> > I need to know the basics such as:
> >
> > 1. What are udeb's? Are they the same as deb's?
> > Is their structure the same? Can the same
> > Debian package building and maintenance tools
> > be used to create them?
> > 2. As far as I can tell, the kernel that is booted
> > from the install CD does appear to be the same
> > as that installed (2.6.8-2-386), therefore, I
> > foresee no problem using the loadable modules (.ko
> > files) for the drivers that I have compiled.
> > Unless I am missing something obvious. Please
> > help me if I am. If that is the case, can the
> > drivers still be packaged in a .deb file and not
> > a .udeb file?
> > 3. I am having considerable difficulty with Googling and poking
> > around for information on how to package the driver
> > packages on a Driver Update Disk that can be used
> > during the install so that the kernel that is booted
> > directly from the CD has the new packages loaded. I
> > would also need to have the same packages installed
> > in the installed kernel before the initial re-boot.
> > 4. I have done an apt-get of debian-installer-20050317
> > and poked around it. Perhaps it's not obvious, but
> > where is the script/application/utility that loads
> > in Driver Update disks, if there is one?
>
> So I think you're the first person I've heard of actually trying to provide
> add-on components for d-i like this; congratulations on breaking new
> ground.
>
> :)
>
> The debian-installer design is certainly intended to allow you to load
> additional components from floppy; the floppy-retriever command exists
> specifically for loading udebs from floppy, so the only thing you should
> have to do to get the added udeb recognized is to drop the floppy in the
> drive, escape out to the d-i main menu, ensure the floppy-retriever
> component is itself loaded, and choose "Load driver from a floppy".
>
> Now, here's the challenge in all of this: floppy-retriever only applies to
> udebs (more properly written "μdebs", i.e., micro-debs), not to debs.
> Udebs are not full packages that can be installed on the running system,
> and moreover, there's currently no direct way to integrate .debs from a
> floppy into the first-stage install because the first-stage installer
> supports pulling packages from a single apt source only. Not only does
> this make it hard for upgrades of the installed system to cope with the
> added kernel module (which is potentially significant in the event of a
> security update that breaks the kernel ABI), it also complicates things in
> terms of updating the kernel's map of what modules should be autoloaded for
> what hardware.
>
> I can see a few ways you could go about this:
>
> - Create a single udeb that unpacks a module into the kernel tree; this
> will require either the user manually selecting the module for loading,
> some kind of preseeding magic (not sure what this would look like), or some
> kind of magic to get the module into discover's hardware database (not sure
> what this would look like either). Make the udeb depend on base-installer,
> and give it a postinst script that dumps the kernel module into the install
> system and reruns the initrd build process for the kernel (not tested,
> could need some hacking to pull off).
>
> - Create the udeb as before that unpacks the module for loading, and get it
> loaded appropriately. Also create a .deb containing the module, and use
> the apt-install utility from the udeb postinst to queue it for
> installation. Use something like preseeding late-command to fix up
> /target/etc/apt/sources.list to support pulling from multiple apt sources
> (one regular mirror, and one a file:/// source coming from floppy) when
> finishing up the install.
>
> - Create a full Debian install CD that includes a customized kernel-image
> package containing your driver, and removes the
> kernel-image-2.6-<flavour> metapackages to avoid having the system's disk
> driver pulled out from under it on an automatic upgrade. You will need to
> update the
> linux-kernel-di-i386 package to pull your module into a kernel udeb, and
> you will need to updated discover1-data-udeb to know how to map hardware
> IDs to a module name for your driver.
>
> The third option is probably the one that requires the least amount of new
> code, but it may not be appropriate for your needs depending on how widely
> you expect to circulate the result. It's also the method with the highest
> overhead for doing any kind of updates, with something like a four- or
> five-pass build process. I think option #2 is where you really want to be.
> I'd be happy to work with you to figure out what needs to happen to make
> that work.
>
> Cheers,
As a matter of interest, if the machine has no floppy drive is the capability
generalised so that extra drivers can be loaded from USB memory stick and
other such places (ZIP drives, Compact Flash etc).?
David
Reply to: