Система намертво виснет при инициализации графики. Вероятно виноват udev.
Собрался с духом наконец написать историю.
Имеется домашний сервер для инета и другого на базе атома второго поколения.
Работал он себе месяцами без ребута. Периодически обновлялся софт. Уезжал на пару дней и решил вырубить сервер. После возвращения он соответственно не загрузился. Виснет, на клаву не реагирует, не пингуется. То есть он загружается в графическом режиме, до запуска udev и потом виснет. Крутил так и эдак, ядро обновил до 4.4.6. Опции фрэйм буфера включал-отключал, весу ставил, интел. Ничего не помогало. В итоге отключил графику полностью. Теперь грузится в текстовом режиме. udev установлен со стандартным конфигом, менял на eudev, но без толку. openrc стоит, но это без разницы кажется. Эти проблемы с графикой у меня начались с 4-го ядра, какое-то оно кривоватое. Думаю всё-таки это новый udev виноват частично.
- Для комментирования войдите или зарегистрируйтесь
Ядро обновлял? Или не знаешь?
Ядро обновлял? Или не знаешь?
мне не нужна подпись, и так всё ясно
Четыре версии ядра проверял.
Четыре версии ядра проверял.
И где конфиги/логи?
И где конфиги/логи?
Какие логи нужны? Я в логах
Какие логи нужны? Я в логах ничего характерного не нашёл. Перекомпилирую ядро со старой конфигурацией, тогда логи будут.
Oчевидно же - прежде всего
Oчевидно же - прежде всего
kern.log/dmesg.Если у тебя
systemd, то там по-более есть возможностей логов старта/загрузки...Т.е. нужно все до момента зависания.
Dmesg вроде дает только лог
Dmesg вроде дает только лог текущей загрузки, после перезагрузки затирается? Собственно в этом проблема, не могу увидеть точно - что вешает.
Кстати dmesg какой-то короткий, пишет не с начала.
[ 7.754367] udevd[1983]: maximum number (16) of children reached Можно ли это поправить?Так и есть
Так и есть, но потому я и упоминал
kern.log- туда пишется то же, что и вdmesg, но с нормальным временем.A в
systemdеще можно увидеть лог самой загрузки.Можно настроить выдачу логов параллельно на другую машину через порт или по сети.
Я настроил kern.log, но в
Я настроил kern.log, но в него попадают данные только при удачной загрузке, так как до загрузки syslog дело не доходит.
Я могу ещё попробовать simple framebuffer, но хотелось бы разобраться.
Ещё попробую скомпилировать модуль не в ядре и запускать его руками. Тогда хотя бы логи будут.
а не может ли...
а не может ли быть проблема в необходимости пересборки графического драйвера после компиляции ядра? (при использовании проприетарных драйверов)
немного смущает вот это:
и тут же следующим сообщением
Проверял три релиза 4го
Проверял три релиза 4го ядра.
Третье ядро грузится.
Выяснилось, что система зависает при включенной опции в ядре:
Framebuffer Console support.
Без этой опции получаю черный экран, но система не виснет.
Может не нужно Сonsole support?
Кроме Vesa других драйверов нет?.
Видеокарта, повторюсь, встроенный интел.
Конфиг lilo.conf
image=/boot/vmlinuz-4.4.6-gentoo-test
initrd = /boot/initramfs.img
root=/dev/sda1
append="rootfstype=ext4 loglevel=7 acpi_enforce_resources=lax root=UUID=c672d353-74e0-4ec5-8047-02d3446f4ad3"
label=gentoo-test
vga=0x317
Раньше система зависала на этапе запуска udev. То есть можно было загрузится без udev. Потом /etc/init.d/udev start - вешало систему, конкретнее гас экран и все переставало работать. Подсветка экрана остается включенной.
Сейчас я пока не могу это воспроизвести.