Що grub rescue> насправді означає

GRUB має кілька «настроїв». Звичайний читає свою конфігурацію, пропонує меню (або завантажує одразу) і передає управління ядру.
grub rescue> — це урізана аварійна оболонка. Ви тут, бо core image GRUB завантажився, але він не може завантажити
те, що потрібно далі — зазвичай модулі та конфіг — тому що не може знайти файлову систему або шлях, який очікує.

Помилка майже завжди належить до однієї з цих категорій:

• Неправильне посилання на диск/розділ (змінився порядок пристроїв, перенумерація NVMe, змінено порядок завантаження в BIOS).
• Відсутній або переміщений /boot (зміна розміру розділу, видалення розділу, перевстановлення, «очищення»).
• Пошкоджені файли GRUB (часткове оновлення, пошкодження диска, неправильне підключення під час перевстановлення).
• Невідповідність UEFI та legacy (встановлено одним способом, а прошивка зараз пробує іншим).
• Складність через шифрування/LVM/RAID (GRUB не може прочитати том без потрібних модулів або правильної структури).

Ваш найбезпечніший припущення: операційна система все ще на диску, але вказівники завантажувача застаріли. Ставтеся до цього як
до зламаної карти, а не до знищеного міста.

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

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

Перше: визначте, який тип завантаження у вас (UEFI чи legacy BIOS)

Це визначає правильну ціль ремонту. В UEFI ви відновлюєте EFI System Partition (ESP) та запис NVRAM.
В legacy BIOS ви відновлюєте MBR / BIOS-ділянку завантаження і встановлення GRUB на диск.

• Якщо ви можете зайти в налаштування прошивки: чи є в списку варіант «ubuntu» як UEFI-опція завантаження? Якщо так — ймовірно UEFI.
• З live USB: наявність /sys/firmware/efi означає, що live-середовище завантажилось в UEFI-режимі.

Друге: знайдіть реальну файлову систему root і де знаходиться /boot

Ваші команди ремонту мають вказувати на фактично встановлену систему Ubuntu. Неправильне підключення = успішний ремонт не того, що треба.
Ідентифікуйте розділи за UUID та типом FS, а не за «зазвичай sda2».

Третє: підтвердіть, чи це проблема вказівників, чи проблема диска

Якщо диск виходить з ладу, перевстановлення GRUB — це як перефарбування тонукачого корабля. Перевірте SMART на очевидні проблеми та перегляньте
журнали ядра зі live-середовища на предмет помилок I/O. Якщо бачите помилки читання — зупиніться і надайте пріоритет даним.

Швидка розвилка рішень

• Ви бачите свої Linux-розділи і можете їх підключити: ймовірно, перевстановлення GRUB/перегенерація конфігурації виправить проблему.
• Ви не можете підключити файлову систему: спочатку ремонт файлової системи та/або усунення проблем зі сховищем.
• У вас LUKS + LVM + RAID: обережно відкривайте й збирайте шари, потім перевстановлюйте GRUB з chroot.

Цікаві факти та невелика історія (бо це важливо)

1. GRUB означає “GRand Unified Bootloader”, спочатку розроблений, щоб уніфікувати завантаження різних ОС та файлових систем, коли там був хаос.
2. GRUB2 — це не просто «версія 2» у лагідному сенсі; це була велика переробка з іншою семантикою конфігурації та модульним завантаженням.
3. «core image» навмисно маленький — це те, що прошивка завантажує спочатку, і воно намагається підвантажити модулі з диска. Коли підвантаження немає — потрапляєте в rescue.
4. UEFI змінив історію завантаження: замість коду в MBR, прошивка завантажує виконуваний файл EFI з ESP. Саме тому кроки перевстановлення відрізняються.
5. Сьогодні Ubuntu за замовчуванням очікує UEFI на сучасному залізі, але чимало серверів все ще працюють у legacy BIOS через сумісність або інерцію.
6. Нестабільність найменувань дисків реальна: NVMe може перенумеровуватись залежно від порядку перебору; контролери USB/SATA можуть змінювати порядок. UUID існують тому, що людям не подобаються сюрпризи.
7. Історично GRUB цінували за розуміння файлових систем у порівнянні зі старішими завантажувачами, які не могли читати ext* без допомоги.
8. Сучасний GRUB може читати LUKS1 в деяких налаштуваннях, але повне шифрування диска й нові налаштування за замовчуванням (LUKS2, параметри PBKDF) усе ще можуть ускладнювати раннє завантаження.
9. «Unknown filesystem» в GRUB часто означає «відсутній модуль», а не обов’язково що файлова система зникла — GRUB модульний, а rescue-режим завантажує менше модулів.

