☰

Рискованно ли предоставлять возможность создания и установки нового ядра Linux и драйвера при перезагрузке?

tag-icon • tag-icon linux kernel reboot updates
Рискованно ли предоставлять возможность создания и установки нового ядра Linux и драйвера при перезагрузке?

Распространенной практикой является поставка драйверов ядра Linux (объектов ядра KO) в исходном коде, а также их сборка и установка на целевом компьютере. Например, драйверы дисплея NVIDIA и драйверы гостевых дополнений Oracle VirtualBox устанавливаются таким образом. Также распространено получение новых версий ядра (с соответствующими заголовками) через обновление системы. Для этого требуется пересборка и переустановка KO, в противном случае устройство перестанет работать после обновления.

В нашем сценарии запуска установки продукта мы хотим добавить шаг создания и установки KO при каждой загрузке. Пользователь может отказаться от этого и должен будет создать и установить KO вручную. Драйвер устройства взаимодействует с USB-устройством.

Соответствующие подробности:

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

  2. Пересборка драйвера занимает около двух секунд, а пропуск сборки во время обычной загрузки (не после обновления ядра) занимает миллисекунды.

  3. В маловероятном случае, если сборка не удастся, это не должно привести к сбою системы или сделать ее нестабильной. Однако наше аппаратное устройство работать не будет.

  4. Некоторые дистрибутивы могут разрешать регистрировать хуки, выполнять действия при определенных событиях, например, обновление ядра. Однако мы пытаемся реализовать что-то, что будет работать на большинстве дистрибутивов единообразно. Наш установщик — script+tar или script+rpm. К сожалению, для этого релиза у нас нет пропускной способности для подготовки собственных пакетов для всех дистрибутивов (например, в стиле Debian).

Вопросы:

  1. Приемлемо ли это решение? Если нет, то почему?

  2. Каковы потенциальные риски, связанные с этим подходом?

  3. Какое правильное/предпочтительное место для запуска make во время запуска? rc.local или скрипт в init.d или другое? Цель состоит в том, чтобы заставить его работать на большинстве дистрибутивов, используя тот же метод (если это вообще возможно).

решение1

Правильный ответ был предоставлен вчера Rosco на ServerFault.

  1. Да, но вы должны добавить четкое описание того, как мы можем запустить ваш скрипт вручную, чтобы мы могли быть уверены, что скрипт вернется нормально. В случае VirtualBox в CentOS они добавляют скрипт в /etc/init.d под названием vboxdrv:

    /etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}

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

  2. Систематический сбой процесса компиляции и отсутствие доступного модуля. Это настолько трагично? Я так не думаю. Пока ваш скрипт не вешает машину и вы даете полный лог сбоя компиляции в /var/log/mymodule, вы не можете сделать лучше этого.

  3. См. 1. - на CentOS/RHEL/Fedora) vboxdrv запускается из /etc/init.d/vboxdrv и проверяет имя дистрибутива, а затем соответственно получает некоторые скрипты. /etc/init.d - это первое место, куда я проверяю, когда мне нужна дополнительная информация о демоне. Меня это устраивает.

Связанный контент