Чёрный экран после загрузки: как AI нашёл симптом, а причину пришлось искать самому

Включаю утром ноутбук — чёрный экран. Перезагружаю — опять чёрный. Тут уже понятно, что само не пройдёт и жать reset дальше смысла нет.

При чёрном экране система чаще всего жива, не поднимается только графика. Поэтому я нажал Ctrl+Alt+F3, зашёл в текстовую консоль и разбирался уже оттуда: логи, драйвер, режим графики. Экран в итоге вернулся после переключения графики в режим on-demand и перезагрузки. Но до этого пришлось покопаться, и ниже я расскажу, как именно шёл поиск — от прогона логов через AI до момента, когда всё сошлось.

Что за машина: ноутбук ASUS с гибридной графикой (Intel + NVIDIA GeForce RTX 3050), Linux Mint на базе Ubuntu 24.04, проприетарный драйвер NVIDIA через DKMS.

Шаг 1. Прогоняю лог через AI

Для разбора логов у меня есть свой скрипт на Python. Он выбирает строки с ошибками, вычищает из них всё чувствительное (IP, почту, MAC, имена хостов), отдаёт языковой модели и получает обратно отчёт в JSON, где у каждой проблемы проставлена серьёзность.

Первый же прогон по /var/log/syslog споткнулся об особенность логов. Записи systemd-coredump — это целые стектрейсы, склеенные в одну строку: rsyslog пишет перевод строки как #012. Одна такая запись съедает сотни токенов, так что строки пришлось обрезать до 300 символов. Суть («Xorg dumped core») при этом остаётся, а стектрейс в данном случае и не нужен.

Модель прожевала сотню строк и выдала вот что:

high: Xorg раз за разом падает с core dump, lightdm уходит в цикл перезапусков, gpu-manager упирается в start-limit-hit;
medium: модуль nvidia не прошёл проверку подписи, драйвер i915 отключил встроенный дисплей eDP;
low: ошибки ACPI в прошивке, jackdbus, wsdd и прочий фоновый шум.

Честно скажу, глазами я бы главное в этом логе увидел не сразу: десятки строк ACPI и стектрейсы забивают всё. А модель свела 25 одинаковых падений в одну проблему и сразу поставила её наверх.

Только на этом её польза и закончилась. Дальше пришлось думать самому.

Шаг 2. Гипотезы, которые отпали

Модель выдала список проблем, но связать их в цепочку «одно вызвало другое» не смогла. Это я делал сам, проверяя версии по очереди.

Гипотеза	Проверка	Результат
Secure Boot не пускает неподписанный модуль nvidia	`mokutil --sb-state`	Secure Boot выключен — сообщение о подписи лишь предупреждение
Загрузки шли с разными ядрами, под одно модуль не собран	`journalctl -b -3 -k \| grep "Linux version"`, `dkms status`	Ядро одно и то же, модуль собран
DKMS собрал модуль только во время утренних загрузок	`ls -l --time-style=full-iso /lib/modules/$(uname -r)/updates/dkms/`	Модуль собран за две недели до сбоя
Видеокарта не определилась на шине PCI	`journalctl -b -3 -k \| grep "0000:01:00"`	Карта на месте в обеих загрузках

С каждой отброшенной версией круг сужался, и в итоге картина получилась странная: видеокарта есть, модуль есть, а драйвер никто не загрузил. В логе ядра сбойной загрузки от NVIDIA нашлась только звуковая часть карты (HDMI-аудио), а видеодрайвера не было вообще. Так система себя ведёт, когда загрузка nvidia запрещена намеренно.

Попутно заметил ещё одну вещь. journalctl --list-boots показал, что первые две загрузки длились полторы минуты и 16 секунд — это я сам перезагружал, не дождавшись. А /var/log/Xorg.0.log.old с причиной падения к тому моменту уже затёрся удачным запуском. Сам себе улики и уничтожил.

Шаг 3. Что поменялось между загрузками

Чтобы подтвердить догадку, я посмотрел, какие файлы в /etc менялись между сбойной и удачной загрузкой:

sudo find /etc -newermt "2026-10-25 09:38" ! -newermt "2026-10-25 10:02" -type f

Среди обновлений браузера и прочей мелочи нашёлся главный подозреваемый — /etc/prime-discrete. В этом файле записан режим переключения графики:

Значение	Режим
`on`	только NVIDIA
`off`	только Intel, драйвер NVIDIA не загружается
`on-demand`	гибридный: Intel по умолчанию, NVIDIA по запросу

$ cat /etc/prime-discrete
on-demand
$ ls -l --time-style=full-iso /etc/prime-discrete
... 2026-10-25 10:00:39 /etc/prime-discrete

Файл изменён в 10:00:39. Это ровно тот момент, когда я из консоли переключил режим на on-demand. Через 30 секунд была перезагрузка, и после неё всё заработало.

Что оказалось на самом деле

Графика стояла в режиме «только Intel». А на этом ноутбуке встроенный экран через Intel не работает — драйвер i915 так и писал, что дисплей eDP не нашёл.

Дальше всё по цепочке:

Режим «только Intel», драйвер NVIDIA не загружается.
Intel не видит встроенный экран.
Xorg не находит, куда выводить картинку, и падает.
lightdm перезапускает Xorg каждые 2 секунды, пока systemd не упирается в лимит перезапусков. На экране при этом просто чернота.
Переключаю на on-demand из консоли, перезагружаюсь — драйвер NVIDIA загружается, экран работает.

Как не наступить на это снова

Если встроенный экран не работает через Intel, режим «только Intel» выбирать нельзя. Нужен on-demand или nvidia. На ноутбуках с переключателем MUX в BIOS режим экрана вообще задаётся в прошивке, а не в Linux.
При чёрном экране не перезагружайтесь сразу. Нажмите Ctrl+Alt+F3, зайдите в консоль и выполните три команды. Они сразу покажут, в какую сторону копать:

lspci | grep -i nvidia   # видна ли видеокарта
lsmod | grep nvidia      # загружен ли драйвер
cat /etc/prime-discrete  # в каком режиме графика

Если там off, переключите режим и перезагрузитесь:

sudo prime-select on-demand
sudo reboot

Каждая лишняя перезагрузка стирает часть улик. У меня так и пропал лог Xorg с причиной падения.

Что я для себя вынес

AI здорово сэкономил время там, где человек тратит его больше всего: в куче однотипных ошибок он нашёл настоящую проблему и отделил её от шума. Но причину не назвал, а одну находку даже переоценил — проблему с подписью модуля, которая оказалась безобидным предупреждением.

Дальше сработала обычная инженерная рутина: выдвинул версию, проверил фактом, взялся за следующую. А окончательно всё подтвердил старый добрый find -newermt — посмотреть, что изменилось между «не работает» и «работает».

Как быстрый первый фильтр AI хорош. Но выводы пока всё равно делать мне.