Одна перефразована ідея, яку варто тримати в голові (і в чеклісті інцидентів): надія не є стратегією. — приписують John C. Maxwell в операційних колах.
Незалежно від джерела, це влучно: спочатку виміряйте, потім змінюйте.

Практичні завдання: команди, виводи, рішення (суть)

Ці завдання передбачають, що ви працюєте з Ubuntu live USB (бажано тієї ж основної версії, але не обов’язково), і ваша мета —
мінімальні зміни. Кожне завдання включає: команду, що означає її вивід, і яке рішення далі.

Завдання 1: Підтвердити, чи live-середовище завантажилось в UEFI

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

Значення: Якщо ви бачите «UEFI mode», слід відновлювати шлях завантаження EFI і використовувати grub-install --target=x86_64-efi.
Якщо «Legacy BIOS mode», встановлюйте GRUB в MBR диска з --target=i386-pc.
Рішення: Якщо це не збігається з тим, як ОС була встановлена, перезавантажте live USB і виберіть правильний режим завантаження в прошивці.

Завдання 2: Перелічити блочні пристрої та файлові системи

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS
NAME         SIZE TYPE FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
nvme0n1    953.9G disk
├─nvme0n1p1   512M part vfat   FAT32       3C21-1A7B
├─nvme0n1p2     2G part ext4   1.0         2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b
└─nvme0n1p3 951.4G part crypto_LUKS 2     9d8d5b6a-8f1c-4a44-9b3c-3b2c9a1f0caa

Значення: Шукайте: ESP (vfat ~100–1024MB), можливо окремий /boot (ext4),
та кореневу файлову систему (ext4/xfs/btrfs) або крипто-контейнер.
Рішення: Запишіть імена пристроїв і UUID. Не починайте «чинити», поки не знатимете, який розділ за що відповідає.

Завдання 3: Якщо шифрування, відкрийте LUKS правильно (не імпровізуйте)

cr0x@server:~$ sudo cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS /dev/mapper/cryptroot
NAME      TYPE FSTYPE      MOUNTPOINTS
cryptroot crypt LVM2_member

Значення: Дешифрований пристрій — це LVM PV (поширена розмітка Ubuntu).
Рішення: Активуйте LVM далі. Якщо cryptsetup не вдається — зупиніться і перевірте, чи ви на правильному розділі та чи диск здоровий.

Завдання 4: Активувати LVM і знайти root

cr0x@server:~$ sudo vgscan --mknodes
  Found volume group "ubuntu-vg" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "ubuntu-vg" now active

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS | grep -E "ubuntu--vg|lv|root|swap" || true
├─ubuntu--vg-root  200G ext4
└─ubuntu--vg-swap    8G swap

Значення: Логічні томи тепер видимі. Root, ймовірно, ubuntu--vg-root.
Рішення: Підключіть root, потім /boot і ESP за потреби.

Завдання 5: Правильно змонтувати встановлену систему (root, boot, ESP)

cr0x@server:~$ sudo mount /dev/mapper/ubuntu--vg-root /mnt

cr0x@server:~$ sudo mkdir -p /mnt/boot /mnt/boot/efi

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

cr0x@server:~$ findmnt -R /mnt
TARGET         SOURCE                     FSTYPE OPTIONS
/mnt           /dev/mapper/ubuntu--vg-root ext4   rw,relatime
/mnt/boot      /dev/nvme0n1p2             ext4   rw,relatime
/mnt/boot/efi  /dev/nvme0n1p1             vfat   rw,relatime,fmask=0022,dmask=0022

