Собственно, проблема в том, что пакет 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