Ubuntu 24.04 завантажується в чорний екран або цикл перезавантажень: 6 виправлень

December 9, 2025 • February 3, 2026 • Читання: 6 хв • Views: 10

Було корисно?

Ви перезавантажилися після оновлення, а машина віддячила вам чорним екраном. Можливо, мигне логотип виробника, можливо, бачите блимальний курсор, можливо, вона «перезавантажується» вічно, ніби готується до марафону. На ноутбуці це дратує. На віддаленій машині — це подія, що обмежує кар’єру.

Це не питання настрою. Зазвичай це один із кількох конкретних режимів відмови: ініціалізація графіки, невідповідність ядра/initramfs, Secure Boot, який відмовляє модулю, відмова дисплейного менеджера, глюк у зберіганні/файловій системі або GRUB, який заплутався, що означає «root» сьогодні. Нижче — шість виправлень, які вирішують більшість випадків чорного екрану/циклів завантаження в Ubuntu 24.04 — і швидкий план дій, щоб з’ясувати, з чим ви маєте справу.

Швидкий план діагностики (перевірте спочатку)

Коли ви дивитесь на чорний екран, ваше завдання — визначити, на якому саме етапі завантаження сталася відмова. Не кидайтеся латати все підряд. Ви створите ще один інцидент поверх першого.

Крок 1: Ядро взагалі завантажилося?

Ознаки, що ні: миттєвий цикл перезавантажень, відсутня активність диска після заставки прошивки, немає меню GRUB, не вдається перейти в TTY, нічого в журналі за останнє завантаження.
Можливі причини: проблеми з GRUB/EFI шляхом, неправильний UUID root, пошкоджений initramfs, пошкоджений EFI System Partition, зміни порядку завантаження у прошивці.
Рухайтесь до: Виправлення 6 (GRUB/завантажувач) і Виправлення 3 (initramfs/ядра).

Крок 2: Ядро завантажилося, але ви ніколи не отримуєте робочий графічний вхід

Ознаки: ви можете переключитися в TTY (Ctrl+Alt+F3), працює ping, працює SSH, але екран чорний або повертає вас до входу повторно.
Можливі причини: невідповідність драйвера GPU, проблеми з GDM/Wayland, Secure Boot блокує модуль, зламана сесія Xorg/Wayland.
Рухайтесь до: Виправлення 2 (GPU/nomodeset) і Виправлення 4 (Secure Boot/MOK), потім Виправлення 1 (журнали).

Крок 3: Завантажується «іноді» або тільки після жорсткого вимкнення

Ознаки: періодичне зависання, запити fsck, затримки в завантаженні, «Started GNOME Display Manager» ніколи не з’являється, або випадкові зависання під час опитування дисків.
Можливі причини: помилки файлової системи, збій диска, NVMe таймаути, повна коренева файлова система, неправильна конфігурація відновлення з гібернації.
Рухайтесь до: Виправлення 5 (зберігання/фс) та завдань у розділі Практичні завдання для перевірки здоров’я диска і вільного місця.

Одна операційна настанова: якщо доступний SSH — робіть усе по SSH і тримайте відкритий root-шелл. Це менш ефектно, ніж риття на місцевій консолі, але так ви уникнете погіршення ситуації.

Цікаві факти та контекст (чому це трапляється)

Ubuntu 24.04 — це LTS (Long Term Support), тобто в деяких аспектах вона консервативна — але все одно використовує новіші ядра й графічні стекі порівняно зі старішими релізами LTS.
«Чорний екран» часто — це відмова конвеєра відображення, а не збій системи. Багато машин можуть бути повністю завантажені з мережею, але екран вам бреше.
Wayland давно став дефолтом для багатьох десктопних інсталяцій Ubuntu, і це змінило місця появи відмов (композитор проти Xorg) і спосіб їх налагодження.
Пропрієтарний драйвер NVIDIA досі — найпоширеніша причина запуску в чорний екран після оновлення на десктопах. Не тому, що він зловмисний — а тому, що він сильно вбудовується в ядро/GL і чутливий до змін ABI.
Secure Boot не «ламить Linux», але може запобігти завантаженню неподписаних модулів ядра, що виглядає точно як «драйвер зник».
initramfs — це маленька рання файловая система, створена з драйверів і скриптів вашої системи; якщо в ній бракує драйверів зберігання або в ній є застарілі шляхи модулів, ядро завантажується, а далі не може примонтувати root.
GRUB тепер має складніше завдання з UEFI, бо вам треба не просто завантажити завантажувач з MBR — потрібно орієнтуватися серед записів прошивки, EFI-файлів і особливостей виробників.
Цикли завантаження часто — це systemd, що «перезапускає після збою», що корисно для демонів і погано для людей без логів.
Повна коренева файлова система часто виглядає як проблема з графікою, бо дисплейний менеджер не може записувати стан, логи або токени автентифікації — отже, він падає або зациклюється.