Значення: findmnt — це ваша перевірка здорового глузду. Якщо ви змонтуєте не ті речі, ремонт може «вдало» відбутися
і все одно не завантажитись.
Рішення: Якщо /mnt/boot/efi відсутній при UEFI-встановленні, ви не готові перевстановлювати GRUB.

Завдання 6: Перевірте наявність очевидних проблем з диском або файловою системою перед записом даних завантаження

cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 30 09:14:12 2025] nvme nvme0: I/O 17 QID 6 timeout, aborting
[Mon Dec 30 09:14:12 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Значення: Помилки читання або таймаути означають, що слід призупинитися. Ремонт завантаження записує дані; якщо диск виходить з ладу,
ви ризикуєте під час відновлення.
Рішення: Якщо бачите I/O помилки — віддайте пріоритет створенню образів/бекапів. Якщо журнали чисті — продовжуйте.

Завдання 7: Визначте, як встановлена система очікує монтувати диски (перевірка UUID)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b /boot ext4 defaults 0 2
UUID=3C21-1A7B /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-root / ext4 defaults 0 1

Значення: Якщо fstab посилається на UUID, яких більше немає, завантаження може впасти пізніше навіть після виправлення GRUB.
Рішення: Якщо є невідповідності UUID — виправте їх зараз (акуратно). Але не вигадуйте UUID — використовуйте blkid.

Завдання 8: Подивіться на встановлену конфігурацію GRUB і визначте ціль

cr0x@server:~$ sudo ls -l /mnt/boot/grub
total 12
-rw-r--r-- 1 root root  144 Dec 29 18:12 grub.cfg
drwxr-xr-x 2 root root 4096 Dec 29 18:12 x86_64-efi
drwxr-xr-x 2 root root 4096 Dec 29 18:12 fonts

Значення: Наявність x86_64-efi свідчить про UEFI-встановлення. У legacy-встановленнях зазвичай буде i386-pc.
Рішення: Підбирайте grub-install --target відповідно до цього факту, а не за припущенням.

Завдання 9: Bind-mount системні директорії й chroot (правильний спосіб)

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/#

Значення: Тепер ви працюєте «всередині» встановленої ОС — звідти інструменти GRUB очікують запускатися.
Рішення: Якщо chroot не вдається або інструменти відсутні, можливо ви змонтували неправильний root або встановлення неповне.

Завдання 10: Перевстановити GRUB для UEFI (переважний шлях для Ubuntu 24.04 на сучасному залізі)

cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Значення: GRUB EFI-бінар та супровідні файли встановлені в ESP, і записи NVRAM можуть бути оновлені.
Рішення: Якщо зʼявляється помилка «cannot find EFI directory», ваша ESP не змонтована в /boot/efi.
Виправте підключення і запустіть знову.

Завдання 11: Перевстановити GRUB для legacy BIOS (коли ви справді в BIOS-режимі)

cr0x@server:~$ grub-install --target=i386-pc --recheck /dev/nvme0n1
Installing for i386-pc platform.
Installation finished. No error reported.

Значення: Код завантажувача GRUB записано в область завантаження диска. Це не спрямовано на розділ типу /dev/nvme0n1p2.
Рішення: Якщо ви не впевнені, з якого диска прошивка завантажується, зупиніться і підтвердьте. Встановлення на неправильний диск — класична помилка.

Завдання 12: Перегенерувати конфіг GRUB та initramfs (бо застарілі конфіги — частий ворог)

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

cr0x@server:~$ update-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
done

Значення: Це перебудовує initramfs (важливо для LUKS/LVM/RAID) і гарантує, що записи меню GRUB вказують на реальні ядра.
Рішення: Якщо update-grub не знаходить ядра — ваше підключення /boot неправильне або порожнє.

Завдання 13: Перевірити UEFI-записи завантаження (коли прошивка «забуває» ubuntu)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI: Built-in EFI Shell
Boot0002* ubuntu HD(1,GPT,2f3a...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Значення: У вас є запис ubuntu, що вказує на shimx64.efi (звично при Secure Boot).
Рішення: Якщо запису ubuntu немає — створіть його або перевстановіть GRUB, вказавши --bootloader-id.

Завдання 14: Якщо ви застрягли в grub rescue> без live USB, зробіть тимчасове завантаження

Це не «виправлення». Це «дозвольте мені потрапити в реальну ОС, щоб я міг виправити все правильно». В grub rescue> доступні обмежені команди.
Ваша ціль — знайти розділ з /boot/grub, встановити root та prefix, завантажити normal і завантажитись.

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

cr0x@server:~$ ls (hd0,gpt2)/
lost+found/ boot/ vmlinuz initrd.img

cr0x@server:~$ set root=(hd0,gpt2)

cr0x@server:~$ set prefix=(hd0,gpt2)/boot/grub

cr0x@server:~$ insmod normal

cr0x@server:~$ normal

Значення: Ви вручну вказали GRUB потрібне місце. Якщо це спрацює, зʼявиться звичне меню GRUB.
Рішення: Завантажте систему, потім перевстановіть GRUB постійно з Ubuntu (або з live USB), щоб це більше не повторилося.

Завдання 15: Підтвердити, що встановлена система бачить диски послідовно (UUID та by-id)

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 15 Dec 30 09:22 2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Dec 30 09:22 3C21-1A7B -> ../../nvme0n1p1

Значення: Мапування UUID існує. На цьому базується стабільне завантаження.
Рішення: Якщо ваш конфіг GRUB або fstab використовує сирі імена пристроїв (наприклад, /dev/nvme0n1p2), розгляньте перехід на UUID.

Завдання 16: Коректно вийти й перезавантажитись (щоб не залишити монтування)

cr0x@server:~$ exit
exit

cr0x@server:~$ for i in /run /sys /proc /dev/pts /dev; do sudo umount -l /mnt$i; done

cr0x@server:~$ sudo umount -l /mnt/boot/efi /mnt/boot /mnt

cr0x@server:~$ sudo reboot

Значення: Ви відмонтували в зворотному порядку. Це знижує ймовірність неконсистентних станів, особливо з LUKS/LVM- шарами.
Рішення: Якщо після перезавантаження знову потрапляєте в rescue — переходьте до таблиці помилок і перевірте режим завантаження + правильний диск.

Жарт №1: GRUB rescue — як пейджер-сповіщення — його не надсилають, коли все добре, але воно означає, що система ще з вами розмовляє.

Три корпоративні міні-історії (як це провалюється в реальності)

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

Компанія експлуатувала невелику ферму серверів Ubuntu на однаковому обладнанні. Ментальна модель була заспокійлива: та сама модель, ті самі налаштування BIOS,
та сама розмітка дисків. Хтось замінив несправний NVMe у вузлі, перевстановив образ і пішов далі.

Наступний перезапуск опинився в grub rescue>. На виклику припустили, що це «так само, як минулого разу» і одразу виконали
BIOS-режим grub-install на диск з live USB. Це «працювало» в сенсі запису коду завантаження.
Але це не допомогло серверу завантажитись.

Справжня причина: цей вузол було встановлено як UEFI, але live USB завантажили в legacy режимі, а прошивка тихо змінила порядок завантаження після заміни диска.
Вони ремонтували не той шар. Після кількох таких циклів на диску опинилися артефакти обох стилів завантаження і плутаючий список записів прошивки.

Виправлення було банальне: завантажити live USB в UEFI-режимі, змонтувати ESP в /boot/efi, перевстановити GRUB з UEFI-ціллю,
а потім перевірити sane boot entry за допомогою efibootmgr. Урок не в тому, що UEFI складний. Урок в тому, що ваше середовище ремонту
має відповідати режиму встановлення, інакше ваш «фікс» — це просто запис випадкового коду в завантажувач з впевненістю.

Міні-історія 2: Оптимізація, що зіграла навпаки

Інша організація мала звичку мікрооптимізувати розмітку дисків. Хтось вирішив, що окремі розділи /boot — це «спадщина»
і обʼєднав /boot у кореневу файлову систему під час оновлення сховища. Також вони ввели повне шифрування диска з сучасними налаштуваннями.
Виглядало чисто. Менше розділів, менше монтажів, менше потенційних проблем. Правда?

Потім прийшло оновлення, і частина машин почала потрапляти в GRUB rescue. Справжня причина не в оновленні ядра. Вона в тому, що раннє середовище завантажувача
стало менш здатним: GRUB не міг надійно прочитати зашифрований root у цій конфігурації, і не було нешифрованого /boot як простого проміжного етапу.

Команда першою думкою вважала «GRUB зламався». Вони перевстановлювали GRUB, перегенерували конфіги, навіть відтворювали записи EFI. Деякі вузли відновилися, деякі — ні,
і найгірше було різноманіття результатів — бо різність призводить до ескалації.

Довгострокове виправлення — стандартизувати: зберегти невеликий нешифрований /boot (і, звісно, ESP для UEFI) для цього класу серверів, документувати і тестувати.
«Оптимізація» забрала маржу безпеки. У продуктивних системах маржа безпеки — не сміття. Це ваше майбутнє вільний час.

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

Третя команда мала звичку, яка звучала нудно: кожного разу при зміні розділів або заміні диска вони фіксували базову інформацію:
lsblk -f, blkid, efibootmgr -v (на UEFI), плюс копію /etc/fstab і
/boot/grub/grub.cfg. Вони зберігали це поруч із записом зміни. Не вишукано. Дуже ефективно.

Коли сервер потрапив у grub rescue> після вікна обслуговування, on-call не довелось гадати, чи вузол UEFI чи legacy, чи /boot окремий,
або який UUID належав ESP. Вони порівняли поточний вивід з базою і відразу побачили, що UUID ESP змінився після заміни диска, але fstab все ще посилається на старий.

Ремонт зайняв хвилини: змонтувати правильний ESP, оновити fstab відповідно, перевстановити GRUB, перегенерувати конфіг, перезавантажитись.
Без інструментів для розділів. Ніяких пізніх героїчних подвигів. Ніхто не вчився майнити нові навички відновлення файлів.

Жарт №2: Краща реакція на інцидент — та, де ви в основному запускаєте cat та виглядаєте легенько розчаровано.

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

1) Симптом: error: unknown filesystem в GRUB rescue

• Корінна причина: GRUB вказує на неправильний розділ, або не може завантажити модуль файлової системи в rescue-режимі.
• Виправлення: В grub rescue> використайте ls, щоб знайти розділ з /boot/grub.
  Встановіть root і prefix, insmod normal, потім завантажтесь; після цього перевстановіть GRUB з ОС.

2) Симптом: error: file '/boot/grub/i386-pc/normal.mod' not found

• Корінна причина: Legacy/BIOS GRUB очікує модулі i386-pc, але їх немає (або насправді ви використовуєте UEFI).
• Виправлення: Перевірте режим завантаження і перевстановіть GRUB з правильною ціллю. Для UEFI очікуйте x86_64-efi.

3) Симптом: Система завантажується в rescue після заміни диска, але розділи виглядають нормально

• Корінна причина: Змінився порядок завантаження прошивки; запис NVRAM UEFI відсутній або вказує на неправильний диск.
• Виправлення: Завантажте live USB в UEFI-режимі, змонтуйте ESP, запустіть UEFI grub-install, потім перевірте за допомогою efibootmgr -v.

4) Симптом: Перевстановлення GRUB «вдалося», але нічого не змінилось

• Корінна причина: Ви змонтували неправильну кореневу файлову систему (поширено при наявності декількох дисків) або не змонтували /boot//boot/efi.
• Виправлення: Використайте findmnt -R /mnt і перевірте очікуваний вміст під /mnt/boot та /mnt/boot/efi перед chroot.

5) Симптом: Після ремонту ядро завантажується, але ви потрапляєте в initramfs prompt

• Корінна причина: Несумісність UUID root, відсутні модулі LVM/crypt в initramfs або неправильні crypttab/fstab.
• Виправлення: З chroot виконайте update-initramfs -u -k all, перевірте /etc/crypttab і /etc/fstab на відповідність поточним UUID.

6) Симптом: Падає лише коли увімкнено Secure Boot

• Корінна причина: Обрано неправильний EFI-бінар (GRUB проти shim), або компоненти в ланцюжку не підписані.
• Виправлення: Перевстановіть GRUB з дефолтним шляхом shim Ubuntu і переконайтеся, що efibootmgr вказує на \EFI\ubuntu\shimx64.efi.
  Як тимчасовий діагноз, відключіть Secure Boot, щоб підтвердити гіпотезу.

7) Симптом: Rescue після зміни розміру/переміщення розділу

• Корінна причина: Невідповідність вбудованого місця/вказівників GRUB (особливо legacy BIOS) або файлову систему перемістили без перевстановлення GRUB.
• Виправлення: Перевстановіть GRUB на правильний диск і перегенеруйте конфіг. Уникайте повторних змін розміру без перезавантаження/перевірки.

8) Симптом: Rescue після конвертації MBR↔GPT або зміни налаштувань прошивки

• Корінна причина: Невідповідність методу завантаження (UEFI очікує GPT+ESP; BIOS-режим очікує код завантаження в іншому місці).
• Виправлення: Визначте один метод. Для сучасного Ubuntu 24.04 оберіть UEFI+GPT+ESP, якщо немає вагомої причини інакше.

Чеклісти / покроковий план (найменші втрати)

