какой командой посмотреть ошибки ядра linux

🐧 20 команд мониторинга Linux, которые вы должны знать

Вступление

1. Top

2. vmstat

Команда vmstat – это утилита Linux для отображения статистики, связанной с потреблением памяти, использования диска и другой системной информацией.

vmstat не должен присутствовать в вашей системе Linux, но не беспокойтесь.

Мы можем легко установить пакет «sysstat»

3. iostat

Команда iostat на Linux позволяет отслеживать статистику использования ЦП и ввода-вывода ( I/O) для всех дисков и файловых систем.

Команды iostat полезны для изменения конфигурации системы, чтобы лучше сбалансировать нагрузку ввода-вывода между физическими дисками.

Эта команда в основном используется системными администраторами Linux.

5. lsof

Задача команды lsof – «перечислить открытые файлы» в системе.

Открытый файл не означает pdf или текстовый файл, он включает файлы на диске или каналы, используемые процессами в фоновом режиме.

Вывод:3

6. tcpdump

Tcpdump – это инструмент, который используется для анализа пакетов TCP / IP.

Эта команда обычно используется для анализа трафика в Linux, а также во многих других операционных системах.

tcpdump позволяет прослушивать весь входящий и исходящий трафик со всех интерфейсов.

Что еще более важно, он может фильтровать трафик по интерфейсу, хосту, месту назначения или хосту-источнику, типу трафика и многим другим критериям.

Чтобы вывести статистику только избранных протоколов, таких как TCP или UDP, используйте соответствующие параметры, такие как t и u, вместе с параметром s.

Команда ps выводит четыре столбца информации для двух минимальных процессов, запущенных в текущей оболочке.

Источник

Изучаем внутреннюю кухню ядра Linux с помощью /proc для быстрой диагностики и решения проблем

Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет. И ещё — здесь не будет описания ядерных отладчиков или скриптов SytemTap; только старые-добрые простые команды вида «cat /proc/PID/xyz» в отношении некоторых полезных узлов файловой системы /proc.

Диагностика «тормозящего» процесса

Вот хороший пример часто возникающей проблемы, которую я воспроизвёл на своём лаптопе: пользователь жалуется, что команда find работает «значительно медленнее», при этом не возвращая никаких результатов. Зная, в чём дело, мы решили проблему. Однако меня попросили изложить систематический подход к решению подобных задач.

К счастью, система работает под управлением OEL6, т.е. на достаточно свежем ядре (а именно — 2.6.39 UEK2)

Итак, приступим к диагностике.

Сперва проверим, жив ли ещё процесс find:

Да, он на месте – PID 27288 (дальше в примере диагностики я буду использовать этот pid)

Начнём с основ и взглянем, что является узким местом для данного процесса. Если он ничем не заблокирован (например, читает всё ему необходимое из кэша), он должен использовать 100% CPU. Если же он в блокировке из-за IO или проблем с сетью, то нагрузка на процессор должна быть ниже, либо вообще отсутствовать.

Вывод команды ‘top’ утверждает, что этот процесс вообще не нагружает CPU (либо нагрузка настолько мала, что её можно считать нулевой). Однако есть весьма важное различие между процессом, который полностью завис, не имея вообще шанса получить квант процессора, и процессом, который постоянно просыпается из состояния ожидания и затем сразу снова засыпает (например, некая операция опроса (poll), которая постоянно завершается по таймауту, а затем процесс по ходу выполнения вызывает её снова и засыпает). Для того, чтобы распознать эти два состояния, команды ‘top’, к сожалению, недостаточно. Но по крайней мере мы уже выяснили, что этот процесс не пожирает процессорное время.

Давайте попробуем другие инструменты. Обычно, если процесс кажется зависшим подобным образом (0% CPU обычно означает, что процесс находится в каком-то блокирующем системном вызове — который приводит к тому, что ядро усыпляет процесс), я запускаю strace на этом процессе чтобы отследить, на каком системном вызове он в настоящий момент застрял. Если же процесс на самом деле не совсем завис, а периодически возвращается из системного вызова и просыпается, то это тоже будет видно в выводе strace (системный вызов будет периодически завершаться, а затем вызываться снова):

Давайте попробуем pstack (на Linux pstack — это всего лишь скрипт-обёртка для отладчика GDB). Pstack ничего не скажет нам о внутренней кухне ядра, но по крайней мере укажет, что это там за системный вызов (обычно это выглядит как вызов функции библиотеки libc на вершине пользовательского стека):

