на экран выводит кучу матюгов и stacktrace. Что отвалилось я не успеваю прочитать. После этого загрузка системы продолжается нормально. В rc.log все «OK» и что отвалилось не видно. В системе не работает монтирование носителей и настройка NetworkManager без root (Группы и права настроены). Мне кажется это связано.
Подскажите как узнать что отваливается?
Во-первых, объясни мне, что в тегах делает openrc, когда у тебя
[ 13.932962] systemd-udevd[13073]: starting version 207
Во-вторых, твои SATA диски работают на UDMA/100 и 133, что эквивалентно скорости IDE-диска.
[ 387.430073] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 387.478405] ata1.00: configured for UDMA/133
Я не уверен, насколько это нормально, пока не увидел модели контроллера и дисков, но скорее всего где-то там есть ошибка.
Кстати, вот ошибка libata
[ 4965.525217] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
res 50/00:03:00:08:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
ata wiki подсказывает, что это 「chip<->device bus error 」.
Что касается длинного бектрейса, то он появляется в результате kernel oops на 17 секунде. В таких случаях рекомендуют обращаться к мейнтейнеру ядра и репортить баги. Однако в твоём случае в ядро натаскано сторонних патчей, поэтому тебе идти или в лес, или к post-factum, он вроде разбанился.
pf-sources ЕМНИП, специализируется на патчах для лэптопов, и, ЧСХ, сегфолт на 10 секунде происходит аккурат после того, как tuxonice пытается загрузить образ. Я бы подумал над этим.
Во-первых, объясни мне, что в тегах делает openrc, когда у тебя
[ 13.932962] systemd-udevd[13073]: starting version 207
Это нормально. У меня стоит openrc, приставка systemd- перед udevd ничего не значит.
В таких случаях рекомендуют обращаться к мейнтейнеру ядра и репортить баги. Однако в твоём случае в ядро натаскано сторонних патчей, поэтому тебе идти или в лес, или к post-factum, он вроде разбанился. p
Спасибо собрал обычное гентушное ядро. Бектрейсов нет. Хотя раньше с pf проблем не имел. Проблема с монтированием и нетворкманагером осталась. Видать в когфигах где то накосячил.
Во-вторых, твои SATA диски работают на UDMA/100 и 133, что эквивалентно скорости IDE-диска. Я не уверен, насколько это нормально, пока не увидел модели контроллера и дисков
Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
Мне до этого казалось, что eudev для того и пилили, чтобы с openrc не перекатываться, а udev>197 для systemd-онли.
приставка systemd- перед udevd ничего не значит.
Значит. Что у кого-то руки загребущие.
Проблема с монтированием и нетворкманагером осталась.
Для монтирования достаточно рабочего udevd (кстати /etc/init.d/udev status) и приблуды навроде thunar-volume-manager для thunar или autofs. Можно и самому правила для udev написать. К eudev приличная документация идёт. Про nm, который ненужен, могу посоветовать проверить consolekit и параметры ядра Как правильно пинать dbus-launch из ~/.xinitrc?
Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
Хм. [AHCI mode] намекает, что модуль ahci работает. Не знаю, почему оно тогда пишет про UDMA/133. Может, это вроде предела в режиме IDE, хотя зачем его выводить, когда есть AHCI?.. В общем, не беспокойся, это моя паранойя.
Э-э-э… То есть, udev>197 потянет за собой systemd, оно установится, но юзать с таким udev можно и openrc? В чём был тогда смысл пилить форк >_O Алсо, может ответишь мне на Gentoo всё? (комментарий)
Для монтирования достаточно рабочего udevd (кстати /etc/init.d/udev status) и приблуды навроде thunar-volume-manager для thunar или autofs. Можно и самому правила для udev написать
Правила почему то игнорируются. Лажа где то в KDE. Если KDE не запускать udisksctl не просит пароль рута.