[закрыто]Не работает blacklist для модулей

[jel]

Не работает blacklist для модулей. Это затрудняет использование ndiswrapper-а и может привести к проблемам с определением железа.

Нежелательный модуль вносится в строку SKIPLIST в файле /etc/rc.d/MODULESCONFIG. На основе этой строки при загрузке генерируется список blacklist-ов в файле /tmp/pup_event_modprobe.conf

Но похоже что дальше этот список не используется. Модули перечисленные в нем спокойно загружаются, создавая ненужные проблемы.

Подскажите, где копать, чтобы заставить этот список работать?

Upd: Похоже что виновник торжества modprobe. Сгенерированный список в скриптах передается ему в качестве конфига и похоже им благополучно игнорируется.

Он ведь тоже из обновленного busybox? О проблемах с утилитой du я уже писал на redmine. Теперь modprobe. И кто знает, что еще там поломали и где оно вылезет. Может есть смысл откатиться на старый busybox?

[Pro]

О проблемах с утилитой du я уже писал на redmine.

что то не заметил......

Upd: Похоже что виновник торжества modprobe. Сгенерированный список в скриптах передается ему в качестве конфига и похоже им благополучно игнорируется.

на чем базируется эта информация?

[jel]

По busybox-у подробно описал на redmine. Надо ставить coreutils.

По modprobe - udev использует /sbin/pup_event_backend_d и /sbin/pup_event_backend_modprobe при создании устройств.

Из /sbin/pup_event_backend_d например modprobe вызывается так:

Код

MODULE="`modprobe.bin --config /tmp/pup_event_modprobe.conf --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`"

Поскольку .conf для него сгенерирован и ненужные модули там перечислены логично предположить, что они не должны загружаться. А раз они загружаются и конфиг в порядке - похоже проблема в modprobe. Либо, как вариант - конфиг генерируется слишком поздно. То есть сначала udev создает устройства вызывая modprobe с пустым конфигом, а уже потом генерируется конфиг.

Еще есть интересные строки в /tmp/bootsysinit.log (выделено жирным)

VERSION UPDATE
mv: can't rename '/etc/modules/firmware.dep': No such file or directory
LOAD KERNEL MODULES
FATAL: Module fbcon not found.
ЗАГРУЗКА SWAP
УСТАНОВКА MISC. SYSTEM
WAIT MODULES LOADED
USER SELECTED MODULES
SETUP SERVICES
RECOGNISE MEDIA DEVICES
Loading extra ethernet driver modules...
loading ndiswrapper module
Loading "ru" keyboard map... Loading /usr/share/keymaps/i386/qwerty/ru.map.gz
MISC. DESKTOP STUFF
PERSONAL BOOT SCRIPT
Loading /usr/share/keymaps/i386/qwerty/ru-utf.map.gz
/etc/rc.d/rc.local: line 6: /etc/rc.d/SFSMODULE: Success
loading  module
Usage: modprobe [-v] [-V] [-C config-file] [-n] [-i] [-q] [-b] [-o <modname>] [ --dump-modversions ] <modname> [parameters...]
modprobe -r [-n] [-i] [-v] <modulename> ...
modprobe -l -t <dirname> [ -a <modulename> ...]
Waiting for interfaces to initialize...Power Button module already loaded.
acpi daemon started.
Starting PCMCIA services:

Либо где-то в скриптах инициалазации допущена ошибка, либо modprobe теперь не понимает каких-то параметров, которые раньше понимал.

[Pro]

modprobe не обновлялся т.к. новые версии не поддерживали работу с модулями ядра сжатыми gz

ошибка скорее всего результат обновления скрипта rc.sysinit пакетом для поддержки модемов.

[jel]

Судя по логу rc.sysinit к моменту возникновения ошибки уже отработал. Ошибка возникает уже после выполнения rc.local. Надо смотреть что там дальше выполняется.

[Pro]

желающие заняться данной задачей есть?

[nik]

новые module-init-tools используют /etc/modprobe.d/*.conf скорей всего проблема в этом.

[jel]

Я пробовал писать blacklist в /etc/modprobe.d/ - все равно не работает.

В /tmp/pup_event_modprobe.conf эти модули попадают в любом случае. А вот почему этот список игнорируется - так и не разобрался.

[Pro]

Просмотрел файлы все  pup_events_ даже сравнил со старыми версиями - ничего криминального нету
изменения конечно есть и  много но не особо криминальные......
вобщем нету ясности для чего нужен /tmp/pup_event_modprobe.conf по идее основным задающим файлом является
/etc/rc.d/MODULESCONFIG думаю надо глянуть теперь скрипты загрузки в /etc/rc.d (не успел еще )

[Pro]

В файле pup_event_backend_modprobe единственный обработчик pup_event_modprobe.conf найден тут:

Код

#find a matching module... (/etc/pup_event_modprobe.conf created in rc.sysinit)
MODULE="`/sbin/modprobe --config /tmp/pup_event_modprobe.conf --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`"
[ "$RULEMODULE" != "" ] && [ "$MODULE" = "" -o "$MODULE" = "usb_storage" -o "$MODULE" = "snd_hda_intel" ] && MODULE="$RULEMODULE" #w463 Use module from argument #101018
[ "$MODULE" = "" ] && exit 1

меня смущает что в коментариях пишут /etc/pup_event_modprobe.conf а  реально файл смотрят в /tmp/pup_event_modprobe.conf опечатка?
думаю что-то поломалось в строке MODULE....

[jel]

Я пробовал запускать modprobe строкой из этого файла (с конфигом и прочими параметрами). Невзирая на наличие модуля в блэклисте modprobe все равно бодро его предлагает.

Код

# echo "blacklist ath9k" >> /tmp/pup_event_modprobe.conf 
# /sbin/modprobe --config /tmp/pup_event_modprobe.conf --show-depends ath9k
insmod /lib/modules/2.6.35.8/kernel/net/wireless/cfg80211.ko.gz 
insmod /lib/modules/2.6.35.8/kernel/net/mac80211/mac80211.ko.gz 
insmod /lib/modules/2.6.35.8/kernel/drivers/net/wireless/ath/ath.ko.gz 
insmod /lib/modules/2.6.35.8/kernel/drivers/net/wireless/ath/ath9k/ath9k_hw.ko.gz 
insmod /lib/modules/2.6.35.8/kernel/drivers/net/wireless/ath/ath9k/ath9k_common.ko.gz 
insmod /lib/modules/2.6.35.8/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko.gz 
# 

[Pro]

опция --use-blacklist нам может чем нить помоч?

возможно надо попробовать поместить этот файлик в /etc/modprobe.d переименовав в blaсklist (без .conf т.к. версия modprobe у нас старая)

[jel]

c --use-blacklist или с -b вроде заработало как положено.

/etc/modprobe.d трогать не надо. Тут несколько другой механизм используется и он не зависит от версии modprobe.

Попробую теперь подкорректировать pup_event_backend_modprobe и посмотрю что получится.

[Pro]

хоть бы заработало, а то мне еще с мышами разбираться надо........

[jel]

Увы

Все равно грузятся. Видимо не из этого скрипта. Надо дальше разбираться.