Фаза 0: Безпека перш за все (2 хвилини, що зекономлять години)

• Не запускайте редактори розділів, якщо не можете чітко описати проблему.
• Зробіть фото/скріншоти поточних налаштувань прошивки та списку дисків, якщо можете.
• Якщо система містить критичні дані й ви бачите I/O помилки — зупиніться і спочатку забезпечте захист даних.

Фаза 1: Визначити режим завантаження та структуру сховища

1. Завантажте live USB у потрібному режимі (UEFI або legacy). Підтвердіть за [ -d /sys/firmware/efi ].
2. Запустіть lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS і відобразіть ESP, /boot, root та будь-які шари crypto/LVM/RAID.
3. Змонтуйте root в /mnt. Змонтуйте /boot і /boot/efi, якщо вони існують.
4. Перевірте підключення за findmnt -R /mnt. Переконайтесь, що /mnt/etc і /mnt/boot містять реальні файли.

Фаза 2: Ремонт з chroot (мінімально, детерміновано)

1. Bind-mount /dev, /proc, /sys, /run в /mnt.
2. chroot /mnt.
3. Перевстановіть GRUB:
   • UEFI: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
   • BIOS: grub-install --target=i386-pc --recheck /dev/<disk>
4. Запустіть update-initramfs -u -k all і update-grub.
5. Якщо UEFI: запустіть efibootmgr -v і переконайтесь, що запис вказує на правильний шлях.

Фаза 3: Перевірити і чисто перезавантажитись

1. Вийдіть з chroot, відмонтуйте у зворотному порядку.
2. Перезавантажтеся і підтвердьте нормальне завантаження.
3. Після завантаження: запустіть journalctl -b -0 -p warning, щоб знайти залишкові проблеми з диском або монтуванням.

Коли припинити «ремонтувати» і ескалувати до відновлення сховища

• SMART показує переразподілені/очікуючі сектори на SATA, або NVMe повідомляє про media errors.
• dmesg показує повторювані I/O помилки при читанні.
• Файлова система не монтується навіть в режимі лише для читання, або fsck повідомляє про серйозні пошкодження.

На завантажувачах не варто вмирати. Якщо диск помирає, вашим пріоритетом є дані, потім відбудова.

Часті запитання

1) Чи означає grub rescue>, що мої дані зникли?

Зазвичай ні. Це найчастіше означає, що GRUB не може знайти свої модулі або конфіг. Ваша root-файлова система часто недоторкана.
Перевірте, змонтувавши розділи з live USB.