Одна ідея (парафраз) від Вернера Вогельса, колишнього CTO AWS, що тут підходить: «Все ламається, постійно; проектуйте та експлуатуйте з цим припущенням». Ставтеся до чорного екрану як до звичайного режиму відмови з планом дій, а не як до особистої образи.

Жарт #1: Чорний екран — це просто спосіб комп’ютера попросити менше сюрпризів і більше логування. Він не помиляється.

6 виправлень, які зазвичай допомагають

Виправлення 1: Отримайте консоль і уважно читайте журнали завантаження

Перед тим як «латати» щось, потрібні докази. Ваші цілі:

Kernel ring buffer (помилки драйверів, збої GPU, таймаути зберігання)
systemd journal (цикл перезапуску сервісів, відмови дисплейного менеджера)
Журнали попереднього завантаження (якщо система перезавантажилася під час завантаження)

Якщо машина локальна — спробуйте переключитися в TTY: Ctrl+Alt+F3. Якщо віддалена — спробуйте SSH. Якщо ні те, ні інше не працює, ви в зоні завантажувача/initramfs — переходьте до Виправлення 3 і Виправлення 6.

Що ви шукаєте — не просто «помилку», а закономірність: повторні скидання GPU, «Failed to start GDM», «drm» збої, «EXT4-fs error», «nvme timeout» або відмова модуля через Secure Boot.

Виправлення 2: Скидання GPU/драйвера (NVIDIA, AMD, Intel) і тріаж з «nomodeset»

Проблеми з графікою зазвичай діляться на дві категорії:

Шлях kernel modesetting зламався (ви зависаєте рано, чорний екран, можливо блимальний курсор).
Шлях дисплейного менеджера/композитора зламався (ядро завантажується, але GUI не стартує або зациклюється).

Тріаж: тимчасово використайте nomodeset, щоб отримати завантаження та зібрати журнали. Це не «вирішення». Це ломик, що підніме кришку.

Якщо це NVIDIA, «вирішення» часто таке: дістатися до TTY, прибрати пошкоджений драйвер, завантажитися тимчасово з відкритим драйвером nouveau, потім перевстановити відому сумісну версію NVIDIA, що відповідає вашому ядру. Якщо AMD/Intel — частіше це регресія ядра або застарілий initramfs без потрібної прошивки.

Wayland vs Xorg теж має значення. GDM можна налаштувати на відкат до Xorg, коли Wayland поводиться некоректно з певними драйверами. Не розцінюйте це як поразку; розглядайте як стратегію локалізації проблеми.

Виправлення 3: Перегенеруйте initramfs і перевірте набір ядер

Коли Ubuntu оновлює ядро, вона також створює нові образи initramfs. Якщо збірка initramfs провалюється (недостатньо місця, перерване оновлення, помилка postinst скрипта), ви можете отримати:

GRUB вказує на існуюче ядро, але відсутній initramfs
initramfs є, але в ньому відсутні модулі/прошивка через помилки під час збірки
ядро завантажується, але не може примонтувати root, що викликає цикли завантаження

Ваш крок: завантажтеся в старіше ядро з GRUB, якщо таке доступне, а потім перегенеруйте initramfs для всіх встановлених ядер. Якщо жодне старе ядро не працює — використайте режим відновлення або live ISO + chroot.

Це також місце, де ви прибираєте напіввстановлений набір пакетів ядра. Поламані DKMS-модулі (часто NVIDIA або VirtualBox) також можуть перервати генерацію initramfs.

Виправлення 4: Secure Boot, MOK enrollment і чому ваш модуль «зник»

Secure Boot корисний, коли ви хочете знати, який код запускається під час завантаження. Менш корисний, коли ви забуваєте, що його ввімкнули, а потім ставите сторонні драйвери, що потребують модулів ядра.

