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

Curious case of /lib/libkmod.so.2



Hi d-i developers,

I'm working on an bootloader/installer system for some industrial equipment. Until now, my main interaction with d-i has been grabbing the pre-cooked kernel/initrds from Debian or Ubuntu, and tacking on a few extra files to the tail of the initrd, like preseed, scripts, and an extra udeb or two.

However, I've come to a place where I'd like to have more control over some things (incl exact kernel version) and so I want to generate my own initrd with just the particular udebs I require. I'm basing most of my work on the Makefile here, which details downloading a dependency tree of packages, and creating a bare bones dpkg setup into which they are installed:

https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build/Makefile#n308

My system actually mostly works, but one key file I'm missing is /lib/libkmod.so.2. This file isn't contained within any of the udebs (libkmod2-udeb is just a multi-call binary with no libs), and in fact a little tracing reveals that it springs into existence as a result of the mklibs-copy call which happens here:

https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build/Makefile#n526

Without this lib, systemd-udevd fails to link at runtime (called by the init script), and the kernel panics shortly after boot.

So my main question is, what is going on with the mklibs-copy call? Where are the contents of libkmod.so.2 coming from? They're byte-for-byte identical with the copy in the libkmod2 package, but in a different location, and I don't even have that package installed.

I'm sure there's some silly explanation here that I'm just not seeing, but a I think I need a poke in the right direction to get there. Thanks,

Mike

Reply to: