kernel-modules-virtualbox зависит от virtualbox-common зачем-то. Из-за этого имеем недоумение пользователей сервера, которые установили минимальную его конфигурацию. В Альт сервер сознательно устанавливается kernel-modules-virtualbox-<flavour> в минимальную конфигурацию, чтобы избежать проблем с последующей установкой virtualbox. Так что хотелось бы узнать: зачем?
Собственно, проблема в том, что пакет virtualbox-common включает в себя /etc/modules-load.d/virtulalbox.conf: vboxdrv vboxnetflt vboxnetadp Загрузка этих модулей ядра в сервере с минимальной конфигурацией при старте, мягко говоря, неправильно.
Может и kernel-modules-virtualbox из минимальной убрать?
(Ответ для Sergey V Turchin на комментарий #2) > Может и kernel-modules-virtualbox из минимальной убрать? Сами эти три модуля занимают менее 900 кБ. Если их не подгружать, то они не подгрузятся. Наличие модуля в минимальной системе решает проблему установки virtualbox на неё. Самое интересное, что модуль kernel-modules-virtualbox в минимальной установке уже давно. В mkimage-profiles (релиз сервера на p9) пришло уже в таком виде. Т.е. не позднее, чем с p8 так повелось, а может и раньше: https://git.altlinux.org/gears/m/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=46bc1f68c7217e7d11c8c53bbc83ae09cd91e94b;hp=3d983cf2ecde7a01d9fbf737337c257f2e03e72d строчка: @$(call add,BASE_KMODULES,kvm virtualbox)
наличие virtualbox в серверном дистрибутиве, на самом деле, не очень оправданно. там скорее нужен qemu-kvm
Очень странное решение у нас с драйверами на сервере. Модули drm насильно отпилены в отдельные подпакеты, что весьма спорно с архитектурной точки зрения. Ведь никто не гарантирует целостность такого отпиливания на уровне зависимостей между модулями ядра. И все это только для того, чтобы иметь возможность не ставить drm-модули ядра на сервер. А тут сторонние драйвера и все наоборот - "а давайте их впилим на сервер", поскольку это обеспечивает мнимое удобство. Предлагаю посмотреть на проблему более целостно, с точки зрения всего комплекса требований к серверу. Кстати, для virtualbox нужно завершить доработку обеспечивающую установку драйверов из gui. Это решило бы данную предполагаемую проблему полноценной установки virtualbox на сервере с графикой. Сейчас пока можно поправить вывод ошибки при отсутствии хостовых драйверов с предложением запустить правильный скрипт в консоли. Этот скрипт нужно указать свой, который сможет доустановить драйвера. _____ Другой момент состоит в том, что было бы неплохо, при установке любого дистрибутива, сохранять кеш пакетов с драйверами для текущего ядра, поскольку необходимость их доустановки в дальнейшем может потребовать обязательного обновления ядра, что не всегда желательно и возможно.
(Ответ для Evgeny Sinelnikov на комментарий #5) > Очень странное решение у нас с драйверами на сервере. Модули drm насильно > отпилены в отдельные подпакеты, что весьма спорно с архитектурной точки > зрения. Ведь никто не гарантирует целостность такого отпиливания на уровне > зависимостей между модулями ядра. > > И все это только для того, чтобы иметь возможность не ставить drm-модули > ядра на сервер. Это уже исправили же. > > А тут сторонние драйвера и все наоборот - "а давайте их впилим на сервер", > поскольку это обеспечивает мнимое удобство. Тяжёлое наследство. Надо в mkimage-profiles-desktop искать коммит с этим впиливанием. Но и так понятно, почему это было сделано. Возможно, не стоит virtualbox на сервер вообще тащить, как выше написал rider@ Но всё же я хотел бы услышать ответ, зачем у kernel-modules-virtualbox-<flavour> зависимость на virtualbox-common? Или даже не так. Зачем столько всего в пакете virtualbox-common? Почему это всё находится не в пакете virtualbox? Какой смысл грузить модули ядра, если самого virtualbox нет?
Установка и удаление модулей ядра у нас штука не воспроизводимая, поскольку ядра в системе могут отставать от ядер в репах. В результате, удаление модулей ядра может приводить к необходимости обновления ядра, если модули требуется снова установить. virtualbox-common это вспомогательный пакет под общие файлы для всех модулей ядра под разные типы ядер. Если модули будут тянуть юзерспейсный софт, то мы получим кучу нежелательных сайд-эффектов. Их нужно разбирать детальнее, чтобы сказать, что сейчас это нас может устроить. Какие другие приложения вытягиваются у нас через модули ядра?
Компонент kernel-modules-virtualbox-std-def упразднён (std-def удалён заданием 360930). В kernel-modules-virtualbox-6.12 7.2.16 по-прежнему Requires: virtualbox-common — перевешиваю на актуальный компонент.
(Ответ для Evgeny Sinelnikov на комментарий #7) > Установка и удаление модулей ядра у нас штука не воспроизводимая, поскольку > ядра в системе могут отставать от ядер в репах. В результате, удаление > модулей ядра может приводить к необходимости обновления ядра, если модули > требуется снова установить. > > virtualbox-common это вспомогательный пакет под общие файлы для всех модулей > ядра под разные типы ядер. Если модули будут тянуть юзерспейсный софт, то мы > получим кучу нежелательных сайд-эффектов. > > Их нужно разбирать детальнее, чтобы сказать, что сейчас это нас может > устроить. Какие другие приложения вытягиваются у нас через модули ядра? Я тебе про одно, а ты мне опять про другое :) Вопрос был конкретный: Какой смысл грузить модули ядра, если самого virtualbox нет? Предлагаю перенести конфиги загрузки модулей ядра из virtualbox-common в пакет virtualbox, а зависимость у kernel-modules-virtualbox на virtualbox-common оставить.
virtualbox-7.2.16-alt2 -> sisyphus: Mon Sep 07 2026 Valery Sinelnikov <greh@altlinux> 7.2.16-alt2 - Moved control facility from virtualbox-common to the main package (closes: 48283) - Load kernel modules only when virtualbox is installed: moved modules-load config, init script and systemd unit to the main package (closes: 42872) - Error dialogs for missing or mismatched kernel driver now suggest installing kernel-modules-virtualbox or running update-kernel instead of non-existent /sbin/vboxconfig (closes: 29112, closes: 33825) - Fixed regression: VBoxClient showed notify-send notification on every session login on non-VM machines (closes: 60287) - Main package now requires virtualbox-doc so the in-app help (UserManual qhelp) is always available