Типовий симптом: після оновлення ви потрапляєте на чорний екран або GUI не стартує, а в журналах видно відмови завантаження модулів. Для NVIDIA це видно в journalctl та dmesg. Для інших DKMS-модулів може бути так, що збірка DKMS пройшла, але модулі не завантажуються через проблеми з підписом.

Виправлення — одне з двох:

правильно зареєструвати Machine Owner Key (MOK) і підписати модулі, або
тимчасово вимкнути Secure Boot у прошивці, щоб підтвердити причинно-наслідковий зв’язок (потім вирішити політику).

Якщо у вас продакшн-ендпойнти, «вимкнути Secure Boot назавжди» рідко є прийнятним стандартом. Використайте це як діагностичний важіль, а не як постійний стиль життя.

Виправлення 5: Усунення проблем файлової системи/зберігання, що маскуються під «графіку»

Ось неприємний секрет: багато звітів про «чорний екран» насправді — проблеми зі зберіганням. Система завантажується допоки не потрапить на:

пошкоджену файлову систему, що викликає режим аварії
кореневу файлову систему, що на 100% заповнена, через що сервіси падають у дивний спосіб
NVMe-пристрій, що видає таймаути, блокуючи udev і systemd

І оскільки дисплейний менеджер знаходиться близько до кінця ланцюга завантаження, його звинувачують першим. Це як кричати на офіціанта, бо на кухні закінчився газ.

Виправлення включає перевірку стану диска, підтвердження можливості монтування root у режимі читання-запису, запуск fsck за потреби та забезпечення достатнього вільного місця для журналів, оновлень і кешів шейдерів GPU.

Виправлення 6: GRUB та ремонт завантажувача (UEFI, ESP та неправильний root)

Якщо ви ніколи надійно не доходите до ядра, ви в зоні завантажувача. Ubuntu 24.04 на сучасному обладнанні майже завжди завантажується через UEFI з EFI System Partition (ESP). Поширені відмови:

ESP заповнена або пошкоджена
запис прошивки вказує на відсутній EFI-файл
конфіг GRUB вказує неправильний UUID root після клонування диска або переразмічення
зміни в подвійній завантажуванні після оновлення Windows, що змінюють порядок завантаження

Виправлення — підтвердити, що ESP змонтована, перевстановити GRUB для UEFI, згенерувати grub.cfg і перевірити UUID у /etc/fstab та погляді GRUB на диски.

Жарт #2: UEFI-прошивка має характер, і це такий характер, що «забуває» ваш запис завантаження прямо перед дедлайном.

Практичні завдання: команди, що означає вивід, що вирішувати

Нижче — реальні завдання, які я виконую в режимі інциденту. Кожне містить: команду, приклад виводу, що це означає і яке рішення приймати.

Завдання 1: Підтвердити, чи доступний TTY і яке ядро запущено

cr0x@server:~$ uname -a
Linux server 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 10 12:34:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Що це означає: Ядро працює. Це не проблема «не можу завантажитися»; це проблема «не можу отримати придатну сесію» (GUI, драйвери, сервіси або затримки збереження).

Рішення: Зосередьтеся на журналах (Завдання 2/3) і на відображенні/GPU (Завдання 6–10), поки не зайдете в хірургію GRUB.

Завдання 2: Переглянути критичні помилки попереднього завантаження

cr0x@server:~$ journalctl -b -1 -p err --no-pager | tail -n 30
Sep 22 08:11:02 server kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel
Sep 22 08:11:03 server gdm3[1223]: Failed to start session: Failed to open display
Sep 22 08:11:03 server systemd[1]: gdm.service: Main process exited, code=exited, status=1/FAILURE
Sep 22 08:11:03 server systemd[1]: gdm.service: Failed with result 'exit-code'.

Що це означає: Під підозрою — підпис модулів або верифікація Secure Boot, і GDM падає, тому що графічний стек не піднявся.

Рішення: Перейдіть до Виправлення 4 (Secure Boot/MOK) і Виправлення 2 (відновлення драйвера). Не витрачайте час на перевстановлення GNOME.

Завдання 3: Знайти етап завантаження, на якому система зависає

cr0x@server:~$ systemd-analyze blame | head -n 15
1min 12.340s dev-nvme0n1p3.device
  45.122s network-online.target
  18.090s plymouth-quit-wait.service
  12.881s systemd-journald.service
  11.004s snapd.seeded.service