^C
^Z
[1]+ Stopped pstack 27288

]# kill %%
[1]+ Stopped pstack 27288
[root@oel6

Pstack тоже завис без всяких объяснений!

Итак, мы до сих пор не знаем, завис ли наш процесс на 100% (увы), либо всего лишь на 99.99% (просыпается и сразу засыпает) — а также не знаем, где именно это произошло.

Куда ещё можно посмотреть? Есть ещё одно часто доступное место — поля status и WCHAN, содержимое которых можно исследовать с помощью старой-доброй команды ps (хм… возможно, стоило запустить её сразу, чтобы удостовериться, что мы имеем дело не с зомби):

Чтобы удостовериться, что процесс продолжает находиться в одном и том же состоянии, ps нужно запустить несколько раз подряд (вы же не хотите прийти к ложному заключению на основании единственной попытки, сделанной в неудачный момент?). Однако здесь я храбро показываю только один запуск.

Процесс находится в состоянии D («беспробудный сон»), что обычно связано с дисковым вводом-выводом (о чём так же говорит и man-страница к ps). К тому же поле WCHAN (имя функции, которая привела процесс к состоянию спячки/ожидания) немного обрезано. Я могу добавить опцию к вызову ps, чтобы сделать вывод этого поля чуть шире, однако поскольку его содержимое в любом случае идёт из системы /proc, давайте заглянем прямо в источник (опять же, было бы неплохо сделать это несколько раз, чтобы удостовериться, завис ли процесс полностью, или же просто очень часто и помногу спит):

]# cat /proc/27288/wchan
rpc_wait_bit_killable

Хм… Похоже, процесс ожидает какой-то вызов RPC. Это обычно означает, что процесс общается с другими процессами (либо на локальной машине, либо вообще на удалённом сервере). Но мы по-прежнему не знаем, почему.

Есть ли какое-нибудь движение, или процесс совсем завис?

Перед тем, как перейти к самому «мясу» статьи, давайте определим, завис ли процесс окончательно, или нет. На современных ядрах об этом можно узнать, изучая /proc/PID/status. Я выделил для наглядности интересные нам значения:

]# cat /proc/27288/status
Name: find
State: D (disk sleep)
Tgid: 27288
Pid: 27288
PPid: 27245
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups: 0 1 2 3 4 6 10
VmPeak: 112628 kB
VmSize: 112280 kB
VmLck: 0 kB
VmHWM: 1508 kB
VmRSS: 1160 kB
VmData: 260 kB
VmStk: 136 kB
VmExe: 224 kB
VmLib: 2468 kB
VmPTE: 88 kB
VmSwap: 0 kB
Threads: 1
SigQ: 4/15831
SigPnd: 0000000000040000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: ffffffff,ffffffff
Cpus_allowed_list: 0-63
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 9950
nonvoluntary_ctxt_switches: 17104

Процесс находится в состоянии D — дисковый сон («беспробудный» сон). Также обратите внимание на значения voluntary_ctxt_switches и nonvoluntary_ctxt_switches — они подскажут нам, сколько раз процессор получал кванты CPU (или отдавал назад). Затем, спустя несколько секунд, запустите команду повторно и проверьте, не увеличились ли значения. В моём случае числа не увеличились, и потому я бы предположил, что процесс завис намертво (ну, или по крайней мере ни разу не просыпался в течение тех нескольких секунд между командами). Итак, теперь я могу быть более уверен в том, что процесс полностью завис (а не просто летит ниже радаров, постоянно потребляя 0.04% времени процессора).

