Собственно, проблема в том, что пакет 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 это вспомогательный пакет под общие файлы для всех модулей ядра под разные типы ядер. Если модули будут тянуть юзерспейсный софт, то мы получим кучу нежелательных сайд-эффектов.

Их нужно разбирать детальнее, чтобы сказать, что сейчас это нас может устроить. Какие другие приложения вытягиваются у нас через модули ядра?