Модули ядра Linux
Как вы знаете из статьи что такое ядро Linux, ядро является монолитным. Это значит, что весь исполняемый код сосредоточен в одном файле. Такая архитектура имеет некоторые недостатки, например, невозможность установки новых драйверов без пересборки ядра. Но разработчики нашли решение и этой проблеме, добавив систему модулей.
Ядро Linux позволяет драйверам оборудования, файловых систем, и некоторым другим компонентам быть скомпилированными отдельно — как модули, а не как часть самого ядра. Таким образом, вы можете обновлять драйвера не пересобирая ядро, а также динамически расширять его функциональность. А еще это значит, что вы можете включить в ядре только самое необходимое, а все остальное подключать с помощью модулей. Это очень просто.
Модули ядра Linux
В этой статье мы рассмотрим модули ядра Linux, основы работы с ними, просмотр уже загруженных модулей, загрузку, установку и отключение модулей. А также полное отключение, добавление в черный список и добавление новых модулей ядра.
Модули ядра Linux собираются только под определенную версию ядра, есть способ запуска модуля независимо от версии ядра, если они совместимы с помощью dkms, но об этом мы поговорим позже.
Находятся все модули в папке /lib/modules/. Учитывая, что модули рассчитаны только для определенной версии ядра, то в этой папке создается отдельная подпапка, для каждой установленной в системе версии ядра. В этой папке находятся сами модули и дополнительные конфигурационные файлы, модули отсортированы по категориям, в зависимости от назначения например:
Перед тем как переходить к практике, давайте коротко рассмотрим основные команды для управления модулями.
- lsmod — посмотреть загруженные модули
- modinfo — информация о модуле
- insmod — загрузить модуль
- rmmod — удалить модуль
Работа с модулями ядра Linux выполняется, в основном, с помощью этих команд, но могут использовать и другие.
Все модули
Такая задача возникает нечасто, но если вы хотите посмотреть все установленные модули ядра Linux в системе, делается очень просто. Все модули расположены в папке /lib/modules, а поэтому очень просто вычислить их все одной командой, или даже просто зайти в папку файловым менеджером и посмотреть.
В Ubuntu команда будет выглядеть вот так:
dpkg -S *.ko | grep /lib/modules
Можно смастерить такую конструкцию с помощью find:
find /lib/modules -name *.ko
Можем искать только для текущего ядра:
find /lib/modules/$(uname -r) -name *.ko
Также, все модули записаны в конфигурационном файле /lib/modules/modules.aliases, поэтому мы можем просто посмотреть его содержимое:
Если хотим проверить установлен ли определенный модуль ядра Linux, отфильтруем вывод любой из команд с помощью grep:
find /lib/modules -name *.ko | grep vbox
Что загружено?
Все информация о загруженных модулях хранится в файле /proc/modules, мы можем ее вывести командой:
Но для этого дела есть более цивилизованные методы. Это утилита lsmod и modinfo. Чтобы посмотреть загруженные модули ядра linux выполните:
Удобно проверять загружен ли модуль с помощью grep:
sudo lsmod | grep vbox
А более подробную информацию о каждом модуле можно получить с помощью утилиты modinfo:
Здесь вы можете увидеть файл модуля, его лицензию, автора и зависимости. Зависимости — это те модули, которые должны быть загружены для его нормальной работы. К сожалению, не для всех модулей доступно нормальное описание, но вы можете попробовать посмотреть описание зависимостей модуля.
Запуск модулей ядра
Загрузить модуль ядра Linux можно с помощью команд modprobe или insmod. Например, загрузим модуль vboxdrv
sudo modprobe vboxdrv
Чтобы загрузить модуль ядра linux с помощью insmod необходимо передать адрес файла модуля:
sudo insmod /lib/modules/4.1.20-11-default/weak-updates/misc/vboxdrv.ko
Напоминаю, что его можно узнать с помощью команды modinfo. Запуск модуля ядра Linux предпочтительно выполнять с помощью modprobe, поскольку эта команда не только находит файл модуля в файловой системе, но и загружает все его зависимости.
Удаление модулей ядра
Здесь аналогично две команды — modprobe, позволяет удалить модуль если ей передать опцию -r, а также есть команда rmmod. Начнем с modprobe:
sudo modprobe -r vboxdrv
Другая команда в этом случае выглядит немного проще:
sudo rmmod vboxdrv
Если вы получили ошибку во время выгрузки модуля, например: rmmod: ERROR: Module vboxdrv is in use by: vboxnetadp vboxnetflt, значит он еще используется другими модулями, и сначала нужно выгрузить их. В данном случае это vboxnetadp и vboxnetflt. Правильно отработавшая команда не должна ничего возвращать.
rmmod vboxnetadp vboxnetflt
Блокирование загрузки модулей
Иногда, во время загрузки системы для используемых нами устройств, загружаются не те модули ядра Linux, они либо не поддерживают нужную функциональность либо конфликтуют с другими модулями. Ярким примером можно назвать загрузку драйвера b43 вместо brcmsmac для беспроводных адаптеров Broadcom. Чтобы решить эту проблему вы можете добавлять модули в черный список. Для этого достаточно добавить одну строчку в файл /etc/modprobe.d/blacklist.conf:
sudo vi /etc/modprobe.d/blacklist.conf
Этот код добавит в черный список модуль b43.
Автозагрузка модулей
Кроме чёрного списка существует отдельный каталог, в котором можно настроить автоматическую загрузку модулей при старте системы. Это /etc/modules.load.d/. Этот каталог тоже содержит конфигурационные файлы с расширением *.conf, в которых перечислены все модули, которые надо загружать при старте системы. Для добавления своего модуля можно воспользоваться файлом /etc/modules.load.d/modules.conf. Например, добавим brcmsmac:
sudo vi /etc/modules.load.d/modules.conf
Установка модулей ядра Linux
Собранные для этой версии ядра модули вы можете просто скопировать в нужную папку, собственно, мы так и поступаем, когда собираем ядро из исходников. Но с проприетарными драйверами и другими внешними драйверами, не поставляемыми в комплекте с ядром дело обстоит иначе. Эти модули поддерживают несколько версий ядра, но для их установки используется специальная технология — DKMS (Dynamic Kernel Module Support). Причем модуль, установленный таким образом один раз, будет пересобираться для каждой новой версии ядра автоматически. Обычно такие модули поставляются в виде пакетов, которые устанавливаются как и все другие приложения пакетным менеджером. Ручная установка модулей с помощью dkms выходит за рамки данной статьи.
Выводы
Скорее всего, вам редко придется возиться с этими модулями. Но работа с модулями ядра будет необходима, если ваш дистрибутив не поддерживает аппаратное обеспечение вашего устройства из коробки, а также когда вы работаете со сторонним программным обеспечением, таким как VirtualBox, Vmware и т д. Но очень полезно знать как обращаться с модулями, когда вам нужно добавить или удалить их. Даже если у вас нет необходимости в этом сейчас, вы можете протестировать, как все работает, чтобы быть вооруженным потом.
Какая команда компилирует модули
К сожалению ничего не могу сказать по сути заданных вами вопросов. Не имею, так сказать, практического опыта работы.
Судя по описанию формата DDS файловой системы там нет. Это ж, по сути, тот же…
10 Aug 2020, 12:24
Приветствую! То, что у лент нет файловой системы, это на все типы распространяется? Например DDS? Так же всё? Дело в том, что на DDS лентах хранится архив, 23 кассеты. Однако последняя была…
11 Jul 2020, 20:16
> Не надо вестись на маркетинговые 400ГБ для LTO-2. Несжатых на ней 200ГБ. Вот они реально и пишутся.
Обма^W Маркетинг- штука понятная. Но, тем не менее, заявлено 400 при сжатии — вынь, да положь…
8 Jul 2020, 17:34
Не надо вестись на маркетинговые 400ГБ для LTO-2. Несжатых на ней 200ГБ. Вот они реально и пишутся.
У меня ленты 3 и 4 поколения 400 и 800ГБ без сжатия соответственно. Вот на эти объемы я и…
6 Jul 2020, 17:07
Лента — это вещь, да. HDD крякнул и — все, ВСЯ инфа ушла в страну вечной охоты. Долгое хранение для хрупких вещей, коими являются жесткие диски, тоже, порой, еще та задача. Лента в этом плане лучше.…
Сборка модулей ядра
Ядро Linux содержит в себе множество кода, поддерживающее ту или иную возможность или оборудование. Основная часть этого кода (обычно это код поддержки процессоров, памяти и других базовых вещей) вкомпилирована в ядро и загружается с ним, а части кода, необходимые только части пользователей — драйверы устройств, поддержка файловых систем, и т.д. — собраны в виде модулей.
Модули могут подключаться к ядру по команде пользователя (modprobe, insmod) или автоматически при помощи udev, и быть выгружены либо самим ядром, либо командой rmmod.
Большинство модулей находится в пакете ядра, однако иногда по техническим, административным или юридическим причинам некоторые модули собираются отдельно.
О модулях и названиях
Поскольку в репозитории может быть множество ядер, модули собираются особым способом: имеется пакет с исходными кодами модуля, и пакеты с модулями, собранным для конкретного ядра. При этом SRPM последних содержит только .spec и патчи, а исходные коды получает по сборочным зависимостям. Таким образом, для модуля module и варианта ядра flavour у нас имеются пакеты с именами
- kernel-source-module — содержит только исходники
- kernel-modules-module-flavour — модуль module, собранный для ядра flavour (например, kernel-modules-nvidia-std-def)
Поле release пакетов с модулями заполняется так: alt.. , где
- — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
- — версия ядра в формате (2^16) * major + (2^8) * mid + minor, то есть 2.6.25=132633. Не пугайтесь, это число рассчитывает скрипт, описанный позже;
- — релиз пакета с ядром.
К примеру, модуль с nvidia для ядра kernel-image-std-def-2.6.25-alt8 будет называться kernel-modules-nvidia-std-def-173.14.12-alt1.132633.8.
Как собрать модуль локально
Данная фаза нужна в первую очередь для тестирования модуля, и, в общем-то, необязательна, но полезна для понимания процесса.
Что нам нужно
Кроме gcc, make и прочих стандартных сборочных вещей нам нужно kernel-headers-modules- (и всё что от него зависит). Этот пакет содержит ту часть исходных кодов, заголовочных файлов, make-файлов и скриптов, которые необходимы для сборки модулей для данного ядра.
Сборка
Скачав и распаковав исходники модуля, мы обнаружим что просто make обычно не работает. Эта проблема специфична для Sisyphus/ALT Linux и состоит в том, что для сборки модуля необходимы заголовки ядра, которые ищутся в каталоге /lib/modules//build , но не могут быть найдены там, потому что в ALT Linux и Sisyphus доступ пользователям в /lib/modules/ запрещён.
Для того, чтобы обойти эту проблему, нужно переопределить переменную (обычно KERNELSOURCE или KSRC ) в Makefile . Далее запускаем сборку, например make KSRC=/usr/src/linux-2.6.25-std-def . Обычно модуль после этого собирается.
Собранный модуль можно попробовать загрузить с помощью insmod , или положить его к другим модулям ядра в /lib/modules/ и загрузить modprobe . Если модуль загрузился и работает, то можно переходить к следующей части.
Как собрать модуль правильно
Почему предыдущий способ не является правильным? Потому что он не дистрибутивен. Для нормальной сборки нам нужны:
- знание git (крайне желательно хотя бы начальное знание!)
- умение пользоваться gear и hasher
- настроенный hasher
- доступ на git.alt (для публикации результатов)
- достаточно терпения
Шаблоны
Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо, была разработана схема, при которой для каждого модуля создается шаблон, а gear (при помощи директивы specsubst, в которой указывается flavour ядра) подгоняет этот шаблон к конкретному ядру (в том числе вычисляет релиз модуля). Остальная работа ложится на макрос %setup_kernel_module, который вычисляет все остальные параметры, нужные для сборки модуля: версию ядра, релиз ядра и релиз модуля. Сами шаблоны хранятся в git-репозитории, в котором есть множество веток, ветки с шаблонами называются template/module/distro, где module — это собственно название модуля (например, nvidia) а distro — это то, подо что мы собираем. Обычно это sisyphus, но, поскольку для разных бранчей шаблоны приходиться менять, можно установить поле distro в соответствующее значение. Обычно distro сейчас совпадает с именем бранча.
Подготовка рабочей директории
Нам потребуются утилита km-create-tag для сборки модулей из пакета kernel-build-tools:
# apt-get update && apt-get install kernel-build-tools
Для использования бранчей с шаблонами придётся их завести локально, например:
$ git branch -r | grep 'template/.*/sisyphus$' $ for m in subfs nvidia; do git checkout -b template/$m/sisyphus origin/template/$m/sisyphus; done
Сборка модуля из шаблона (с помощью gear-specsubst)
Когда вы собираете локально в тестовых целях, удобно установить параметр gear.specsubst.kflavour с вашим ядром:
$ git config --add gear.specsubst.kflavour std-def
После этого модуль можно собрать с помощью команды:
$ gear --commit --hasher hsh
Управление архитектурами, для которых собираются модули
Разные ветки ядер в разных репозиториях собираются для разного набора архитектур. Аналогично, многие модули имеют ограничения, в силу которых могут быть собраны не для всех возможных архитектур.
Начиная с kernel-build-tools-0.112-alt1, в нём реализована следующая функциональность:
В файле .gear/km-karch может сохраняться информация о архитектурах, для которых должен собираться модуль. Вот пример такого файла для virtualbox:
std-pae %ix86 * %ix86 x86_64
Такой файл описывает, что для ядра std-pae модуль должен собираться только на архитектуре i586, а для других ядер — для i586 и x86_64.
Эта информация учитывается скриптом km-create-tag, но может быть переопределена при помощи ключа -a этого скрипта (не рекомендуется, так как эта информация не сохранится для следующего запуска km-create-tag и модуль для каких-то архитектур может оказаться молча потерян).
Для того, чтоб это работало, в спек файле должны быть строки:
%define karch @karch@ ExclusiveArch: %karch
А в .gear/rules файле строка:
specsubst: kflavour karch
Создание тегов для сборки на git.alt (схема с gear-specsubst)
Например, для создания тега для модуля nvidia, собираемого для ядра std-def
cd modules && km-create-tag -k std-def nvidia
Или, для создания тегов для всех модулей, можно сделать:
$ GET ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/list/src.list | \ sed -r -n 's/^kernel-modules-([^[:space:]]+)-std-def[[:space:]].*/\1/p' | \ xargs -r km-create-tag -k std-def
Сборка модулей на git.alt
После этого можно запушить полученные бранчи и тэги на git.alt.
$ cd modules && git push --all && git push --tags && cd -
и добавить список модулей к последнему task'у (где предположительно уже добавлен на сборку соответствующий kernel-image):
$ for tag in $(cat out/taglist); do ssh git.alt task add repo packages/kernel-modules.git $tag; done
Следует, однако, учитывать, что updatemodules и km-create-tag не затирают файл out/taglist и вам нужно делать это вручную.
Если же вы обновляете ядро, но не собираетесь обновлять шаблоны модулей, можно сделать:
$ ssh git.alt task add [номер задания] kmodules std-def
это добавит в задание (где предположительно уже добавлен на сборку соответствующий kernel-image) все модули, собранные для ядра std-def.
Некоторые моменты
- Если в репозитории: kernel-image-std-def-3.0.4-alt0.M60P.1.i586.rpm
- Тогда в имени пакета: kernel-modules-emlog-std-def-0.51-alt2.196612.0.M60P.1.i586.rpm
0.51 - версия драйвера alt2 - релиз модуля (увеличивается при пересборке модуля без пересборки ядра) 196612 - версия ядра (генерируется автоматом, в зависимости от ядра) 0.M60P.1 - релиз ядра (автоматом)
В релиз модуля запаковывается версия + релиз ядра. СТРАШНО?
Пересобрать отдельно один модуль
Допустим нужно пересобрать в репозитарий некий модуль без пересборки ядра и всех модулей.
Ветка kernel-modules-rt3070-std-def/sisyphus — должна быть вытянута последняя из http://git.altlinux.org/gears/
- Изменяем ветку template/rt3070/sisyphus, коммитим наши изменения
- km-create-tag -k std-def rt3070
- Проверяем сборку чем-нибудь вроде: gear -t $(git describe) --hasher -- hsh $TMP/
Сборка нового модуля
Сборка kernel-source-module
Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так:
git clone git://git.altlinux.org/gears/k/kernel-source-kdbus.git mkdir kernel-source-module cd kernel-source-module git init-db распаковать исходники git add . git commit -a -m "version" (ну или вариации) git branch -m upstream (чтобы потом докладывать) git checkout -b master cp ../kernel-source-kdbus/.gear* . cp ../kernel-source-kdbus/*.spec mv kernel-source-kdbus.spec kernel-source-module.spec
Редактируем по образу и подобию kernel-source-module.spec — обычно там надо заменить имя модуля, версию, описание и changelog, а сам процесс сборки обычно можно не трогать.
git add .gear *.spec git commit -a
Далее собираем пакет при помощи gear. В результате в пакете должен оказаться всего один файл, а именно /usr/src/kernel/sources/kernel-source-module.tar.bz2
Обратите внимание на то, что некоторые пакеты с исходниками в своём имени содержат версию, например, kernel-source-kdbus-5.0.0.31-5.0.0.31-alt1. Это сделано для того, чтобы можно было иметь возможность собирать разные версии ядер с разными версиями модулей (например, новые модули не собираются с 2.6.18).
Создание нового шаблона
После сборки пакета с исходными кодами модуля, нам нужно создать новую ветку в репозитории с модулями:
$ cd modules $ git checkout -b template/module/sisyphus origin/template/kdbus/sisyphus $ rm -f SOURCES/* $ mv kernel-modules-kdbus.spec kernel-modules-module.spec
где module — название вашего модуля.
Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим:
$ git add *.spec && git commit -a
Внимание, верхняя запись changelog должна оставаться неизменной и состоять их тех жутких макросов, из которых она состоит в любом модуле ядра в любом актуальном репозитории ALT.
Как выложить свой модуль в репозиторий
Выкладывание модулей ничем не отличается от выкладывания обычных пакетов.
$ ssh git.alt init-db kernel-source-module $ cd kernel-source-module $ git remote add public git.alt:packages/kernel-source-module.git $ git push --all public
Выкладываем собственно модуль:
$ ssh git.alt init-db kernel-modules $ cd modules $ git remote add public git.alt:packages/kernel-modules.git $ git push --all public
Осталось собрать пакеты через git.alt.
Важное замечание: для того чтобы сборка прошла правильно, kernel-source-module должен быть собран до сборки kernel-modules-module.
Рекомендации по взаимодействию с мейнтейнерами ядер
Для нормальной совместной работы рекомендуется:
- При обновлении модуля обновлять сборки под максимальное количество ядер;
- Своевременно обновлять шаблоны в репозитории на git.alt;
- Оповестить мейнтейнеров ядер (в списке рассылки devel-kernel), о том что есть ваш модуль;
- Настроить git remote на kernel-modules других мейнтейнеров;
- В спеках kernel-modules- поле Packager установить в Kernel Maintainers team.
Про symvers и модули зависящие от других модулей
Иногда бывает, что пакет с модулями, должен собираться под другой пакет с модулями. Так например просиходит с gspca и v4l. Для нормальной сборки нам нужно 2 вещи: во-первых, проставить правильно зависимости на headers (у v4l есть свои хедеры), во-вторых, нужно импортировать файл с symvers. В gscpca проблема решилась добавлением следующей строчки в %prep фазу пакета с модулем gspca:
cat /usr/src/linux-%kversion-%flavour-%krelease/kernel-modules-v4l.symvers > Module.symvers
Компиляция модуля ядра [Решено]
DarkneSS - 10 Июнь, 2014 - 18:53
Когда собирается ядро, в конфиге сборки указывается, собирать ли драйвер, если собирать, то модулем или вшить. Вы можете взять исходники своего дистрибутивного ядра, если по умолчанию драйвер собирается модулем, то просто пересобирайте с заплаткой и замените файл модуля. Если же по умолчанию вшито, то придётся вам поставить самосборное ядро, наверно.
jacobtey - 10 Июнь, 2014 - 20:56
Это я понимаю. В моем случае это слава богу отдельный модуль. А поскольку кроме этого модуля я ничего в ядре менять (патчить) не собираюсь, а делать это придется на каждом обновленном ядре, то я и подумал, что возможно есть способ скомпилировать только этот модуль, как если бы он компилировался вместе со всем ядром, а затем этот скомпилированный модуль просто поставить в ядро вместо прежнего непропатченного. Нет желания каждый раз заводить эту шарманку на полчаса с риском упустить что-то нужное ради одного модуля.
AlexMad - 10 Июнь, 2014 - 21:23
Если я правильно понял суть вопроса, то должен огорчить - под каждое новое ядро придется пересобирать модуль.
jacobtey - 10 Июнь, 2014 - 21:27
Я не против собирать только модуль (пусть и под каждое новое ядро), но не все ядро целиком. Из двух зол выбирая меньшее.
jacobtey - 11 Июнь, 2014 - 09:22
У меня установлены ядро 3.13.0-24, в котором работает ресивер, и 3.13.0-29, в котором я пытаюсь его завести. Загружаемые исходники имеют только номер 3.13.0, и я не могу понять, что они в себе содержат. Насколько я понимаю последние две цифры в версии ядра от убунты означают количество заплаток от ее разработчиков. Как скачать соответствующие исходники?
Гость - 10 Июнь, 2014 - 20:23
А другие USB устройства нормально работают после наложения патча ? А то как я понял и ресивер и камера оба usb ?
jacobtey - 10 Июнь, 2014 - 21:29
Не,не. Камера встроена в лаптоп. Просто при пересборке ядра с помощью скрипта TBS я что-то сношу.
jacobtey - 11 Июнь, 2014 - 08:51
Вот что-то по-моему нашел, но сыпет ошибки.
Для того чтобы установить или прорпатчить модуль не обязательно пересобирать ядро.
Последовательность должна быть такая:
1) скачать и установить исходники ядра (sudo apt-get install linux-source). Они установятся в /usr/src/linux-xxxxx.tgz (например /usr/src/linux-2.6.24-21.tgz)
2) распаковать tgz (например /usr/src/linux-2.6.24-21)
3) скопировать /boot/config-xxxxx (например /boot/config-2.6.24-21-generic) в распакованную папку исходников ядра (например /usr/src/linux-2.6.24-21) и переименовать config-xxxx в ".config"(точка обязательна)
4) открыть файл .config в текстовом редакторе, найти там свой модуль (например yenta_socket) и посмотреть чтобы стока была не закоментировна и в конце было "=m"
5) наложить нужный пач на модуль, либо перейти в папку модуля (например drivers/pcmcia) и вручную поправить исходнай файл модуля (например yenta_socket.c)
6) из раздела распакованных исходников ядра (например /usr/src/linux-2.6.21-24) дать команду "make drivers/путь к модулю/модуль.ko" (например "make drivers/pcmcia/yenta_socket.ko"). Таким образом соберётся только один нужный нам модуль.
7) скопировать (либо перезаписать) собранный модуль (например drivers/pcmcia/yenta_socket.ko) в /lib/modules/название ядра/kernel/drivers/путь к модулю/ (например /lib/modules/2.6.24-21-generic/kernel/drivers/pcmcia/).
Cool запустить команду "depmod -a"
9) перезапустить систему
Отсюда
Я не знал, поэтому допишу от себя. В .config нужно еще отключить debug ядра, а то модули собираются чудовищных размеров.
jacobtey - 11 Июнь, 2014 - 13:28
Кое-как разобрался с ошибками при компиляции модуля. Почему-то коряво ложился патч. Пришлось руками переписывать из патча в исходник фронтенда. Теперь make завершается файлом stv0900.ko без ошибок.
Однако модуль не работает. После перезагрузки он не появляется в lsmod'e, а в ответ на принудительный запуск возвращает ошибку modprobe: ERROR: could not insert 'stv0900': Exec format error. Складывается впечатление, что исходники ядра не соответствуют установленному в системе.
Вот запара. Как это выяснить? Почему в примере исходник содержит номер микроверсии от убунты (2.6.24-21), а уменя скачивается только 3.13.0? Что-то изменилось с появлением третьей версии ядра?
Да, и если кому интересно, скрипт от TBS создавал модули в папке dvb/frontend,а в кубунте эти модули хранятся в папке dvb-frontend, поэтому систему клинило.
jacobtey - 17 Июнь, 2014 - 21:59