Що це означає: Ядро і systemd живі; блок пристрою (NVMe розділ) займає понад хвилину. Це часто таймаути, повторні спроби або ненадійний диск.

Рішення: Розглядайте як проблему надійності зберігання (Виправлення 5). Очікуйте, що dmesg покаже NVMe таймаути.

Завдання 4: Перевірити dmesg на скидання GPU, таймаути зберігання або відсутню прошивку

cr0x@server:~$ dmesg -T | egrep -i "nvidia|amdgpu|i915|drm|nvme|EXT4-fs error|I/O error|firmware" | tail -n 40
[Mon Sep 22 08:12:01 2025] nvme nvme0: I/O 114 QID 7 timeout, aborting
[Mon Sep 22 08:12:08 2025] EXT4-fs (nvme0n1p3): recovery complete
[Mon Sep 22 08:12:10 2025] i915 0000:00:02.0: [drm] GuC firmware load failed

Що це означає: Кілька червоних прапорців: таймаути зберігання, відновлення ext4 і відсутня прошивка i915. Будь-який з них може призвести до чорного екрану.

Рішення: Віддайте пріоритет здоров’ю диска і пакункам прошивки. Якщо диск помирає — жодні налаштування відображення не врятують вас.

Завдання 5: Перевірити вільне місце (нудна перевірка, що рятує від несподіваних проблем)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3    97G   97G     0 100% /

Що це означає: Root заповнений. Сервіси, яким потрібен запис (gdm, journald, apt тригери, сесії користувачів) будуть падати дивними способами, включно з петлями входу і чорними екранами.

Рішення: Негайно звільніть місце (журнали, старі ядра, кеші). Потім повторіть налаштування пакетів і перегенеруйте initramfs, якщо потрібно (Виправлення 3).

Завдання 6: Перевірити, яку GPU та стек драйверів система вважає активними

cr0x@server:~$ lspci -nnk | egrep -A3 "VGA|3D|Display"
00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT2 [8086:46a6]
	Subsystem: Lenovo Device [17aa:3a21]
	Kernel driver in use: i915
	Kernel modules: i915

Що це означає: Intel i915 — активний драйвер. Чорний екран може бути через прошивку, регресію ядра або поведінку дисплейного менеджера/Wayland.

Рішення: Якщо dmesg показує помилки завантаження прошивки — встановіть відсутні пакети прошивки і перегенеруйте initramfs (Виправлення 3). Якщо це специфічно для Wayland — спробуйте відкат до Xorg (Завдання 10).

Завдання 7: Перевірити, чи gdm падає або зациклюється

cr0x@server:~$ systemctl status gdm --no-pager
● gdm.service - GNOME Display Manager
     Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-09-22 08:11:03 UTC; 2min 12s ago
   Main PID: 1223 (code=exited, status=1/FAILURE)

Sep 22 08:11:03 server gdm3[1223]: GdmDisplay: Session never registered, failing
Sep 22 08:11:03 server systemd[1]: gdm.service: Failed with result 'exit-code'.

Що це означає: Дисплейний менеджер не запустив робочу сесію. Це може бути драйвер GPU, проблема Wayland, права доступу або симптоми повного диска.

Рішення: Витягніть логи GDM (Завдання 8) і вирішіть, чи перейти на Xorg або тимчасово використати інший дисплейний менеджер для локалізації проблеми.

Завдання 8: Витягнути логи GDM і GNOME Shell з поточного завантаження

cr0x@server:~$ journalctl -b -u gdm --no-pager | tail -n 80
Sep 22 08:10:59 server gdm3[1102]: Enabling debugging
Sep 22 08:11:02 server gdm3[1223]: Gdm: GdmDisplay: no session desktop files installed
Sep 22 08:11:03 server gdm3[1223]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

Що це означає: «No session desktop files» вказує на пошкоджені пакунки або напівзавершене оновлення, а не чисто GPU-проблему.

Рішення: Перевірте стан пакетів (Завдання 11), потім перевстановіть пакети сесії робочого столу за потреби. Не перезавантажуйтеся постійно в надії, що це вирішить проблему саме по собі.

Завдання 9: Тимчасове завантаження з «nomodeset», щоб отримати робочу консоль/базовий GUI

