[ILUG] Re: etch and kernel modules
Niall O Broin
niall at magicgoeshere.com
Tue Nov 21 21:48:36 GMT 2006
On 21 Nov 2006, at 11:43, martin f krafft wrote:
>> However, investigating the initrd proves more curious. The Debian
>> supplied initrd.img file is a gzipped cpio, yet if you run the
>> mkinitrd script it produces an initrd which is a cramfs filesystem.
>> Why the disparity?
> Well, Debian switched to initramfs since 2.6.12 or so. Initramfs is
> a joint development by the Ubuntu and Debian folks and it's just
> a gzipped cpio file; that's a lot easier to deal with than cramfs.
Yes, it's a little easier to deal with, though I guess most distros now
have cramfs in the kernel. At boot time, where do the files in an
fs file GO? Does the kernel have some kind of random access to the
of the file? Or does it get extracted into a tmpfs at boot or somesuch?
>> 1) What determines what modules are loaded from the initrd?
>> Clearly NOT need.
> /etc/initramfs-tools/modules will be an /etc/modules-style file that
> determines what the initramfs loads.
That seems to be used if there are other modules I'd LIKE to have
However, it seems that modules like pcspkr and floppy are just loaded by
default once the hardware is found. Now, I can of course solve the
problem (or better, annoyance) by adding an init script, or simply a
into rc.local but I'm wondering is there a "right" way to do it.
> /usr/share/initramfs-tools/hooks/* contains hooks
> which installs any non-standard modules into te initramfs. The
> scripts in /usr/share/initramfs-tools/scripts/*/* load them during
>> 2) How do I influence the above in a reasonable way?
> I think it'll be on a case-by-case basis. To start, maybe you could
> let me know which raid modules are loaded. I am the Debian RAID
> maintainer and unless you use RAID, no modules should get loaded.
> If you could list the modules you don't need, and also let me know
> which hooks are being run, that would help,
I'll list the modules I don't need in groups, with a comment per group:
psmouse uhci_hcd ehci_hcd pcspkr parport_pc parport shpchp pci_hotplug
These are all for hardware features which I simply don't ever intend
to use on a server in a data centre - all these modules can be unloaded.
These are also for hardware features which I simply don't ever intend
to use on a server in a data centre but these modules can't be unloaded.
An attempt to rmmod them results in a hanging unkillable process.
These are device mapper modules that I won't use.
raid10 raid0 raid456 xor
I use RAID1 on this box - I have no need for all these modules. And
prior to 2.6.18 it was worse, as raid were separate modules.
Now, I recognise that some of these may simply be sensible defaults,
and that my little start script may well be the right way to approach
The hooks which are present are:
kernelextras mdadm thermal udev
>> I have consulted the Debian Bible (Kraft's book) but it is
>> curiously silent on the matter.
> My book is based on Debian sarge. A lot has changed for Debian etch.
> I am sorry. :)
> (I am working on a new edition, but it's going to take substantially
> longer than etch itself).
That's the problem with a comprehensive reference work on such a fast
moving subject, isn't it - getting it out before it's obsolete.
More information about the ILUG