Кстати, есть ещё два места, где можно посмотреть количество переключений контекста (а второе из них, вдобавок, доступно и на древних ядрах):

]# cat /proc/27288/sched
find (27288, #threads: 1)
— se.exec_start: 617547410.689282
se.vruntime: 2471987.542895
se.sum_exec_runtime: 1119.480311
se.statistics.wait_start: 0.000000
se.statistics.sleep_start: 0.000000
se.statistics.block_start: 617547410.689282
se.statistics.sleep_max: 0.089192
se.statistics.block_max: 60082.951331
se.statistics.exec_max: 1.110465
se.statistics.slice_max: 0.334211
se.statistics.wait_max: 0.812834
se.statistics.wait_sum: 724.745506
se.statistics.wait_count: 27211
se.statistics.iowait_sum: 0.000000
se.statistics.iowait_count: 0
se.nr_migrations: 312
se.statistics.nr_migrations_cold: 0
se.statistics.nr_failed_migrations_affine: 0
se.statistics.nr_failed_migrations_running: 96
se.statistics.nr_failed_migrations_hot: 1794
se.statistics.nr_forced_migrations: 150
se.statistics.nr_wakeups: 18507
se.statistics.nr_wakeups_sync: 1
se.statistics.nr_wakeups_migrate: 155
se.statistics.nr_wakeups_local: 18504
se.statistics.nr_wakeups_remote: 3
se.statistics.nr_wakeups_affine: 155
se.statistics.nr_wakeups_affine_attempts: 158
se.statistics.nr_wakeups_passive: 0
se.statistics.nr_wakeups_idle: 0
avg_atom: 0.041379
avg_per_cpu: 3.588077
nr_switches: 27054
nr_voluntary_switches: 9950
nr_involuntary_switches: 17104
se.load.weight: 1024
policy: 0
prio: 120
clock-delta: 72

Здесь нужно смотреть на число nr_switches (которое равно nr_voluntary_switches + nr_involuntary_switches ).

Общее число nr_switches — 27054 в приведённом выше куске, а также находится в третьем поле в выводе /proc/PID/schedstat:

]# cat /proc/27288/schedstat
1119480311 724745506 27054

И оно не увеличивается…

Исследуем внутреннюю кухню ядра с помощью файловой системы /proc

Похоже, наш процесс весьма крепко завис :). Strace и pstack бесполезны. Они используют системный вызов ptrace() для подключения к процессу и внедрения в его память, но поскольку процесс безнадёжно завис, скорее всего в каком-то системном вызове, я предполагаю, что и вызов ptrace() тоже зависает сам по себе (кстати, я как-то попробовал запустить strace на сам strace в тот момент, когда он подключается к целевому процессу. И это привело к крэшу процесса. Я предупредил! 🙂

Как же мы узнаем, в каком системном вызове мы зависли, не имея ни strace, ни pstack? К счастью мы работаем на современном ядре! Поприветсвуем /proc/PID/syscall!

]# cat /proc/27288/syscall
262 0xffffffffffffff9c 0x20cf6c8 0x7fff97c52710 0x100 0x100 0x676e776f645f616d 0x7fff97c52658 0x390e2da8ea

Зашибись! И что мне с этим делать.
Ну, обычно эти числа для чего-то нужны. Если мы видим что-нибудь вроде “0xAVeryBigNumber” то это обычно адрес в памяти (и их можно использовать с утилитами вроде pmap), а если число маленькое — скорее всего это индекс к какому-нибудь массиву. Например, массив дескрипторов открытых файлов (который вы можете лицезреть в /proc/PID/fd), или, в этом случае, поскольку мы имеем дело с системными вызовами — это номер системного вызова, в котором находится процесс! Итак, мы теперь знаем, что процесс завис в системном вызове #262!

Заметьте, что номера системных вызовов могут различаться между разными ОС, версиями ОС и платформами, а потому вам понадобится правильный заголовочный файл от вашей ОС. Неплохо начать с поиска “syscall*” в папке /usr/include. На моей версии и платформе Linux (64bit) системные вызовы определены в файле /usr/include/asm/unistd_64.h :

]# grep 262 /usr/include/asm/unistd_64.h
#define __NR_ newfstatat 262

Как бы то ни было, этот системный вызов — “new-fstat-at” — даёт возможность читать свойства файла очень похоже на то, как это делает обычный системный вызов stat. И мы зависли как раз в операции чтения метаданных файла. Итак, мы продвинулись ещё на шаг дальше. Однако мы до сих пор так и не знаем, почему случилось зависание!

Ну что ж, пришло время поприветствовать моего маленького друга /proc/PID/stack, который позволит вам просматривать цепочку ядерного стека процесса просто распечатывая содержимое proc-файла.

]# cat /proc/27288/stack
[] rpc_wait_bit_killable+0x24/0x40 [sunrpc]
[] __rpc_execute+0xf5/0x1d0 [sunrpc]
[] rpc_execute+0x43/0x50 [sunrpc]
[] rpc_run_task+0x75/0x90 [sunrpc]
[] rpc_call_sync+0x42/0x70 [sunrpc]
[] nfs3_rpc_wrapper.clone.0+0x35/0x80 [nfs]
[] nfs3_proc_getattr+0x47/0x90 [nfs]
[] __nfs_revalidate_inode+0xcc/0x1f0 [nfs]
[] nfs_revalidate_inode+0x36/0x60 [nfs]
[] nfs _getattr+0x5f/0x110 [nfs]
[] vfs_getattr+0x4e/0x80
[] vfs_fstatat+0x70/0x90
[] sys_newfstatat+0x24/0x50
[] system_call_fastpath+0x16/0x1b
[] 0xffffffffffffffff

