fb conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver.

проблема не в этом, у меня тоже так пишет:

dmesg | grep fb
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.175670] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.175672] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
[    0.220339] pnp 00:0d: [mem 0xf8000000-0xfbffffff]
[    0.220374] system 00:0d: [mem 0xf8000000-0xfbffffff] has been reserved
[    0.545413] vesafb: mode is 1680x1050x32, linelength=6720, pages=0
[    0.545414] vesafb: scrolling: redraw
[    0.545416] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.546046] vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90005600000, using 6912k, total 6912k
[    0.738996] fb0: VESA VGA frame buffer device
[    0.757569] ahci 0000:03:00.0: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs 
[    1.289694] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[    1.425326] fbcon: inteldrmfb (fb0) is primary device
[    1.642561] fb0: inteldrmfb frame buffer device
[    1.719994] usb 3-2: New USB device found, idVendor=09fb, idProduct=6001

давай debug initcall_debug в параметры ядра и выкладывай логи

А вы initramfs пересобирали ?

Я не знаю какая система инициализации была на вашем дистрибутиве до этого, но если не systemd, то нужно пересобирать initramfs или хотя бы добавить к опциям ядра 'init=/sbin/systemd' или 'init=/bin/systemd' или возможно по аналогии, /usr/bin/systemd || /usr/sbin/systemd .

Это гогно как положено не обновляется, быстрее накатить заново.

Тоже самое. Загрузка прекращается после строки fb conflicting fb...
Лично у меня по этому поводу пока никаких идей.

Думаю initramfs тут не причем, хотя я его, для эксперимента, пересобирал. Он затыкается на инициализации устройств udev'ом. По дефолту используется systemd. Я просто не могу определить в чем конкретно ошибка, так как система виснет после выше описанной строки и больше ничего не выдает. Может он затыкается в другом месте, а мне об этом не сообщает.

Я скорее жду совета от человека знающего проблему, чем желаю обсуждать что «гагно» а что нет. Если под «накатить» подразумевается переустановка - то нет, не вариант.

нужны логи, без них ловить нечего. если есть еще компы, сделай выхлоп через netconsole (ядро грузить с «debug initcall_debug»). попробуй также, воспроизводится ли на других ядрах (в репах есть default, desktop, vanilla). также попробуй заблеклистить i915, это отключит его на этапе загрузки (останешься без сплеша, но потом иксы его подтянут). и да, не спеши стреляться или ставить венду - похоже ты поймал редкий баг, ему место в багзилле.

Вдогонку: если считаешь, что проблема связана с KMS, то его можно отключить на этапе загрузки. За это отвечает ключ NO_KMS_IN_INITRD в /etc/sysconfig/kernel. Не забудь после изменений сделать mkinitrd.

Правда, самому очень интересно, чем закончится драма. Столкнулся с такой же проблемой, только у меня посыпался kms и комп остался без иксов. Даже тему не стал создавать.

Давно хотел попробовать смену ядра. И блин, помогло. Так что проблему можно считать решенной, хоть и через одно место. Спасибо, тебе, добрый человек, за совет. А desktop ядро убил в конец экспериментами, даже fallback режим перестал грузиться. debug initcall_debug уже пробовал, затыкается на том же месте. Похоже действительно баг в видео драйвере, просто удивительно, что система рушится банальным обновлением systemd и udev. udev же вроде при обновлении initrd не пересобирает и ядро не трогает, или я не прав?
P.S. А я думал для отключения KMS достаточно скормить параметр nomodeset.

udev же вроде при обновлении initrd не пересобирает и ядро не трогает, или я не прав?

mkinitrd точно вызывается инсталляционным скриптом

А я думал для отключения KMS достаточно скормить параметр nomodeset.

так и есть. способ, что я выше приводил, позволяет отключить KMS на раннем этапе загрузки, позже он может быть включен (если nomodeset не выставлен).

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

есть еще вариант, что выхлоп есть, но journald или как там его не показывает в консоли, а прячет в какой-нибудь файл.

Проблема решена

Оказалось довольно таки банально. Я собирал драйвера для сетевой из сборника compat-drivers-2013-02-20-u, т.к. к сожалению, на мою сетевуху в стандартной поставке ядра дров не оказалось. Под шумок из этого сборника собирались дрова на интеловскую видюху (видимо бета), и удачно инсталлировались в систему вместе со всей прочей требухой из этого сборника. Поковырявшись, я понял, что можно изменить make файл, чтобы собирались и инсталлировались только драйвера на сетевуху. Собственно так и решился мой недуг.