2) В чому різниця між виправленням з grub rescue> і з live USB?

В grub rescue> іноді можна завантажитись один раз, встановивши root і prefix, але це крихке.
Live USB дозволяє змонтувати встановлену систему і правильно перевстановити GRUB.

3) Я перевстановив GRUB, але все одно потрапляю в rescue. Яка найпоширеніша помилка?

Неправильний режим завантаження (UEFI vs BIOS) або неправильні підключення. «Фікс» спрацював, але на неправильне місце.
Перевірте за findmnt і чи змонтовано ESP в /boot/efi.

4) Чи варто запускати Boot-Repair або інші автоматизовані інструменти?

У критичній ситуації автоматизація може допомогти, але вона ховає рішення і може записати зміни, яких ви не хотіли.
Для мінімальних втрат у продакшні робіть ручні кроки mount → chroot → reinstall і тримайте процес детермінованим.

5) Чи може Secure Boot спричинити grub rescue>?

Так, опосередковано. Якщо ланцюжок очікує shim і підписані компоненти, а щось вказує на неправильний EFI-бінар, прошивка може відмовити в завантаженні
і ви опинитесь у поганому стані. Переконайтесь, що запис завантаження посилається на shimx64.efi в Ubuntu.

6) У мене LVM та шифрування. Чи потрібно перевстановлювати GRUB по-іншому?

Команди перевстановлення схожі, але підготовчі кроки змінюються: потрібно відкрити LUKS, активувати LVM і змонтувати правильні root/boot/ESP.
Також перебудуйте initramfs, щоб раннє середовище знало, як розблокувати і зібрати томи.

7) Чи можна виправити це без chroot?

Іноді так, але це легше зробити неправильно. Chroot дозволяє інструментам GRUB та initramfs працювати з шляхами встановленої системи,
що зменшує випадки «пофіксив live USB» замість встановленої ОС.

8) Що робити, якщо efibootmgr не показує запису ubuntu?

Перевстановіть GRUB в UEFI-режимі зі змонтованою ESP в /boot/efi. Якщо це все одно не додає запис — створіть його вручну,
але спочатку переконайтесь, що файл існує за /boot/efi/EFI/ubuntu/shimx64.efi або grubx64.efi.

9) У мого сервера декілька дисків. На який диск встановлювати GRUB?

Встановлюйте на диск, з якого прошивка завантажується. В UEFI це більше про те, який ESP і запис завантаження використовуються.
В BIOS встановлення в неправильний MBR — дуже ефективний спосіб залишитись у непрацездатному стані.

10) Після виправлення GRUB я потрапив в initramfs замість запитної сесії — чому?

GRUB передав управління ядру успішно, але ядро не може змонтувати root (невідповідність UUID, відсутні модулі crypt/LVM, неправильні fstab/crypttab).
Перевірте UUID та перегенеруйте initramfs з chroot.

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

Відновлення з grub rescue> — це здебільшого дисциплінована робота шарами: режим прошивки, схема дисків, підключення, потім перевстановлення.
Шлях із найменшими втратами також найбанальніший: виміряйте, змонтуйте правильно, chroot, перевстановіть GRUB з правильною ціллю, перегенеруйте initramfs і конфіг.

Практичні наступні кроки, які варто зробити після завантаження системи:

• Зробіть базу: lsblk -f, blkid, efibootmgr -v (UEFI), плюс /etc/fstab і /etc/crypttab.
• Визначте і задокументуйте: UEFI чи legacy BIOS. Зафіксуйте це в налаштуваннях прошивки по всьому парку.
• Уніфікуйте розмітку /boot і ESP. Узгодженість — це функція доступності.
• Регулярно перевіряйте стан дисків і налаштуйте сповіщення про I/O помилки. Завантажувачі кричать голосно, а диски винахідливо виходять з ладу.

Якщо ви ставитесь до завантаження як до продуктивного трубопроводу — трасованого, відтворюваного і не залежного від фольклору — ви рідко бачитимете grub rescue>.
А коли це станеться, ви виправите це з прямим обличчям.