Имея на руках полный стек ядра для данной задачи, мы можем изучать его снизу вверх и пытаться разобраться, каким же образом вызов функции rpc_wait_bit_killable привёл к вызову планировщика и помещению нас в спящее состояние.

Чтобы разобраться, не завис ли какой-нибудь из этих вспомогательных потоков в коде, связанном с сетью, вам также нужно рассмотреть и их стеки, хотя, например, kworker-ы выполняют гораздо больше функций, чем просто соединение RPC для NFS. Во время отдельного эксперимента (просто копируя большой файл через NFS) я поймал одного из kworker-ов, ожидающего в коде общения с сетью:

[] __cond_resched+0x2a/0x40
[] lock_sock_nested+0x35/0x70
[] tcp_sendmsg+0x29/0xbe0
[] inet_sendmsg+0x48/0xb0
[] sock_sendmsg+0xef/0x120
[] kernel_sendmsg+0x41/0x60
[] xs_send_kvec+0x8e/0xa0 [sunrpc]
[] xs_sendpages+0x173/0x220 [sunrpc]
[] xs_tcp_send_request+0x5d/0x160 [sunrpc]
[] xprt_transmit+0x83/0x2e0 [sunrpc]
[] call_transmit+0xa8/0x130 [sunrpc]
[] __rpc_execute+0x66/0x1d0 [sunrpc]
[] rpc_async_schedule+0x15/0x20 [sunrpc]
[] process_one_work+0x13e/0x460
[] worker_thread+0x17c/0x3b0
[] kthread+0x96/0xa0
[] kernel_thread_helper+0x4/0x10

Вероятно, не составит труда включить трассировку ядра и узнать, какие именно потоки ядра общаются между собой, но в данной статье я не хочу этим заниматься. Пусть это будет практическим (и простым) диагностическим упражнением!

Разбираемся и «чиним»

В любом случае, благодаря возможности очень легко получить распечатку стека ядра в современных Linux (не могу точно сказать, в какой именно версии ядра это появилось), мы смогли последовательно заключить, где именно зависла наша команда find — а именно, в коде NFS в ядре Linux. А когда вы имеете дело с зависанием, связанном с NFS, скорее всего следует подозревать проблемы с сетью. Если вам любопытно, каким образом я воспроизвёл указанную проблему, то всё очень просто: я смонтировал том NFS из виртуальной машины, запустил команду find, а затем приостановил машину. Это привело к тем же симптомам, как если бы имелась сетевая (конфигурация, firewall) проблема, где соединение молча обрывается без уведомления концевых узлов TCP, или где пакеты по какой-то причине просто не проходят.

Профилирование потоков ядра «на коленке»

Заметьте, что файл /proc/PID/stack выглядит как обычный текстовый файл. А потому вы можете легко получить профиль потоков ядра! Вот, как можно «на коленке» узнать текущий системный вызов, а также раскрутку стека ядра (если находимся в системном вызове), а затем объединить всё это в полуиерархический профиль:

Это позволит очень грубо оценить, где в ядре процесс проводит своё время (если вообще проводит). Номера системных вызовов выделены отдельно сверху. «running» означает, что во время диагностики процесс работал в пространстве пользователя (а не в системных вызовах). Так, 69% времени процесс находился в пользовательском коде; 25% в системном вызове #180 (nfsservctl на моей системе), и 6% в системном вызове #247 (waitid).

Выше автор использует вызов некоего скрипта /home/oracle/os_explain. Раздобыть его можно по ссылке — прим. перев.

В выводе видно ещё две «функции», по какой-то причине они не отобразились по именам. Однако их адреса известны, поэтому мы можем проверить их вручную:

Похоже, что это возврат из системного вызова для 32-битной подсистемы, однако поскольку эта функция не является сама по себе системным вызовом (это всего лишь внутренняя вспомогательная функция), видимо, обработчик /proc/stack не отобразил её имя. Возможно также, что эти адреса показаны, поскольку состояние /proc не консистентно для читателя: пока один поток модифицирует эти структуры памяти и элементы, читающие потоки иногда видят устаревшие данные.

Проверим заодно второй адрес:

Ничего не нашли? Хорошо, однако отладка на этом не закончена! Поищем что-нибудь инересное вокруг данного адреса. Например, удалим пару последних цифр в конце адреса:

Ещё о профилировании стека

Заметьте, что существующие различные утилиты раскрутки стека — Perf на Linux, утилиты Oprofile и profile из DTrace на Solaris фиксируют регистры указателя инструкций (EIP на 32-битном Intel, или RIP на x64), а также указателя стека (ESP на 32бит и RSP на x64) для текущего потока на процессоре, а затем проходят по указателям стека назад. Таким образом, эти утилиты способны показать лишь те потоки, которые выполняются на CPU в момент тестирования! Это, безусловно, замечательно, когда мы ищем проблемы с высокой нагрузкой процессора, однако совершенно бесполезно для диагностики намертво зависших, либо находящихся в длительном ожидании/спячке процессов.

Утилиты вроде pstack на Linux,Solaris,HP-UX, procstack (на AIX), ORADEBUG SHORT_STACK и просто чтение псевдофайла /proc/PID/stack являются хорошим дополнением (но не заменой) утилит профилирования CPU — покуда они дают доступ к памяти процесса независимо от его состояния в планировщике и читают стек прямо оттуда. Если процесс спит и не касается CPU, то вершина стека процесса может быть прочитана из сохранённого контекста — который сохраняется в памяти ядра планировщиком ОС во время переключения контекстов.

Безусловно, утилиты профилирования событий процессора зачастую могут дать гораздо больше, чем просто pstack, OProfile, Perf и даже провайдер CPC в DTrace (на Solaris11). Например, устанавливать и считывать внутренние счётчики процессора, чтобы оценить такие вещи, как количество пропущенных циклов CPU при ожидании доступа к памяти; количество промахов кэшей L1/L2 и т.д. Но лучше почитайте, что пишет по этому поводу Kevin Closson: (Perf, Oprofile)

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Модули ядра Linux

Оглавление

Что такое модули ядра

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

Примеры модулей ядра — это драйверы различных устройств.

В этой статье вы узнаете:

Получение информации о модулях

Модули храняться в директории /usr/lib/modules/ВЫПУСК_ЯДРА. Текущую папку с модулями можно узнать командой:

Имена модулей часто содержат символы подчёркивания (_) или дефисы (—); при этом данные символы являются взаимозаменяемыми в командах modprobe и в конфигурационных файлах в директории /etc/modprobe.d/.

Команда lsmod показывает драйверы и другие модули, которые загружены в данный момент. Чтобы увидеть, какие модули загружены в данный момент, выполните:

На самом деле, это одно и то же. Информация считывается из /proc/modules и данные команды только выводят её в более понятном для восприятия виде.

Для показа информации о модуле используется команда modinfo:

Если вы получили ошибку:

То запустите modinfo с sudo.

К примеру, чтобы узнать информацию о модуле iwlwifi:

Как понять вывод modinfo

Вывод modinfo обширен и содержит много информации.

Строка «filename» показывает полный путь до файла модуля.

В строке «description» описание модуля, например, «Intel(R) Wireless WiFi driver for Linux».

Рассмотрим, как интерпретировать строки

на примере модуля i915

firmware:

Многим устройствам для правильной работы нужны две вещи: драйвер и прошивка. Драйвер запрашивает прошивку из файловой системы в /lib/firmware. Это специальный файл, необходимый для аппаратного обеспечения, это не бинарный файл. Затем дайвер делает всё, что нужно для загрузки прошивки в устройство. Прошивка выполняет программирование оборудования внутри устройства.

alias:

Эту запись можно разделить на части символами двоеточия (:)

intree:

Все модули ядра начинают свои разработки как вне дерева. Как только модуль принимается для включения, он становится модулем внутри дерева. Модули без этого флага (установленного в N) могут испортить ядро.

vermagic:

При загрузке модуля строка vermagic проверяются на совпадение с текущей версией ядра. Если они не совпадают, вы получите ошибку, и ядро откажется загружать модуль. Вы можете преодолеть это, используя в modprobe флаг —force. Естественно, эти проверки существуют для вашей защиты, поэтому использование этой опции опасно.

Для вывода списка опций, установленных для загруженного модуля:

Если вы получили ошибку:

То установите пакет sysfsutils.

Пример вывода для модуля iwlwifi:

Для отображения полной конфигурации всех модулей:

Чтобы отобразить конфигурацию определённого модуля:

Чтобы перечислить зависимости модуля (или псевдонима), включая сам модуль:

Автоматическая загрузка модуля с помощью systemd

