В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено, что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если использовать simpledrm вместо simplefb. Т.е.: CONFIG_FB_SIMPLE=n CONFIG_DRM=y CONFIG_DRM_SIMPLEDRM=y И видимо ещё CONFIG_DRM_KMS_HELPER=y Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами, но только для x86_64.
> неработающий framebuffer чинится для virtualbox в EFI с vmsvga А для EFI с vboxsvga не сломается при этом? Неплохо бы проверить при починке.
@ldv кто будет делать ?
(In reply to Anton Farygin from comment #2) > @ldv кто будет делать ? Меня интересует для начала, кто будет думать, как всем угодить и ничего не сломать. Мне вот DRM=y не нужно вообще нигде, ни на серверах, ни на ноутах.
Разные ядра для разных целей - единственный нормальный путь. Но важно что бы количество таких ядер не захлестнуло.
(In reply to Антон Мидюков from comment #0) > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено, > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если > использовать simpledrm вместо simplefb. Т.е.: > CONFIG_FB_SIMPLE=n > CONFIG_DRM=y > CONFIG_DRM_SIMPLEDRM=y > > И видимо ещё > CONFIG_DRM_KMS_HELPER=y > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами, > но только для x86_64. А почему только для x86_64? Можно и для aarch64.
(Ответ для Alexey Sheplyakov на комментарий #5) > (In reply to Антон Мидюков from comment #0) > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено, > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если > > использовать simpledrm вместо simplefb. Т.е.: > > CONFIG_FB_SIMPLE=n > > CONFIG_DRM=y > > CONFIG_DRM_SIMPLEDRM=y > > > > И видимо ещё > > CONFIG_DRM_KMS_HELPER=y > > > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами, > > но только для x86_64. > > А почему только для x86_64? Можно и для aarch64. Я проверял для aarch64. 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить не может. Впрочем, эта проблема обязательно вылезет вновь в одном из следующих релизов ядра и так. 2. simpledrm работает только с EFI. При загрузке с u-boot через extlinux.conf framebuffer'а нет. На Allwinner H5 (Orange Pi Prime) так. А каковы резоны для включения на aarch64?
(In reply to Dmitry V. Levin from comment #3) > (In reply to Anton Farygin from comment #2) > > @ldv кто будет делать ? > > Меня интересует для начала, кто будет думать, как всем угодить Всем угодить невозможно... > Мне вот DRM=y не нужно вообще нигде, ни на серверах, ни на ноутах. ... особенно если вместо технических критериев пользоваться субъективными предпочтениями. > и ничего не сломать. Тут волшебных рецептов нет, только тестировать. P.S. Если у Вас графическая подсистема Linux вызывает такое отторжение, то самое время придумать другую, более правильную. Затем адаптировать Mesa, Xorg (а также Qt, gtk, и далее со всеми остановками). Точнее говоря, делать это надо было лет 8 назад (а то и раньше), когда окончательно стало ясно, что fbdev мёртв, а Xorg вскоре за ним последует.
(In reply to Alexey Sheplyakov from comment #7) > Если у Вас графическая подсистема Linux вызывает такое отторжение, Вопрос не в отношении, графическая система нужна не для всех классов систем. Например, на серверах нужна не графическая система, а serial console.
Дима, всё верно, но ядро un-def обычно никто на серверах не использует.
> Например, на серверах нужна не графическая система, а serial console. Вообще, да. При разделении хотя бы на сервер и десктоп будет проще не мешать всё в кучу. P.S. Правда, судя по тому, что в BIOS уже настоящий графический интерфейс с мышью пихают, спрос есть.
(In reply to Anton Farygin from comment #9) > Дима, всё верно, но ядро un-def обычно никто на серверах не использует. Не-не. Это "предварительное" ядро. Лучше пусть таким и останется. Сейчас получается удобно, что можно p10-un-def == sisyphus-std-def. По мне бы лучше std-srv, std-wks, un-srv и un-wks.
(In reply to Антон Мидюков from comment #6) > (Ответ для Alexey Sheplyakov на комментарий #5) > > (In reply to Антон Мидюков from comment #0) > > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено, > > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если > > > использовать simpledrm вместо simplefb. Т.е.: > > > CONFIG_FB_SIMPLE=n > > > CONFIG_DRM=y > > > CONFIG_DRM_SIMPLEDRM=y > > > > > > И видимо ещё > > > CONFIG_DRM_KMS_HELPER=y > > > > > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами, > > > но только для x86_64. > > > > А почему только для x86_64? Можно и для aarch64. > > Я проверял для aarch64. > 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить > не может. 1. Зачем нужен u-boot на rasberry pi? Встроенный загрузчик прекрасно умеет запускать ядра Linux в разных видах (EFI stub, zImage, и т.п.). Есть UEFI (https://github.com/pftf/RPi4) - это если кому-то хочется стандартизации (я в их числе, если что). 2. Насколько я знаю, и u-boot, и встроенный загрузчик, и UEFI (EDK2) умеют загружать не только EFI stub, но и Image.gz Впрочем, эта проблема обязательно вылезет вновь в одном из > следующих релизов ядра и так. > 2. simpledrm работает только с EFI. rock pi 4c (arm-tf + u-boot) - UEFI нет, а framebuffer есть. И неудивительно. simpedrmfb (как и fb_simple) работает с тем, что настроил и *о чём рассказал* загрузчик/прошивка (рассказал через uefi таблицы, или в device tree). И не важно, какой именно загрузчик - u-boot, UEFI, arm-tf. > При загрузке с u-boot через extlinux.conf framebuffer'а нет. Возможно Вы не умеете его готовить (я тоже не умею, я пользуюсь тем, что добрые люди из armbian готовят) > А каковы резоны для включения на aarch64? 1. Не хочется на создавать дополнительную разницу между разными архитектурами. 2. fbdev по сути давно заброшен, его уже неоднократно собирались выпилить, и лучше заранее к этому подготовиться.
(In reply to Sergey V Turchin from comment #11) > (In reply to Anton Farygin from comment #9) > > Дима, всё верно, но ядро un-def обычно никто на серверах не использует. > Не-не. Это "предварительное" ядро. Лучше пусть таким и останется. > Сейчас получается удобно, что можно p10-un-def == sisyphus-std-def. > > По мне бы лучше std-srv, std-wks, un-srv и un-wks. А кто тестировать-то всё это будет?
(Ответ для Alexey Sheplyakov на комментарий #12) > (In reply to Антон Мидюков from comment #6) > > (Ответ для Alexey Sheplyakov на комментарий #5) > > > (In reply to Антон Мидюков from comment #0) > > > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено, > > > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если > > > > использовать simpledrm вместо simplefb. Т.е.: > > > > CONFIG_FB_SIMPLE=n > > > > CONFIG_DRM=y > > > > CONFIG_DRM_SIMPLEDRM=y > > > > > > > > И видимо ещё > > > > CONFIG_DRM_KMS_HELPER=y > > > > > > > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами, > > > > но только для x86_64. > > > > > > А почему только для x86_64? Можно и для aarch64. > > > > Я проверял для aarch64. > > 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить > > не может. > > > 1. Зачем нужен u-boot на rasberry pi? Для унификации. Грузить ядро с FAT раздела то ещё счастье. Вот не грузится с новым ядром и что делать? С предыдущим то не загрузишься. > Встроенный загрузчик прекрасно умеет > запускать ядра Linux в разных видах (EFI stub, zImage, и т.п.). Есть UEFI > (https://github.com/pftf/RPi4) - это если кому-то хочется стандартизации (я > в их числе, если что). Я знаю об этом проекте. Даже собирал edk2-rpi в Сизиф и p9 одно время. Я думаю, что в перспективе можно перейти на него попробовать. > > 2. Насколько я знаю, и u-boot, и встроенный загрузчик, и UEFI (EDK2) умеют > загружать не только EFI stub, но и Image.gz > Да, u-boot умеет грузиться в режиме EFI. Но и в режиме EFI получившееся ядро не смогло загрузиться. Начало грузиться и не смогло. > Впрочем, эта проблема обязательно вылезет вновь в одном из > > следующих релизов ядра и так. > > > 2. simpledrm работает только с EFI. > > rock pi 4c (arm-tf + u-boot) - UEFI нет, а framebuffer есть. И неудивительно. Там работает не simpedrmfb, а свой framebuffer. Я пробовал на Nano PC T4 (rk3399). В начале загрузки ядра монитор тухнет, и, пока свой framebuffer не загрузится, изображения нет. Идея вкомпиливания состоит ещё и в том, чтобы framebuffer был доступен с первых секунд загрузки ядра, чтобы на нём можно было видеть сообщения ядра. На Rockchip одинаково бесполезны simpedrmfb и fb_simple. > simpedrmfb (как и fb_simple) работает с тем, что настроил и *о чём > рассказал* загрузчик/прошивка (рассказал через uefi таблицы, или в device > tree). И не важно, какой именно загрузчик - u-boot, UEFI, arm-tf. > Верно. На Orange Pi Prime сообщения нормально выводятся на экран с fb_simple, как при загрузке через extlinux.conf, так и режим EFI. А с simpedrmfb только в режиме EFI. > > > При загрузке с u-boot через extlinux.conf framebuffer'а нет. > > Возможно Вы не умеете его готовить (я тоже не умею, я пользуюсь тем, что > добрые люди из armbian готовят) > > > > А каковы резоны для включения на aarch64? > > 1. Не хочется на создавать дополнительную разницу между разными > архитектурами. > 2. fbdev по сути давно заброшен, его уже неоднократно собирались выпилить, и > лучше заранее к этому подготовиться. Польза от fb_simple только в том, чтобы выводить сообщения на экран, пока не загрузится нормальный drm-модуль. Польза от вкомпиливания simpedrmfb видится ещё и в том, что plymouth будет запускаться сразу, а в initrd не будет необходимости класть другие drm-модули. Но это гипотеза, которую нужно будет проверить. На aarch64 plymouth мы не используем (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.
> > По мне бы лучше std-srv, std-wks, un-srv и un-wks. > А кто тестировать-то всё это будет? Да все те же, кто раньше. Некоторые сразу оба вида будут использовать, только на разных системах.
С тестированием, как раз, будет проще.
(In reply to Dmitry V. Levin from comment #8) > (In reply to Alexey Sheplyakov from comment #7) > > Если у Вас графическая подсистема Linux вызывает такое отторжение, > > Вопрос не в отношении, графическая система нужна не для всех классов систем. > Например, на серверах нужна не графическая система, а serial console. 1. Графическая система всё равно есть (CONFIG_FB_SIMPLE=Y), только ущербная, никем не поддерживаемая. 2. uart/rs232 консоль далеко не у всякого сервера есть. 3. И самое главное: "на серверах не нужна графическая подсистема" - это Ваши личные предпочтения, ничем технически не обоснованные. А принятые на основе этого предпочтения решения (сборка drm модулем + упаковка в отдельный пакет drm драйверов) создают объективные проблемы. Например, обсуждаемый баг. А ещё невозможность автоматической установки обновлений ядра.
(In reply to Антон Мидюков from comment #14) > На aarch64 plymouth мы не используем А зря. Очень хотелось бы, чтобы и на aarch64 при загрузке отображалось что-то более человеческое, чем чёрный экран. > (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу. Я рассматриваю aarch64 как "обычный компьютер для обычного пользователя", а не как хакерскую игрушку. А соответственно serial console а) нужна < 1% пользователей, б) не всегда (легко) доступна
(Ответ для Alexey Sheplyakov на комментарий #18) > (In reply to Антон Мидюков from comment #14) > > > На aarch64 plymouth мы не используем > > А зря. Очень хотелось бы, чтобы и на aarch64 при загрузке отображалось > что-то более человеческое, чем чёрный экран. И мне хочется, чтобы plymouth выводился исключительно на экран, не мешая serial console: https://bugzilla.altlinux.org/39326 > > > (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу. > > Я рассматриваю aarch64 как "обычный компьютер для обычного пользователя", а > не как хакерскую игрушку. А соответственно serial console а) нужна < 1% > пользователей, б) не всегда (легко) доступна И тем не менее, на одноплатниках обычно врубается она, если не указать console=tty1.
Проблемы больше нет, как в новых, так и в старых образах. Видимо, помогло последнее обновление virtualbox до 6.1.34
