> I generated a module called v86d which is in /sbin > > I want to add that to initrd.img-2.6.25-1-686 > > No amount of fiddling does it. > > When I do: > > zcat initrd.img-2.6.25-1-686 | cpio --list > > the module never appears. > > I tried adding a file to /etc/modprobe.d and > adding v86d to /etc/initramfs-tools/modules > > all to no effect. > > How do you add a module to an initrd.img?
I'm sure there's a way to do what you want, but Debian's tools for creating initrd's only grab files from /lib/modules/<kernel-version>, AFAIK. I use 'v86d' to support UVESA FB on my system, but my preference is to not use an initrd at all. Because of that, I have never investigated how to force 'v86d' into a Debian initrd (though, as I said, I'm sure there's a way!). What I do is pack an initramfs with my kernel image -- which is the moral equivalent of an initrd, except that the bootloader doesn't have to load an external file for the kernel. The kernel just unpacks the compressed cpio (initramfs) archive that is present in the kernel image itself. You can find some instructions for doing this here: http://dev.gentoo.org/~spock/projects/uvesafb/ Read down until you see "uvesafb::installation instructions", then take a look at step 6: 6. reconfigure your kernel; in the "General Setup" section select: Initial RAM filesystem and RAM disk (initramfs/initrd) support and use /usr/share/v86d/initramfs in Initramfs source file(s). (that's CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs") For us, the location of the file needed for CONFIG_INITRAMFS_SOURCE will not be the same. The location of that file will depend on where you unpacked and built the 'v86d' sources. For example, let's say user "fred" on my system unpacked his 'v86d' sources in ~/sandbox. He now has a directory like this: /home/fred/sandbox/v86d-0.1.5 Inside that dir, there is a subdir called 'misc', and in that dir is the file "spock" was talking about: $ ls /home/fred/sandbox/v86d-0.1.5/misc initramfs Therefore, user "fred" should go to his kernel source tree, run something like 'make menuconfig', find the option for CONFIG_INITRAMFS_SOURCE, and set its value to /home/fred/sandbox/v86d-0.1.5/misc/initramfs This process will cause the kernel to include an initramfs image along with the kernel image containing the files required for 'v86d' to work. (If you are using 'v86d' to get UVESA FB to work, then all of this is for nothing if you also did not have a uvesafb-aware build of 'klibc' installed when you compiled 'v86d'! You would have to rebuild 'klibc' first, pointing the build at kernel sources that have been built with UVESA FB enabled, then rebuild 'v86d' against that version of 'klibc'.) BTW, I am not saying that you will no longer need an initrd at all. If you needed one before, because certain modules required for your machine to boot were not compiled directly into the kernel, then you will still need one. I'm just saying that 'v86d' will not have to be present in that initrd: it can actually just be included with the kernel image itself, if following the method of "spock" indicated above. Personally, when building my own kernel I take the time (numerous hours, the first time) to completely disable the configs for hardware not present in my system and features that I cannot imagine ever using. I then make sure that any drivers necessary for booting are built into the kernel (config set to "Y"), and other drivers that I want (but don't need at boot time) I enable as loadable modules (config set to "M"). The results are mixed: my kernels are somewhat larger, but I have a lot less wasted space in /lib/modules: # ls -s /boot [...] 5876 initrd.img-2.6.25-1-amd64 [...] 2492 vmlinuz-2.6.25.080503.amd64x2.uvesafb 1692 vmlinuz-2.6.25-1-amd64 # ls -1 /lib/modules 2.6.25.080503.amd64x2.uvesafb 2.6.25-1-amd64 # du -s /lib/modules/2.6* 15020 /lib/modules/2.6.25.080503.amd64x2.uvesafb 77540 /lib/modules/2.6.25-1-amd64 As you can see, my self-compiled kernel image is about 800K larger than the Debian stock kernel, but the stock kernel also requires a 5800K initrd. In /lib/modules, my self-compiled kernel uses about 1/5 the amount of disk space as the stock kernel... and I went overboard turning on modules for networking support that I probably will never even use! The biggest difference is in compile time, though. My Athlon 64 X2 5600 CPU compiles my kernel in less than 4.5 minutes if I tell 'make-kpkg' to use both cores: CONCURRENCY_LEVEL=3 make-kpkg --append-to-version=<...> --revision=<...> kernel_image HTH, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
