Действительно ли это опасно для предоставления опции сделать и установить новое ядро Linux и драйвер на перезагрузке?
Это - обычная практика, чтобы поставить драйверы ядра Linux (объекты ядра КОС) в исходном коде, и создать и установить их на целевом компьютере. Например, драйверы дисплеев NVIDIA и гостевые дополнительные драйверы Oracle VirtualBox установлены этот путь. Также распространено получить новые версии ядра (с соответствующими заголовками) посредством системного обновления. Это требует, чтобы KO был восстановлен и переустановлен, иначе устройство прекратит работать после обновления.
В нашем сценарии запуска установки продукта мы хотим добавить шаг, чтобы сделать и установить KO на каждой начальной загрузке. Пользователь может выбрать к уклонению, и должен был бы создать и установить KO вручную. Драйвер устройства связывается с USB-устройством.
Подходящие детали:
Фактические восстанавливают, произойдет только однажды, когда новое ядро установлено, потому что составляют завещание не, пытаются восстановить файл, который уже является там и до даты.
Требуется приблизительно две секунды для восстановления драйвера и миллисекунд для пропуска сборки во время нормальной начальной загрузки (не после обновления ядра)
В маловероятном случае, что сборка перестала работать, она не должна разрушать систему или делать это нестабильным. Однако наше устройство не будет работать.
Некоторые дистрибутивы могут позволить регистрировать рычаги, делать действия с определенными событиями, как обновление ядра. Однако мы пытаемся реализовать что-то, что будет работать над большинством дистрибутивов универсальным способом. Наш установщик является script+tar или script+rpm. К сожалению для этого выпуска у нас нет пропускной способности для подготовки собственных пакетов ко всем дистрибутивам (например, Debian-стиль).
Вопросы:
Действительно ли это - приемлемое решение? В противном случае, почему?
Что потенциальные риски связаны с этим подходом?
Что корректное/предпочтительное место работать делают во время запуска? rc.local или сценарий под init.d или другим? Цель состоит в том, чтобы заставить его работать над большинством дистрибутивов с помощью того же метода (если вообще возможный).
1 ответ
Этот корректный ответ был вчера предоставлен Rosco на ServerFault.
Да, но необходимо добавить четкое практическое руководство, описывающее способ, которым мы можем запустить скрипт вручную, таким образом, мы можем удостовериться, что сценарий будет обычно возвращаться. В случае VirtualBox в CentOS они добавляют сценарий в/etc/init.d, названном vboxdrv:
/etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}Это ясно; мы можем запустить/остановить сценарий и получить его состояние, таким образом, риск получения проблем во время перезагрузки минимален, пока мы можем проверить сценарий на новом ядре прежде, чем развернуть его. Вы не можете иметь более стандартный, чем это, для меня это прекрасно.
Систематический отказ процесса компиляции и никакого доступного модуля. Это - это трагичное?Я так не думаю. Пока Ваш сценарий не подвешивает машину, и Вы даете полный журнал отказа компиляции в/var/log/mymodule, Вы не можете добиться большего успеха, чем это.
См. 1. - на CentOS/RHEL/Fedora) vboxdrv работает от/etc/init.d/vboxdrv и проверяет имя распределения, затем источник некоторые сценарии соответственно./etc/init.d является первым местом, которое я проверяю, когда я хочу больше информации о демоне. Это меня устраивает.