[РЕШЕНО] Чем занята ОС уже 14 часов при загрузке?

[kiav]

Workstation K 8.3

splash при загрузке, дополз до конца и стоит, окно ввода пароля не появляется.
Индикатор активности жесткого диска мигает. Да и по звуку понятно, что что-то происходит.

Диск на 2ТБ. Я не помню сколько времени на нем занимал тест поверхности в режиме чтения. Такое ощущение, что системе очень захотелось проверить поверхность после сбоя. Это возможно?

Esc не дает эффекта, я понятия не имею чем занята система. Также не работает и Ctrl+F12. Остается только верить. Но уже долго.

Моя железяка с момента покупки выводит меня из себя зависаниями (мертво, железо так делает по неизвестным мне причинам). Это зависание сопровождается отказом USB клавиатуры (даже Num Lock не дает ничего). Сейчас же с клавиатурой все хорошо. Ну а мышь в этом экране никогда и не водила курсор.

Перезагрузку делал после зависания в процессе обновления ядра на std-debug. Была надпись, что он пытается менять конфиг grub2. Но привычного текста о том, что поменял не было. Перезагрузка показала, что действует старый конфиг (я еще отрубал splash в новом).

Системный диск у меня на SSD. Все остальное (/opt, /home ... ) на HDD. Вот он то как раз большой, на 2ТБ.

[berkut_174]

Это возможно?

Если прям 14 часов, то с трудом верится, так как за это время, если не 2 Тб, то 1 Тб то точно мог синхронизироваться в soft-RAID1.

Надо смотреть логи. Попробуйте по SSH подключиться к машине, если есть такая возможность.
Мне кажется, если никакие сочетания Ctrl+Alt+F* не срабатывают, то можно ребутить, система окончательно зависла и ничего ожидать не стоит.
Если проблема возникла при обновлении ядра, то загрузитесь со старым.

[kiav]

можно ребутить, система окончательно зависла и ничего ожидать не стоит.

Да, так и есть. Я бы ждал вечность.


В логе journalctl бесконечно повторяется

sddm[813]: /usr/bin/xauth: (stdin):1: bad "remove" command line
sddm[813]: /usr/bin/xauth: (stdin):2: bad "add" command line
sddm[813]: QProcess: Destroyed while process ("/usr/libexec/sddm/sddm-helper") is still running.

[berkut_174]

sddm

Вот недавно читал тред https://forum.altlinux.org/index.php?topic=42009.msg333866#msg333866, не оно ?

[kiav]

Все прояснилось.

Несмотря на то, что создание нового конфига не отработало, загружалось именно новое (отладочное) ядро 4.9.154-std-debug-alt0.M80P.1

Вот оно то проблему и создавало. Так что моя мечта запустить отладку ядра и посмотреть где ядро на моей железяке недовольно у меня не выйдет. Я так и не узнаю мои проблемы порождены аппаратурой (и тогда надо сдавать по гарантии) или несовместимость с ядром (которое можно было надеяться исправить).

Ядер у меня много в системе. Начинал я с un-def из-за того, что прошлая железяка зависала на std-def. Думал новая тоже будет прекрасно на нем работать.
Понял, что un-def мне не помощник, переключился на std-def. Проработало 1,5 недели без нареканий, пока не случилось очередное зависание железа.
Ну а std-debug вовсе не работает.

Почему у меня при несработавшем обновлении подцепилось именно std-debug, а не, к примеру, un-def я не знаю. Это загадка.

sddm

Вот недавно читал тред https://forum.altlinux.org/index.php?topic=42009.msg333866#msg333866, не оно ?

Трудно сказать. На std-def и un-def на той же железяке проблем нет. Думаю, что-то не так с std-debug. На нем может не все модули есть. К примеру, точно нет для virtualbox.