cr0x@server:~$ grep -n "GRUB_CMDLINE_LINUX_DEFAULT" /etc/default/grub
6:GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Що це означає: nomodeset увімкнено постійно в GRUB. Це часто дозволяє завантажитися, але відключає належне GPU-прискорення і може зменшувати роздільну здатність.

Рішення: Використовуйте це лише як діагностичну підпору. Після виправлення драйвера/прошивки приберіть nomodeset і згенеруйте GRUB заново (Завдання 16).

Завдання 10: Примусити GDM використовувати Xorg замість Wayland (поширений крок із локалізації)

cr0x@server:~$ sudo sed -n '1,80p' /etc/gdm3/custom.conf
# GDM configuration storage
[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false

Що це означає: Wayland вимкнено для GDM. Це часто стабілізує системи з певними налаштуваннями NVIDIA або регресіями композитингу.

Рішення: Якщо це вирішує чорний екран, залиште як тимчасовий захід і заплануйте оновлення драйвера/ядра пізніше.

Завдання 11: Перевірити наявність некоректного оновлення (напівналаштовані пакети, помилки DKMS)

cr0x@server:~$ sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 linux-image-6.8.0-41-generic   Linux kernel image for version 6.8.0 on 64 bit x86 SMP

Що це означає: Пакет ядра не завершив конфігурацію — часто через збій при побудові initramfs, відсутність місця або помилку DKMS.

Рішення: Виправте передумови (місце, помилки DKMS), потім запустіть dpkg --configure -a і перегенеруйте initramfs (Виправлення 3).

Завдання 12: Перегенерація initramfs для всіх ядер

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-40-generic

Що це означає: Образи initramfs успішно згенеровані. Якщо ви бачили помилки тут — вони важливі; перегорніть вивід і виправте їх замість перезавантаження в надії.

Рішення: Якщо генерація успішна — оновіть GRUB і перезавантажтеся. Якщо не вдається через DKMS — спочатку виправте збірку/підпис модулів (часто Виправлення 4 для Secure Boot).

Завдання 13: Визначити встановлені ядра і вибрати відкат у GRUB

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2}'
linux-image-6.8.0-40-generic
linux-image-6.8.0-41-generic
linux-image-generic

Що це означає: У вас принаймні два ядра. Це ваша подушка безпеки.

Рішення: Якщо 6.8.0-41 падає — завантажте 6.8.0-40 з «Advanced options for Ubuntu» і ремонтуйте звідти (Виправлення 3 / Виправлення 2 залежно від симптомів).

Завдання 14: Перевірити стан Secure Boot з працюючої системи

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Що це означає: Secure Boot увімкнено, отже неподписані сторонні модулі можуть бути заблоковані.

Рішення: Якщо ви покладаєтесь на NVIDIA або інші DKMS-модулі — переконайтеся, що MOK зареєстровано і модулі підписано правильно (Виправлення 4). Не перевстановлюйте драйвери без вирішення підпису.

Завдання 15: Перевірити, чи завантажено модуль NVIDIA (за потреби)

cr0x@server:~$ lsmod | egrep '^nvidia|nouveau'
nouveau              2795520  2

Що це означає: Система використовує nouveau, а не пропрієтарний модуль NVIDIA. Це може бути навмисно або означати, що NVIDIA не змогла завантажитися.

Рішення: Якщо вам потрібна пропрієтарна NVIDIA для CUDA/3D — перевірте журнал на помилки завантаження модуля і питання Secure Boot (Виправлення 4), а потім перевстановіть правильну версію драйвера (Виправлення 2).

Завдання 16: Оновити конфіг GRUB після змін

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
Found linux image: /boot/vmlinuz-6.8.0-40-generic
Found initrd image: /boot/initrd.img-6.8.0-40-generic
done

Що це означає: GRUB бачить обидва ядра та initramfs. Добре.

Рішення: Якщо GRUB не бачить очікувані образи — зупиніться і перевірте місткість /boot та цілісність файлової системи (Виправлення 5).

Завдання 17: Перевірити монтування ESP і вільне місце (проблеми UEFI)

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE         FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro

Що це означає: ESP змонтовано і доступне для запису (поки що). Якщо воно відсутнє — встановлення GRUB може «успішно» відпрацювати, але не потрапити туди, куди очікує прошивка.

Рішення: Якщо ESP не змонтовано — змонтуйте, перевірте /etc/fstab і відновіть записи GRUB/EFI (Виправлення 6).

