Как оказалось проблема с отсутствующим framebuffer у virtualbox (bug 40232) - это вершина айсберга. У ядра un-def при загрузке в UEFI теперь нет вывода графики, пока drm модуль не загрузится. Так что без установленного пакета kernel-image-drm-un-def графики теперь вовсе нет. А в virtualbox drm модуль, видимо, не предоставляет framebuffer. Проблему можно воспроизвести в qemu, virtualbox, на любом железе с UEFI.
У ядра std-def CONFIG_FB_SIMPLE=y, а у un-def CONFIG_FB_SIMPLE=m. Добавление в /etc/initrd.mk: MODULES_PRELOAD = simplefb и перегенерация initrd проблему решает.
(Ответ для Антон Мидюков на комментарий #1) > У ядра std-def CONFIG_FB_SIMPLE=y, а у un-def CONFIG_FB_SIMPLE=m. Это изменение произошло в 5.14.13-alt1. В архивном ядре 5.14.11-alt1 ещё y, а в 5.14.13-alt1 уже m. Похоже, причина в коммите: http://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un-def.git;a=commit;h=b0ee6190e85604cfa7848f002b300c95628f1ee4 CONFIG_DRM_SIMPLEDRM=m не позволяет CONFIG_FB_SIMPLE=y. Т.е. для встраивания одного из них в ядро нужно отключать сборку другого. Вопрос только в том, оставить ли CONFIG_FB_SIMPLE или же попробовать перейти на новый CONFIG_DRM_SIMPLEDRM.
(Ответ для Антон Мидюков на комментарий #2) > (Ответ для Антон Мидюков на комментарий #1) > > У ядра std-def CONFIG_FB_SIMPLE=y, а у un-def CONFIG_FB_SIMPLE=m. > > Это изменение произошло в 5.14.13-alt1. В архивном ядре 5.14.11-alt1 ещё y, > а в 5.14.13-alt1 уже m. Похоже, причина в коммите: > http://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un- > def.git;a=commit;h=b0ee6190e85604cfa7848f002b300c95628f1ee4 > > CONFIG_DRM_SIMPLEDRM=m не позволяет CONFIG_FB_SIMPLE=y. Т.е. для встраивания > одного из них в ядро нужно отключать сборку другого. Вопрос только в том, > оставить ли CONFIG_FB_SIMPLE или же попробовать перейти на новый > CONFIG_DRM_SIMPLEDRM. Делать CONFIG_DRM_SIMPLEDRM=y нельзя, так как он за собой тянет drm.ko, drm_helper.ko, cec.ko из пакета kernel-modules-drm-un-def. Да и сам он оттуда. Вообще проблема сборки в виде модуля для обоих конфигов видится в том, что ни один, ни другой правилами udev в качестве некоего fallback не загружается. Также выяснил, что проблему с framebuffer в virtualbox решает загрузка модуля simpledrm.ko. Так что, возможно, стоит грузить модуль simpledrm.ko в initrd.
> Вообще проблема сборки в виде модуля для обоих конфигов видится в том, что > ни один, ни другой правилами udev в качестве некоего fallback не загружается. Согласен. Из этого следует вопрос -- возможно ли и нужно ли такое правило udev написать?
(Ответ для Anton V. Boyarshinov на комментарий #4) > > Вообще проблема сборки в виде модуля для обоих конфигов видится в том, что > > ни один, ни другой правилами udev в качестве некоего fallback не загружается. > > Согласен. Из этого следует вопрос -- возможно ли и нужно ли такое правило > udev написать? На данный момент выяснил, что simpledrm работает нормально не везде. И действительно полезен только в virtualbox с VMware SVGA II Adapter в режиме UEFI. Загрузку simpledrm.ko, видимо, можно загружать при появлении этого видеоадаптера. А вот simplefb нужно загружать во всех остальных случаях. Но проблема в том, что simplefb можно загрузить, а выгрузить не получится. Кажется сомнительным, что условие "если есть VMware SVGA II Adapter, то грузим simpledrm, а если нет, то грузим simplefb" будет работать, как надо. Может же быть, что на момент запуска udev VMware SVGA II Adapter не доступен. А после загрузки simplefb уже будет поздно это проверять.
Я не вижу хорошего решения, как грузить модуль simplefb.ko Учитывая, что модуль невыгружаемый, то делать его модулем смысла особо нет. Единственный случай, когда помогает загрузка simpledrm.ko вместо simplefb.ko, это virtualbox в режиме EFI с графикой vmsvga. По-моему, этим вполне можно пожертвовать. Пользователи элементарно могут подумать, что система не грузится, хотя дело не дошло ещё и до initrd. А если kernel panic, то и вовсе увидишь лишь перезагрузку. Предлагаю отключить CONFIG_DRM_SIMPLEDRM, чтобы simplefb был в ядре, как раньше. Напомню, что сейчас CONFIG_FB_SIMPLE=y, но так как CONFIG_DRM_SIMPLEDRM=m, то происходит замена на CONFIG_FB_SIMPLE=m. Т.е. приведём в соответствие исходный и итоговый конфиги ядра.
Подтверждаю для беты K. После установки пришлось переключиться на VBoxSVGA, тогда загрузка пошла.
А может посмотреть, как у соседей с этими модулями?
(Ответ для Антон Мидюков на комментарий #6) > Я не вижу хорошего решения, как грузить модуль simplefb.ko > Учитывая, что модуль невыгружаемый, то делать его модулем смысла особо нет. > Единственный случай, когда помогает загрузка simpledrm.ko вместо > simplefb.ko, это virtualbox в режиме EFI с графикой vmsvga. По-моему, этим > вполне можно пожертвовать. Пользователи элементарно могут подумать, что > система не грузится, хотя дело не дошло ещё и до initrd. А если kernel > panic, то и вовсе увидишь лишь перезагрузку. > > Предлагаю отключить CONFIG_DRM_SIMPLEDRM, чтобы simplefb был в ядре, как > раньше. Напомню, что сейчас CONFIG_FB_SIMPLE=y, но так как > CONFIG_DRM_SIMPLEDRM=m, то происходит замена на CONFIG_FB_SIMPLE=m. Т.е. > приведём в соответствие исходный и итоговый конфиги ядра. Я сделал соответствующие изменения, будет в следующей сборке.
(In reply to Антон Мидюков from comment #3) > (Ответ для Антон Мидюков на комментарий #2) > > (Ответ для Антон Мидюков на комментарий #1) > > > У ядра std-def CONFIG_FB_SIMPLE=y, а у un-def CONFIG_FB_SIMPLE=m. > > > > Это изменение произошло в 5.14.13-alt1. В архивном ядре 5.14.11-alt1 ещё y, > > а в 5.14.13-alt1 уже m. Похоже, причина в коммите: > > http://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un- > > def.git;a=commit;h=b0ee6190e85604cfa7848f002b300c95628f1ee4 > > > > CONFIG_DRM_SIMPLEDRM=m не позволяет CONFIG_FB_SIMPLE=y. Т.е. для встраивания > > одного из них в ядро нужно отключать сборку другого. Вопрос только в том, > > оставить ли CONFIG_FB_SIMPLE или же попробовать перейти на новый > > CONFIG_DRM_SIMPLEDRM. > > Делать CONFIG_DRM_SIMPLEDRM=y нельзя А придётся. Дело в том, что не-DRM fbdev драйверы скоро выпилят. Так что графическая консоль до загрузки initramfs будет только при CONFIG_DRM=y CONFIG_DRM_SIMPLEDRM=y Напоминаю, что другой консоли (кроме графической) зачастую и нет. Так что в не столь отдалённой перспективе придётся либо мириться с этим багом, ... > так как он за собой тянет drm.ko, > drm_helper.ko, cec.ko из пакета kernel-modules-drm-un-def. Да и сам он > оттуда. ... либо а) таки сделать CONFIG_DRM=y, CONSIG_DRM_SIMPLEDRM=y б) упразднить пакет modules-drm, drm драйверы паковать в kernel-image в) drm-ненавистникам выдать по ведру настойки пустырника
(Ответ для Alexey Sheplyakov на комментарий #10) > (In reply to Антон Мидюков from comment #3) > > (Ответ для Антон Мидюков на комментарий #2) > > > (Ответ для Антон Мидюков на комментарий #1) > > > > У ядра std-def CONFIG_FB_SIMPLE=y, а у un-def CONFIG_FB_SIMPLE=m. > > > > > > Это изменение произошло в 5.14.13-alt1. В архивном ядре 5.14.11-alt1 ещё y, > > > а в 5.14.13-alt1 уже m. Похоже, причина в коммите: > > > http://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un- > > > def.git;a=commit;h=b0ee6190e85604cfa7848f002b300c95628f1ee4 > > > > > > CONFIG_DRM_SIMPLEDRM=m не позволяет CONFIG_FB_SIMPLE=y. Т.е. для встраивания > > > одного из них в ядро нужно отключать сборку другого. Вопрос только в том, > > > оставить ли CONFIG_FB_SIMPLE или же попробовать перейти на новый > > > CONFIG_DRM_SIMPLEDRM. > > > > Делать CONFIG_DRM_SIMPLEDRM=y нельзя > > А придётся. Дело в том, что не-DRM fbdev драйверы скоро выпилят. > Так что графическая консоль до загрузки initramfs будет только при > > > CONFIG_DRM=y > CONFIG_DRM_SIMPLEDRM=y > > Напоминаю, что другой консоли (кроме графической) зачастую и нет. > Так что в не столь отдалённой перспективе придётся либо мириться с этим > багом, ... > > > так как он за собой тянет drm.ko, > > drm_helper.ko, cec.ko из пакета kernel-modules-drm-un-def. Да и сам он > > оттуда. > > ... либо > > а) таки сделать CONFIG_DRM=y, CONSIG_DRM_SIMPLEDRM=y > б) упразднить пакет modules-drm, drm драйверы паковать в kernel-image > в) drm-ненавистникам выдать по ведру настойки пустырника Вот как выпилят, так так и сделаем. Зачем торопить события?
(In reply to Антон Мидюков from comment #5) > (Ответ для Anton V. Boyarshinov на комментарий #4) > > > Вообще проблема сборки в виде модуля для обоих конфигов видится в том, что > > > ни один, ни другой правилами udev в качестве некоего fallback не загружается. > > > > Согласен. Из этого следует вопрос -- возможно ли и нужно ли такое правило > > udev написать? > > На данный момент выяснил, что simpledrm работает нормально не везде. Где конкретно? > И действительно полезен только в virtualbox с VMware SVGA II Adapter в режиме UEFI. Утверждение не соответствует действительности. simpledrmfb полезен на любых UEFI системах (x86, arm64), arm/arm64 одноплатниках (включая raspberry pi 2/3/4).
(In reply to Антон Мидюков from comment #11) > (Ответ для Alexey Sheplyakov на комментарий #10) > > (In reply to Антон Мидюков from comment #3) > > > (Ответ для Антон Мидюков на комментарий #2) > > > > (Ответ для Антон Мидюков на комментарий #1) > > > > > У ядра std-def CONFIG_FB_SIMPLE=y, а у un-def CONFIG_FB_SIMPLE=m. > > > > > > > > Это изменение произошло в 5.14.13-alt1. В архивном ядре 5.14.11-alt1 ещё y, > > > > а в 5.14.13-alt1 уже m. Похоже, причина в коммите: > > > > http://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un- > > > > def.git;a=commit;h=b0ee6190e85604cfa7848f002b300c95628f1ee4 > > > > > > > > CONFIG_DRM_SIMPLEDRM=m не позволяет CONFIG_FB_SIMPLE=y. Т.е. для встраивания > > > > одного из них в ядро нужно отключать сборку другого. Вопрос только в том, > > > > оставить ли CONFIG_FB_SIMPLE или же попробовать перейти на новый > > > > CONFIG_DRM_SIMPLEDRM. > > > > > > Делать CONFIG_DRM_SIMPLEDRM=y нельзя > > > > А придётся. Дело в том, что не-DRM fbdev драйверы скоро выпилят. > > Так что графическая консоль до загрузки initramfs будет только при > > > > > > CONFIG_DRM=y > > CONFIG_DRM_SIMPLEDRM=y > > > > Напоминаю, что другой консоли (кроме графической) зачастую и нет. > > Так что в не столь отдалённой перспективе придётся либо мириться с этим > > багом, ... > > > > > так как он за собой тянет drm.ko, > > > drm_helper.ko, cec.ko из пакета kernel-modules-drm-un-def. Да и сам он > > > оттуда. > > > > ... либо > > > > а) таки сделать CONFIG_DRM=y, CONSIG_DRM_SIMPLEDRM=y > > б) упразднить пакет modules-drm, drm драйверы паковать в kernel-image > > в) drm-ненавистникам выдать по ведру настойки пустырника > > Вот как выпилят, так так и сделаем. Пока гром не грянет, мужик не перекрестится, ага. > Зачем торопить события? Чтобы было время спокойно выяснить, что сломалось, и столь же спокойно починить.
(In reply to Alexey Sheplyakov from comment #13) > > Вот как выпилят, так так и сделаем. > Пока гром не грянет, мужик не перекрестится, ага. А при выпиливании не может появиться ещё каких-то изменений, с этим связаных?
(Ответ для Alexey Sheplyakov на комментарий #12) > (In reply to Антон Мидюков from comment #5) > > (Ответ для Anton V. Boyarshinov на комментарий #4) > > > > Вообще проблема сборки в виде модуля для обоих конфигов видится в том, что > > > > ни один, ни другой правилами udev в качестве некоего fallback не загружается. > > > > > > Согласен. Из этого следует вопрос -- возможно ли и нужно ли такое правило > > > udev написать? > > > > На данный момент выяснил, что simpledrm работает нормально не везде. > > Где конкретно? > На RPi4 изображение отвалилось в режиме UEFI (u-boot). Вполне возможно, что ещё где-то выстрелит на кривом UEFI. > > И действительно полезен только в virtualbox с VMware SVGA II Adapter в режиме UEFI. > > Утверждение не соответствует действительности. simpledrmfb полезен на любых > UEFI > системах (x86, arm64), arm/arm64 одноплатниках (включая raspberry pi 2/3/4). simplefb где-то не работает? >Чтобы было время спокойно выяснить, что сломалось, и столь же спокойно починить. Можно с 5.16 к примеру начать. А в p10 simplefb проверенный пусть будет пока. Но это пусть решает мантейнер ядра.
Проблема была решена отключением CONFIG_DRM_SIMPLEDRM.
