Hi,
i was wondering whether there exists any mechanism to blacklist modules from
being loaded besides the typical /etc/modprobe.d/blacklist type mechanisms.
Sometimes you have a module oopsing because of faulty hw which cannot be
removed rendering the system unbootable.
And sometimes there's just no way to edit the modprobe blacklist because you
cannot boot the box :)
Basically i would like to setup a list of module names the kernel simply
refuses to load..
blacklist=some_module,some_other_module,some_third_module
Does something exist? Do you think it makes sense? Would it be tough to
implement?
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On Jan 27 2007 02:22, Florian Schmidt wrote:
>
>i was wondering whether there exists any mechanism to blacklist modules
>from being loaded besides the typical etc/modprobe.d/blacklist type
>mechanisms. Sometimes you have a module oopsing because of faulty hw
>which cannot be removed rendering the system unbootable. And sometimes
>there's just no way to edit the modprobe blacklist because you cannot
>boot the box :) Basically i would like to setup a list of module names
>the kernel simply refuses to load..
>
>blacklist=some_module,some_other_module,some_third_module
>Does something exist?
I think there was something like that although I can't remember
either what it was.
-`J'
--
* Jan Engelhardt <[email protected]> [2007-01-27 15:53]:
>
> On Jan 27 2007 02:22, Florian Schmidt wrote:
> >
> >i was wondering whether there exists any mechanism to blacklist modules
> >from being loaded besides the typical etc/modprobe.d/blacklist type
> >mechanisms. Sometimes you have a module oopsing because of faulty hw
> >which cannot be removed rendering the system unbootable. And sometimes
> >there's just no way to edit the modprobe blacklist because you cannot
> >boot the box :) Basically i would like to setup a list of module names
> >the kernel simply refuses to load..
> >
> >blacklist=some_module,some_other_module,some_third_module
>
> >Does something exist?
>
> I think there was something like that although I can't remember
> either what it was.
brokenmodules=..., but that's SUSE's linuxrc.
Regards,
Bernhard
Bernhard Walle wrote:
> * Jan Engelhardt <[email protected]> [2007-01-27 15:53]:
> brokenmodules=..., but that's SUSE's linuxrc.
good enough to boot the rescue system from the install cd without
oopsing and fix up the blacklist file in the installed systen though ;)
Trying to boot into single user is also worth a try. Some modules are
loaded nevertheless (usb + hid stuff, so you can login with a usb kbd
for example), but most of them are not yet loaded ...
cheers,
Gerd
--
Gerd Hoffmann <[email protected]>
On Jan 29 2007 09:30, Gerd Hoffmann wrote:
>Bernhard Walle wrote:
>> * Jan Engelhardt <[email protected]> [2007-01-27 15:53]:
>> brokenmodules=..., but that's SUSE's linuxrc.
>
>good enough to boot the rescue system from the install cd without
>oopsing and fix up the blacklist file in the installed systen though ;)
Does not work with components that are compiled-in, for which such a boot
option would be most helpful.
-`J'
--
Jan Engelhardt wrote:
> On Jan 29 2007 09:30, Gerd Hoffmann wrote:
>> Bernhard Walle wrote:
>>> * Jan Engelhardt <[email protected]> [2007-01-27 15:53]:
>>> brokenmodules=..., but that's SUSE's linuxrc.
>> good enough to boot the rescue system from the install cd without
>> oopsing and fix up the blacklist file in the installed systen though ;)
>
> Does not work with components that are compiled-in, for which such a boot
> option would be most helpful.
Is that an real-live issue, with distro kernels being shipped with
almost everything compiled as module these days?
cheers,
Gerd
--
Gerd Hoffmann <[email protected]>
On Jan 29 2007 12:25, Gerd Hoffmann wrote:
>Jan Engelhardt wrote:
>> On Jan 29 2007 09:30, Gerd Hoffmann wrote:
>>> Bernhard Walle wrote:
>>>> * Jan Engelhardt <[email protected]> [2007-01-27 15:53]:
>>>> brokenmodules=..., but that's SUSE's linuxrc.
>>> good enough to boot the rescue system from the install cd without
>>> oopsing and fix up the blacklist file in the installed systen though ;)
>>
>> Does not work with components that are compiled-in, for which such a boot
>> option would be most helpful.
>
>Is that an real-live issue, with distro kernels being shipped with
>almost everything compiled as module these days?
For me it was. FC6 has at least CONFIG_MD=y, and SUSE also has some =y that
could be =m with the help of module autoload rules, and some =y that could
truly be =m. Those being =y cannot be blacklisted.
-`J'
--
Am Montag, 29. Januar 2007 13:40 schrieb Jan Engelhardt:
> >Is that an real-live issue, with distro kernels being shipped with
> >almost everything compiled as module these days?
>
> For me it was. FC6 has at least CONFIG_MD=y, and SUSE also has some =y that
> could be =m with the help of module autoload rules, and some =y that could
> truly be =m. Those being =y cannot be blacklisted.
What use is it to modularly compile something that almost everybody needs?
Regards
Oliver
On Jan 29 2007 13:44, Oliver Neukum wrote:
>Am Montag, 29. Januar 2007 13:40 schrieb Jan Engelhardt:
>> >Is that an real-live issue, with distro kernels being shipped with
>> >almost everything compiled as module these days?
>>
>> For me it was. FC6 has at least CONFIG_MD=y, and SUSE also has
>> some =y that could be =m with the help of module autoload rules,
>> and some =y that could truly be =m. Those being =y cannot be
>> blacklisted.
>
>What use is it to modularly compile something that almost everybody needs?
[correction: meant CONFIG_BLK_DEV_MD, because CONFIG_MD itself does
not generate any code]
So just because almost everyone needs CONFIG_SCSI (SATA, usb_storage,
you name it), you're going to compile that in as well? It's just
another 180 KB [BLK_DEV_MD: ~100K] so let's compile it in!
There is a reason initramfs exists, and it's not only for firmware
loading or running custom scripts.
Am Montag, 29. Januar 2007 14:23 schrieb Jan Engelhardt:
>
> On Jan 29 2007 13:44, Oliver Neukum wrote:
> >What use is it to modularly compile something that almost everybody needs?
>
> [correction: meant CONFIG_BLK_DEV_MD, because CONFIG_MD itself does
> not generate any code]
>
> So just because almost everyone needs CONFIG_SCSI (SATA, usb_storage,
> you name it), you're going to compile that in as well? It's just
> another 180 KB [BLK_DEV_MD: ~100K] so let's compile it in!
For every module you waste PAGE_SIZE/2. In my system
oliver@valisk:~/Desktop/linux-2.6.20-6-greg> lsmod|wc
46 158 1827
that's 92K. There is a point where the number of people who don't
need it grows too small to justify that.
> There is a reason initramfs exists, and it's not only for firmware
> loading or running custom scripts.
But shrinking the statically compiled kernel isn't one of them. You need
to look at the actual memory footprint.
Regards
Oliver