Завдання 18: Запустити fsck коли система в аварійному режимі або з live середовища

cr0x@server:~$ sudo fsck -f /dev/nvme0n1p3
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p3: recovering journal
/dev/nvme0n1p3: clean, 512345/6553600 files, 8123456/26214400 blocks

Що це означає: Відновлення журналу відбулося і файлова система тепер чиста.

Рішення: Якщо fsck повідомляє про непоправні помилки або повторювану корупцію — припиніть розглядати це як програмну проблему. Замініть диск і відновіть дані.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через хибне припущення

Середня компанія використовувала флот Ubuntu робочих станцій для розробки і кілька on-prem GPU серверів для навчання моделей. Одного понеділка кілька десктопів після оновлення вийшли «нежиттєздатні»: чорний екран, вентилятори крутяться, немає GUI.

Інженер на виклику припустив, що це регресія GNOME, бо «екран входу чорний, отже проблема з десктопом». Вони дистанційно перевстановили пакети десктопа через rescue shell, перезапустили GDM і спробували кілька дисплейних менеджерів. Нічого не допомогло. Тим часом більше машин автооновлювалися в той самий стан.

Справжня причина: Secure Boot було ввімкнено у прошивці на партії ноутбуків після оновлення BIOS. Пропрієтарний GPU-модуль більше не приймався без коректної MOK-реєстрації. Машини завантажувалися нормально; графічний стек — ні.

Поворотний момент настав, коли хтось зробив неефектну, але правильну річ: journalctl -b -p err і прочитав журнал від початку до кінця. Помилки верифікації модулів були прямо у виводі. Як тільки вони стандартизували процес реєстрації MOK під час встановлення драйвера або тимчасово перемкнули постраждалі машини на Xorg, флот швидко відновився.

Урок не в тому, що «Secure Boot — поганий». Урок у тому, що припущення дорогі. Коли екран чорний — журнали ядра — ваша реальність.

Міні-історія 2: Оптимізація, що обернулася проти

Інша команда хотіла швидше забезпечувати патчі на кінцевих точках співробітників. Вони налаштували unattended-upgrades, щоб застосовувати оновлення автоматично і перезавантажувати вночі. На папері — добре: менше відомих вразливостей, менше ручних перезавантажень.

Потім збій сумісності драйвера і ядра вразив підмножину машин із дискретними GPU. Перезавантаження відбулося о 3:00. Вранці користувачі прийшли до чорних екранів, а служба підтримки виглядала як атака відмовою в обслуговуванні — але самостійно спричинена.

Ця «оптимізація» базувалася на припущенні, що перезавантаження — непомітна річ. Насправді перезавантаження — це подія зміни: ядро, initramfs, драйвери, прошивка і завантажувач тестуються одночасно. Якщо у вас немає поетапних розгортань, канарок або хоча б правила «не перезавантажувати, якщо останнє завантаження було поганим», ви граєте в рулетку в масштабі.

Вони виправили це, впровадивши фазові релізи (навіть просте кільцеве розгортання), зберігаючи принаймні два відомо робочі ядра і забезпечивши доступ із віддаленого доступу (SSH увімкнено, документований доступ до консолі). Unattended upgrades залишилися — але з обмеженнями. Нудно, але ефективно.

Міні-історія 3: Нудна, але правильна практика, що врятувала

Фінансова організація працювала на Ubuntu на кількох сотнях ноутбуків і спільних робочих станціях. Їхня політика безпеки була суворою, тому Secure Boot лишався увімкненим. Також у них була проста, але дисциплінована практика: кожна машина зберігала два ядра, і вони регулярно перевіряли, що GRUB показує «Advanced options» з кількома записами.

Коли оновлення ядра спричинило регресію на певній апаратній моделі, не знадобилося героїчних зусиль. Користувачі знали, що треба вибрати попереднє ядро в GRUB. IT мав короткий скрипт, щоб закріпити погане ядро й утримувати оновлення до приходу фікса.

Що це зробило можливим — не технічна геніальність, а операційна підготовка: «Якщо нове ядро ламає систему — завантажуй попереднє, збирай журнали, потім ліквідовуй проблему». Вони також звичали перевіряти вільне місце на / і /boot під час планового обслуговування, що запобігло класичній помилці побудови initramfs через заповнений розділ.

