uvesafb: mode switch failed

Тут хз, а проприетарный нвидиевский драйвер прямо в dmesg предупреждает, что может глючить с vesa. Хочет vga.

А чего не свободный драйвер? Там же вроде только производительность 3D осталась из минусов.

Насчет v86d — дык а проверить? Можно втупую, типа «ps -e | grep v86d > /tmp/test.txt» перед «modprobe uvesafb», можно еще зависимости инициализации проверить. Куда был modprobe добавлен и откуда v86d стартует.

Ну вот плавность важна...и еще в minecraft иногда играю... А v86d...нужно проверить. Ну пока мне хватает спящего режима, завтра скорее всего отпишусь.

Ну вот плавность важна...и еще в minecraft иногда играю...

И на свободном с этим явно хуже? Требования у майнкрафта вроде вполне демократичные. Если не вестись на авторитетные мнения типа «свободный драйвер == нет 3D».

Еще, тут про initramfs можно вспомнить, если вдруг модуль ядра стартует оттуда, а v86d уже после переключения на нормальный рут. Но это вряд ли..

После установки v86d всегда автоматический update-initramfs.

Ну и после удаления тоже.

Ок, но все равно момент, который тоже можно проверить потом.

Короче я сделал modprobe -r uvesafb (а вдруг поможет?), после чего update-initramfs -u -v. Увидел, что uvesafb все равно пытается загрузиться. Удалил файл модуля...ни разу не имел дело с этими модулями, но полез. Удалил v86d опять с помощью purge. update-initramfs несмотря ни на modprobe -r, ни на apt-get purge v86d продолжает искать uvesafb. А говорят, что он вообще не нужен если есть fglrx.

В прошлый раз при установке fglrx удаление файла модуля помогло убрать сообщение о том, что fglrx уже установлен.

Короче я сделал modprobe -r uvesafb (а вдруг поможет?), после чего update-initramfs -u -v. Увидел, что uvesafb все равно пытается загрузиться.

«modprobe -r» это всего лишь «выгрузить модуль». На диске при этом ничего не изменяется.

Удалил файл модуля...ни разу не имел дело с этими модулями, но полез.

В общем случае так делать не надо (редактировать в пакетном дистрибутиве файлы, которые не есть конфигурационными). 99% что есть более прямой способ.

update-initramfs несмотря ни на modprobe -r, ни на apt-get purge v86d продолжает искать uvesafb.

Имхо неудивительно. А в чем вообще проблема, кроме сообщения «failed»?

Судя по man initramfs.conf, по дефолту туда похоже просто добавляются все наличные драйвера для фреймбуфера. То есть это нормально. Можно еще -c вместо -u для update-initramfs на всякий случай попробовать, но это вряд ли.

Если таки мешает, вот это должно помочь:

https://wiki.debian.org/KernelModuleBlacklisting

Вначала можно убедиться, что нигде больше не задано кастомных правил для конкретного модуля: «grep -rI uvesafb /etc». Еще в /usr/lib/modprobe.d/ может что-то быть.

Удалять?

Стоит попробовать. Но не факт что это поможет, с учетом вышесказанного.

А в папке modprobe.d ничего нет.

Ок, это было на всякий случай. В /etc/modprobe.d пойдет блеклист, если делать как по ссылке. Но в чем основная проблема таки не понял.

И еще: теперь без ошибок выкидывает в консоль. Может, стоит в автозагрузку записать service kdm restart, чтобы не мучиться?

Вот, я нашел, почему этот модуль ищет:

cat /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
fbcon
vesafb
uvesafb mode_option=1366x768-32 mtrr=3 scroll=ywrap
uvesafb mode_option=1366x768-32 mtrr=3 scroll=ywrap

Теперь при update-initramfs нет упоминания о uvesafb, тем не менее все равно выбрасывает в консоль. Значит, тут дело не в uvesafb.

Пардон, но без подробностей по первой (ошибка uvesafb) и второй («выкидывает в консоль») проблеме что-то сказать сложно.