Сегодня загрузка всех необходимых модулей выполняется udev автоматически, поэтому нет необходимости помещать модули в какой-либо файл конфигурации. Однако в некоторых случаях вам может потребоваться загрузить дополнительный модуль во время процесса загрузки компьютера или добавить в чёрный список другой модуль для правильной работы компьютера.

Модули ядра могут быть явно перечислены в файлах в /etc/modules-load.d/ для systemd, чтобы загрузить их во время включения компьютера. Каждый файл конфигурации имеет имя в стиле /etc/modules-load.d/

Пример файла /etc/modules-load.d/virtio-net.conf

Кроме указанной директории, также считываются файлы конфигурации из /run/modules-load.d/*.conf и /usr/lib/modules-load.d/*.conf.

Обратите внимание, что обычно лучше полагаться на автоматическую загрузку модулей с помощью идентификаторов PCI, USB-идентификаторов, идентификаторов DMI или аналогичных триггеров, закодированных в самих модулях ядра, вместо статической конфигурации, подобной этой. Фактически, большинство современных модулей ядра уже подготовлены для автоматической загрузки.

Ручная обработка модуля (включение и отключение модулей и драйверов)

Модули ядра обрабатываются инструментами, предоставляемыми пакетом kmod. Вы можете использовать эти инструменты вручную.

Чтобы загрузить модуль применяется команда вида:

Для выгрузки (выключения) модуля:

Или альтернативная команда:

Как задействовать драйвер без его установки

Рассмотрим реальный пример, когда может пригодиться запуск драйвера из файла.

Эти драйвера предназначены для работы таких современных карт с поддержкой стандарта Wi-Fi AC как:

Эти драйвера поддерживают режим монитора и беспроводную инъекцию, то есть подходят для аудита безопасности Wi-Fi сетей на 2.4 и 5 Ghz, в том числе с поддержкой Wi-Fi стандарта AC.

В принципе, в репозиториях Kali Linux уже имеется данный драйвер:

Но его версия 5.6.4. Но уже доступна версия 5.7.0. Предположим, мы хотим попробовать версию 5.7.0 без установки её в систему.

Итак, удаляем версию из репозитория (если она была установлена)

Проверим, что модуль не загружен:

И при попытке его загрузить возникает ошибка:

То есть, неизвестный символ в модуле. Суть такая же — модуль не найден, но ранее существовал, поэтому от него остались упоминания в списках зависимостей.

Установим зависимости, необходимые для компиляции данного драйвера:

Клонируем репозиторий — обратите внимание на использование опции -b с которой указана интересующая нас ветка (в данном случае название ветки совпадает с версией драйвера):

Компилируем, но не делаем установку, поскольку мы в принципе не хотим устанавливать этот модуль:

У нас есть два способа загрузить (включить) модуль — с помощью insmod или с помощью команды modprobe. Команда insmod удобнее, т. к. можно указать скомпилированный файл драйвера, а команда modprobe лучше обрабатывает зависимости, поэтому рассмотрим оба варианта.

Загрузка модуля без установки (используя insmod)

Для включения модуля из файла используйте команду вида:

Файлы модулей имеют расширение .ko, в нашем случае имя файла 88XXau.ko, поэтому команда следующая:

Проверяем, был ли загружен модуль:

Первая строка показывается, что модуль 88XXau загружен, а в последующих строках показаны модули, которые использует 88XXau (то есть которые являются для него зависимостями).

Загрузка модуля без установки (используя modprobe)

Второй вариант чуть более сложный в настройке, но для загрузки модуля не нужно указывать полный путь до файла драйвера.

Выгрузим модуль, если он был загружен ранее:

В нашем случае для этого нужно выполнить такую команду:

Обновим список зависимостей всех модулей (кстати, ключ -a в следующей команде можно пропускать, т.к. он предполагается по умолчанию):

Теперь для загрузки модуля можно использовать обычную команду modprobe:

Проверим версию модуля:

Обратите внимание на строки:

Используется версия v5.7.0 — именно этого мы и добивались.

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

Драйверы можно установить с помощью DKMS. Это система, которая автоматически перекомпилирует и устанавливает модуль ядра при установке или обновлении нового ядра. Чтобы использовать DKMS, установите пакет dkms.

С помощью DKMS устанавливаются драйверы из официальных репозиториев. Также с помощью DKMS можно установить и драйверы из прочих репозиториев (например, rtl8812au, который чуть выше был взять в качестве примера, это поддерживает) — для этого следуйте официальным инструкциям по установке от разработчиков, а описанный чуть выше метод запуска драйвера без установки предназначен для тестирования.

Запрет на включение модулей (чёрный список модулей)

Чёрный список в контексте модулей ядра — это механизм, предотвращающий загрузку модуля ядра. Это может быть полезно, если, например, связанное оборудование не требуется или если загрузка этого модуля вызывает проблемы: например, могут быть два модуля ядра, которые пытаются управлять одним и тем же компонентом оборудования, и загрузка их вместе приведёт к конфликту.

Использование файлов в /etc/modprobe.d/

Создайте файл .conf внутри /etc/modprobe.d/ и добавьте строку для каждого модуля, который вы хотите добавить в черный список, используя ключевое слово blacklist. Например, если вы хотите запретить загрузку модуля pcspkr, создайте файл /etc/modprobe.d/nobeep.conf и добавьте в него строку:

Некоторые модули загружаются как часть initramfs. То есть можно выделить модули, которые:

Для запрета загрузки модулей первого типа (загружаемые из файлов .ko) достаточно внести запись об этом модуле в файл /etc/modprobe.d/*.conf с директивой blacklist.

Для модулей второго типа (загружаемые как часть initramfs), кроме создания конфигурационного файла, также необходимо пересоздать initramfs.

Примечание: initramfs (initial ramdisk) — это начальная среда ramdisk для загрузки ядра Linux. Начальный ramdisk — это, по сути, очень маленькая среда (раннее пользовательское пространство), которая загружает различные модули ядра и настраивает необходимые вещи перед передачей управления init. Это позволяет, например, иметь зашифрованные корневые файловые системы и корневые файловые системы на программном массиве RAID.

Примечание. Команда blacklist внесёт модуль в чёрный список, чтобы он не загружался автоматически. Но при этом модуль может быть загружен, если от него зависит другой модуль, не включенный в чёрный список, а также по прежнему можно загрузить модуль вручную. Тем не менее есть обходной путь для этого поведения; Команда install указывает modprobe запускать пользовательскую команду вместо того, чтобы как обычно вставлять модуль в ядро, поэтому вы можете принудительно заставить модуль всегда не загружаться с помощью рассмотренной далее конструкции. Допустим, вы создали файл /etc/modprobe.d/blacklist.conf чтобы заблокировать загрузку модуля ИМЯ_МОДУЛЯ. Чтобы это сделать надёжно, добавьте в этот файл:

Это надёжно заблокирует загрузку указанного модуля, а также любого другого, зависящего от него.

Как пересоздать initramfs для блокировки модулей

Если вы блокируете модули, которые загружаются из initramfs, то после их добавления в файл /etc/modprobe.d/*.conf, необходимо пересоздать initramfs.

На Debian, Kali Linux, Linux Mint, Ubuntu и их производных это делается так:

В Arch Linux, BlackArch и их производных это делается так:

В Arch Linux команда

распечатает все автоматически обнаруженные модули: чтобы предотвратить загрузку некоторых из этих модулей initramfs, внесите их в чёрный список в файле .conf в /etc/modprobe.d, и он будет добавлен хуком modconf во время генерации образа. Запуск

выведет список всех модулей, задействованных различными хуками (например, хук filesystems, хук block и т. д.).

Блокировка модулей в начале загрузки Linux (отключение модулей в командной строке ядра)

Это может быть очень полезно, если неисправный модуль делает невозможным загрузку вашей системы. Вы можете занести в чёрный список модули в меню загрузчика. Просто добавьте

в строку с параметрами загрузки ядра.

Примеры редактирования параметров загрузки ядра для популярных дистрибутивов вы найдёте в статье «Как в Linux сбросить забытый пароль входа». Также смотрите статью «Как изменить параметры загрузки Linux в UEFI».

Примечание. Если вы заносите в чёрный список более одного модуля, имейте в виду, что они разделены только запятыми. Пробелы или что-либо ещё могут нарушить синтаксис.

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

Как заблокировать все сетевые интерфейсы на компьютере

Предположим, необходимо, чтобы на компьютере была заблокирована любая сетевая активность, то есть и проводные, и беспроводные сети. Существует команда rfkill, но она предназначена для блокировки только беспроводных сетей. Поэтому найдём другой способ.

Алгоритм действий следующий:

Чтобы узнать, какие драйверы задействованы в Linux для работы сетевых карт, выполните команду:

Строки «configuration:» содержат информацию о драйверах. Для беспроводной карты это «driver=iwlwifi», а для проводного сетевого интерфейса это «driver=r8169».

Создаём файл /etc/modprobe.d/block-network.conf и добавляем в него:

Так выглядит настройка сети в нормальном состоянии, виден проводной и беспроводной адаптеры:

После перезагрузки невозможно будет включить сеть, поскольку компьютер не сможет использовать сетевые интерфейсы без драйверов:

При попытке загрузить модули вручную, например:

Эти модули не будут загружаться благодаря команде install.

Вы не сможете включить любую сеть вплоть до удаления файла /etc/modprobe.d/block-network.conf и перезагрузки. Тем не менее при подключении других сетевых адаптеров, они будут использоваться. Данный способ надёжно защитит от случайного использования сети при условии, что вы контролируете подключение новых физических устройств к компьютеру.

Как надёжно выключить веб камеру

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

Сейчас мы научимся отключать драйвер веб камеры, чтобы её невозможно было использовать.

Даже если у вас ноутбук, скорее всего, веб камера подключена внутри корпуса к USB хабу, то есть это USB устройство. Вывести список USB устройств в системе можно командой:

Обратите внимание на IMC Networks USB2.0 HD UVC WebCam в приведённом списке — это и есть веб камера ноутбука.

Чтобы определить драйверы, которые нужны для работы любого USB или с PCI устройства в вашей системе, обратитесь к статье «Как узнать, какие модули (драйверы) связаны с USB и PCI устройствами».

Воспользуемся следующей командой:

Видим, что для устройства USB2.0 HD UVC WebCam используется драйвер uvcvideo.

Создаём файл /etc/modprobe.d/block-webcam.conf и блокируем в нём запуск модуля ядра uvcvideo:

После перезагрузки система не сможет использовать вебкамеру, пока не будет удалён файл block-webcam.conf и выполнена перезагрузка.

Настройка параметров модуля

Чтобы передать параметр в модуль ядра, вы можете передать их вручную с помощью modprobe или убедиться, что определённые параметры всегда применяются с помощью файла конфигурации modprobe или с помощью командной строки ядра.

Вручную во время загрузки, используя modprobe

Основной способ передачи параметров в модуль — использование команды modprobe. Параметры указываются в командной строке с использованием простых назначений ключ=значение:

Используя файлы в /etc/modprobe.d/

Файлы в каталоге /etc/modprobe.d/ можно использовать для передачи настроек модуля в udev, который будет использовать modprobe для управления загрузкой модулей во время загрузки системы. Файлы конфигурации в этом каталоге могут иметь любое имя, если они заканчиваются расширением .conf, например /etc/modprobe.d/myfilename.conf. Синтаксис:

Например, содержимое файла /etc/modprobe.d/thinkfan.conf:

Добавление опций модуля во время загрузки системы (ииспользование командной строки ядра)

Если модуль встроен в ядро, вы также можете передать опции модулю с помощью командной строки ядра. Для всех распространённых загрузчиков правильный синтаксис:

Псевдонимы

Псевдонимы — это альтернативные имена для модуля. Например:

означает, что вы можете использовать

Вы также можете использовать подстановочные знаки в стиле оболочки, поэтому

имеет тот же эффект.

Чтобы создать псевдоним в конфигурационном файле /etc/modprobe.d/myalias.conf:

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

Пример файла /etc/modprobe.d/modprobe.conf

Ошибки при работе с модулями

Модули не загружаются

Если определённый модуль не загружается и в журнале загрузки

говорится, что модуль находится в чёрном списке, но в каталоге /etc/modprobe.d/ нет соответствующей записи, проверьте другую папку modprobe на наличие записи о занесении в чёрный список: /usr/lib/modprobe.d/.

Предупреждение. Игнорирование проверок версий для модуля ядра может привести к сбою ядра или непредсказуемому поведению системы из-за несовместимости. Используйте —force-vermagic только с максимальной осторожностью.

modprobe: ERROR: could not insert ‘…’: Unknown symbol in module, or unknown parameter (see dmesg)

Ошибка вызвана тем, что ранее модуль присутствовал в системе и о нём оставлена запись в списке зависимостей, но на момент ошибки модуль отсутствует (удалён).

Для обновления списка зависимостей выполните команду:

modprobe: FATAL: Module … not found in directory /lib/modules/…

Означает, что модуль, который вы пытаетесь запустить, не существует.

Если ранее модуль (драйвер) запускался, но затем появилась указанная ошибка, то она может быть связана с тем, что было обновлено ядро, а модуль для новой версии ядра не был скомпилирован.

Источник