Інцидент не перетворився на кризу, бо організація ставилася до завантажуваності як до функції надійності — протестованої, збереженої і документованої. Передбачуваність перемагає хитрощі.

Типові помилки: симптом → причина → виправлення

1) Симптом: Чорний екран, але ви можете зайти по SSH

Причина: Дисплейний менеджер (GDM) падає через невідповідність драйвера GPU, проблеми Wayland або повний диск.
Виправлення: Перевірте systemctl status gdm і journalctl -u gdm. Якщо NVIDIA — перевірте завантаження модуля та Secure Boot (Виправлення 4). Спробуйте відкат до Xorg (Виправлення 2 / Завдання 10). Перевірте використання диска (Завдання 5).

2) Симптом: Цикл завантаження після оновлення ядра; GRUB з’являється на мить

Причина: Поламаний initramfs або поствстановлення ядра; іноді DKMS зламався під час оновлення.
Виправлення: Завантажте старіше ядро, запустіть dpkg --configure -a, потім update-initramfs -u -k all і update-grub (Виправлення 3).

3) Симптом: «Started GNOME Display Manager» ніколи не з’являється; довгі затримки

Причина: Затримки зберігання (NVMe таймаути), очікування fsck або пошкоджений диск.
Виправлення: Використайте systemd-analyze blame і dmesg з фільтром на nvme/I/O (Завдання 3/4). Запустіть fsck за потреби (Завдання 18). Замініть підозріле обладнання (Виправлення 5).

4) Симптом: Петля входу (вводите пароль, вас повертає до екрану входу)

Причина: Повний диск, пошкоджені файли сесії користувача, неправильні права у домашній теці або падіння GDM/Wayland.
Виправлення: Перевірте df -h, звільніть місце; перевірте journalctl на помилки сесії; спробуйте Xorg; підтвердьте права в home. Перезапустіть gdm після виправлення.

5) Симптом: Чорний екран одразу після вибору Ubuntu в GRUB

Причина: Регресія kernel modesetting або deadlock драйвера GPU рано в завантаженні.
Виправлення: Тимчасово додайте nomodeset в GRUB, щоб завантажитися, а потім відновіть драйвер/прошивку і приберіть nomodeset (Виправлення 2).

6) Симптом: Немає меню GRUB; прямо в прошивку або «no boot device»

Причина: Запис завантаження EFI відсутній, ESP пошкоджено/не змонтовано, диск не виявлено.
Виправлення: Перевірте порядок завантаження у прошивці, змонтуйте ESP, перевстановіть GRUB в режимі UEFI через chroot, якщо потрібно (Виправлення 6). Якщо диск відсутній — це апаратна проблема.

Чеклисти / покроковий план

Чеклист A: Якщо ви можете потрапити в TTY або SSH (найпоширеніший випадок)

Підтвердіть, що ядро працює: uname -a.
Витягніть помилки попереднього завантаження: journalctl -b -1 -p err.
Перевірте вільне місце: df -h / і також df -h /boot, df -h /boot/efi.
Перевірте стан GDM: systemctl status gdm і journalctl -u gdm.
Перевірте стан драйвера GPU: lspci -nnk, lsmod, і dmesg -T на помилки drm/gpu.
Якщо NVIDIA + Secure Boot увімкнено: підтвердьте з mokutil --sb-state і вирішіть питання MOK (Виправлення 4).
Відновіть стан пакетів: dpkg --audit, потім dpkg --configure -a, якщо потрібно.
Перегенеруйте initramfs: update-initramfs -u -k all, потім update-grub.
Якщо потрібно — ізолюйте проблему: змусьте Xorg у /etc/gdm3/custom.conf і перезапустіть gdm.
Перезавантажтеся один раз — один чистий перезавантаження, не п’ять розгніваних — і знову перевірте журнали.

Чеклист B: Якщо ви не можете потрапити в TTY/SSH (зона завантажувача/initramfs)

При завантаженні примусьте меню GRUB (утримуйте Shift або натискайте Esc залежно від прошивки).
Спробуйте «Advanced options» і завантажте старіше ядро.
Спробуйте режим відновлення і shell «root». Якщо shell доступний — продовжуйте з Чеклисту A для перевірки журналів і дисків.
Якщо жодне встановлене ядро не завантажується: використайте live ISO Ubuntu, змонтуйте root, chroot і перегенеруйте initramfs та перевстановіть GRUB (Виправлення 3 + Виправлення 6).
Перевірте монтування ESP і відновіть EFI-записи.
Лише після того, як програмне відновлення не допоможе: підозрюйте апаратні проблеми з диском/контролером.

Чеклист C: Правила «не роби гірше»

Не видаляйте випадкові пакети, поки не зафіксуєте журнали з journalctl -b -1 і dmesg.
Не перезавантажуйте часто; ви втрачаєте докази і додатково навантажуєте пошкоджене обладнання.
Не тримайте систему постійно на nomodeset, якщо тільки це не кіоск і вам подобається низька роздільна здатність.
Не відключайте Secure Boot назавжди автоматично. Вирішіть свідомо: безпекова політика проти простоти експлуатації.

FAQ

1) Як зрозуміти, що це «лише GUI», а не вся система?

Якщо ви можете перейти в TTY (Ctrl+Alt+F3) або підключитися по SSH — ядро завантажилося і systemd працює. Тоді ви налагоджуєте графіку/дисплейний менеджер або затримки пізнього завантаження, а не GRUB.

2) Чи вирішує «nomodeset» проблему?

Ні. Воно часто дозволяє завантажитися, уникаючи kernel modesetting, що дає вам точку опори для відновлення драйверів/прошивки. Ставтеся до нього як до запасного колеса.

3) Чому оновлення драйвера NVIDIA викликає чорний екран після оновлення ядра?

Пропрієтарний стек NVIDIA залежить від інтерфейсів ядра і будує модулі (часто через DKMS). Якщо збірка модуля провалюється, або Secure Boot блокує модуль, графічний стек не зможе стартувати.

4) Яка найшвидша команда, що зазвичай каже правду?

journalctl -b -1 -p err — хороший початок, особливо після циклу перезавантажень. Вона фільтрує помилки з попереднього завантаження, коли сталася відмова.

5) Чи справді повний диск може викликати чорний екран?

Так. GDM, GNOME Shell і навіть компоненти автентифікації потребують запису файлів. Якщо / заповнений, ви можете отримати петлі входу, падіння сесій і «порожній» робочий стіл.

6) Чи варто переключитися з Wayland на Xorg?

Якщо ви заблоковані і потрібна машина зараз — так. Переключення GDM на Xorg — розумний тимчасовий захід. Потім заплануйте час на виправлення драйвера/ядра.

7) Як відновити, якщо я навіть не бачу меню GRUB?

Спробуйте примусити його через Esc/Shift під час завантаження. Якщо прошивка ніколи не передає управління GRUB, можливо знадобиться live ISO для відновлення запису EFI і перевстановлення GRUB (Виправлення 6).

8) Це частіше на десктопах, ніж на серверах?

Так. Сервери часто працюють без GUI і з консервативнішими драйверами. Десктопи поєднують GPU, композитори і часті зміни драйверів — більше рухомих частин, більше режимів відмови.

9) Якщо fsck «вилікував» проблему раз — чи все добре?

Не обов’язково. Одне відновлення після некоректного вимкнення — нормально. Повторювані ремонти файлової системи або NVMe таймаути — сигнал проблеми надійності: дивіться SMART/стан пристрою і плануйте заміну.

Висновок: наступні кроки, щоб запобігти повторенню

Чорні екрани і цикли завантаження в Ubuntu 24.04 рідко містять містику. Зазвичай це одна з шести речей: драйвери GPU, невідповідність initramfs/ядра, політика модулів Secure Boot, проблеми дисплейного менеджера/Wayland, збої зберігання/фс або дрейф GRUB/UEFI. Трюк — швидко визначити етап відмови, а потім застосувати виправлення, що відповідає доказам.

Наступні кроки, які реально зменшують майбутній біль:

Тримайте принаймні два встановлені ядра і підтверджуйте, що GRUB їх показує.
Регулярно перевіряйте вільне місце для /, /boot та /boot/efi.
Якщо ви використовуєте NVIDIA і Secure Boot — стандартизуйтесь на процесі MOK-реєстрації і підпису модулів замість імпровізації на кожній машині.
Розгортайте оновлення поетапно. Перезавантаження — це подія зміни, і так її треба оцінювати.
Коли щось ламається — збережіть journalctl -b -1 перед тим, як «латати». Журнали не брешуть; люди іноді брешуть.