Debian 13: запис UEFI зник — відновіть завантаження за допомогою efibootmgr за кілька хвилин

Що насправді зламалося, коли зник запис UEFI

UEFI-завантаження — це триопорний стілець:

1. Записи в NVRAM прошивки (змінні Boot####), що вказують на EFI-виконуваний файл на диску.
2. EFI System Partition (ESP), розділ FAT32, який містить .efi бінарники та конфігурації.
3. Ланцюжок завантажувача (часто shimx64.efi → grubx64.efi → ваше ядро).

Коли ви втрачаєте запис завантаження, зазвичай зникає тільки перша ніжка. Файли на диску зазвичай залишаються. Прошивка просто «забула», де живе Debian, або вирішила не звертати уваги.

Чому так трапляється? Типові причини включають:

• Скидання прошивки після втрати живлення, проблем з батарейкою або оновлення BIOS/UEFI.
• Сховище NVRAM переповнене або пошкоджене (так, таке трапляється).
• Інсталятор іншої ОС «дбайливо» перезаписує BootOrder.
• Деякі платформи тихо видаляють записи, що вказують на тимчасово відсутні диски (USB/NVMe hot swap, проблеми контролера RAID).
• Перемикання Secure Boot, яке змінює пріоритет шляху (shim vs прямий GRUB), і робить ваш запис «невпізнаним» для прошивки.

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

Цікаві факти та трохи історії (бо це має значення)

• UEFI замінив BIOS не просто для красивіших меню, а щоб стандартизувати завантаження поза обмеженнями 2 TB/MBR та надати програмований pre-boot середовище.
• EFI System Partition — FAT навмисно: виробникам прошивок потрібен був універсальний формат, який читається всюди без набору файлових систем.
• UEFI-записи зберігаються в NVRAM, яке зазвичай підкріплене SPI-flash на материнській платі, а не на вашому диску. Тому перевстановлення GRUB не завжди виправляє відсутній запис.
• Існує стандартизований «fallback» шлях: \EFI\BOOT\BOOTX64.EFI на x86_64. Якщо прошивка не знаходить записи, вона може спробувати цей шлях. Деякі вендори покладаються на нього більше, ніж визнають.
• Secure Boot не «захищає Linux»; він визначає, які бінарні файли можуть виконуватись у pre-boot. ОС все ще може бути неправильно налаштована або скомпрометована після завантаження. Це інструмент ланцюжка довіри, не чарівна паличка.
• efibootmgr спілкується з NVRAM через efivarfs (зазвичай змонтований в /sys/firmware/efi/efivars). Якщо ви завантажились у legacy-режимі, він не зможе керувати UEFI-змінними.
• Деякі прошивки мають маленькі квоти NVRAM, і виробники іноді зберігають журнали збоїв або діагностику в тій же області. Ваші записи завантаження можуть програти в конкуренції «корисній телеметрії».
• UEFI-екзешник GRUB не є конфігом. Конфіг зазвичай знаходиться в /boot/grub/grub.cfg у файловій системі Linux, тоді як EFI-бінарник на ESP — лише завантажувальний стендбай.
• Підписаний ланцюжок Debian зазвичай використовує shimx64.efi, щоб задовольнити Secure Boot і дозволити GRUB завантажуватись, з ключами підпису під контролем Debian замість необхідності будувати власний ланцюжок.

Швидкий план діагностики: знайдіть вузьке місце за 5 хвилин

Перше: чи ви насправді завантажені в режимі UEFI?

Якщо ви в середовищі відновлення (live ISO, PXE rescue, віддалений інженер з crash cart), підтвердіть, чи ядро бачить змінні UEFI. Якщо ні — перезавантажте rescue-носій у режимі UEFI. Нічого іншого не зафіксується.

Друге: чи є ESP і чи містить він завантажувач Debian?

Знайдіть ESP, змонтуйте його і подивіться на \EFI\debian\. Якщо файли відсутні, проблема на диску: перевстановіть grub-efi-amd64 (і можливо shim-signed) і згенеруйте заново.

Третє: чи NVRAM записуваний і не переповнений?

Якщо efibootmgr не вдається створити записи, прошивка може блокувати записи, файлову систему змінних може бути не змонтовано, Secure Boot може обмежувати оновлення змінних (рідше), або NVRAM може бути повний/пошкоджений. У такому випадку змініть тактику: використайте fallback-шлях EFI/BOOT/BOOTX64.EFI або очистіть записи NVRAM, якщо можете.

Четверте: перевірте BootOrder і фактичний шлях до пристрою

Навіть якщо ви створите запис, він може вказувати на неправильний диск/розділ, якщо ви здогадались. Підтвердіть номера диска і розділу. Потім встановіть BootOrder свідомо. «Нехай прошивка сама розбереться» — це як спостерігати, як сервер знову завантажить Windows.

Практичні завдання: команди, виводи, рішення (робочий план)

Ось завдання, які я фактично виконую. Кожне має три частини: команда, що означає її вивід, і яке рішення прийняти. Виконуйте їх з rescue-shell Debian, якщо система не завантажується. Також можна з інстальованої системи, але в сценарії зниклого запису зазвичай ви не можете завантажитись.

Завдання 1: Підтвердьте наявність режиму UEFI

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Dec 28 09:14 /sys/firmware/efi

Значення: Якщо каталог існує, ви завантажені в режимі UEFI. Якщо його немає — ви в режимі legacy/CSM.

Рішення: Якщо відсутній — перезавантажте rescue-носій і виберіть опцію UEFI в меню прошивки. Не працюйте з efibootmgr, поки цього немає.

Завдання 2: Підтвердьте, що efivarfs змонтовано (доступ до NVRAM)

cr0x@server:~$ mount | grep -E 'efivars|efi'
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Значення: efivarfs — це інтерфейс ядра до UEFI-змінних.

Рішення: Якщо не змонтовано — змонтуйте його (Завдання 3) або виправте, чому ваше rescue-ядро не підтримує це.

Завдання 3: Змонтовать efivarfs якщо потрібно

cr0x@server:~$ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
cr0x@server:~$ mount | grep efivars
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Значення: Без цього efibootmgr може показувати «EFI variables are not supported» або не зможе записувати.

Рішення: Якщо mount не вдається — можливо ви в legacy-режимі або використовуєте ядро без підтримки EFI-змінних.

Завдання 4: Перегляньте BootOrder і записи

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0001,0002
Boot0001* UEFI: Built-in EFI Shell	HD(1,GPT,8f2c0f9f-6c7f-4f84-9b8c-9f5f3b2f0b0a,0x800,0x32000)/File(\EFI\tools\Shell.efi)
Boot0002* UEFI PXEv4 (MAC:001122334455)	PciRoot(0x0)/Pci(0x1,0x1)/MAC(001122334455,0)
Boot0007* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Значення: Ви бачите, чи існує запис «debian» і на який файл він вказує.

Рішення: Якщо запис Debian відсутній — відтворіть його. Якщо він існує, але вказує на неіснуючий файл — виправте вміст ESP або скоригуйте шлях.

Завдання 5: Знайдіть EFI System Partition

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTLABEL     MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2     2G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 boot
└─nvme0n1p3 951.4G crypto_LUKS 0fc63daf-8483-4772-8e79-3d69d8477de4 root

Значення: ESP зазвичай має файлову систему vfat і GPT-тип c12a7328-f81f-11d2-ba4b-00a0c93ec93b.

Рішення: Зверніть увагу на пристрій (тут /dev/nvme0n1p1). Якщо ви не бачите ESP, можливо, ви в legacy-режимі, або розмітка диску неправильна (або у вас екзотичний вендорський апарат).

Завдання 6: Змонтйте ESP та перевірте вміст

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo find /mnt/esp/EFI -maxdepth 2 -type f -name '*.efi' | sort
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/debian/grubx64.efi
/mnt/esp/EFI/debian/shimx64.efi

Значення: Якщо ви бачите EFI-бінарники Debian, сторона диску в порядку, і ймовірно проблема в записі NVRAM.

Рішення: Якщо /mnt/esp/EFI/debian/ відсутній або порожній — потрібно перевстановити GRUB/shim на ESP.

Завдання 7: Перевірте файл завантажувача, на який вказує запис прошивки

cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/shimx64.efi && echo "shim present"
shim present
cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/grubx64.efi && echo "grub present"
grub present

Значення: Підтверджує, що конкретний файл існує. Це уникне класичної невідповідності «запис вказує на grubx64.efi, а на диску є тільки shim».

Рішення: Якщо відсутній — перевстановіть пакети і знову запустіть grub-install (Завдання 10–11).

Завдання 8: Перевірте, чи файлова система ESP не має проблем

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -n /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
...
/dev/nvme0n1p1: 12 files, 1024/130560 clusters

Значення: Прогін з -n — лише для читання. Ви перевіряєте на наявність явних пошкоджень без змін.

Рішення: Якщо повідомляє про помилки — заплануйте ремонт (видаліть -n) і очікуйте перевстановлення boot-файлів, якщо вони були пошкоджені.

Завдання 9: Перевірте логи ядра на помилки запису EFI-змінних

cr0x@server:~$ dmesg | grep -i -E 'efivars|efi:|secure|nvram' | tail -n 20
[    0.214321] efi: EFI v2.80 by American Megatrends
[    0.214322] efi: ESRT=0xb7f3c000 ACPI=0x9b5f4000 ACPI 2.0=0x9b5f4000 SMBIOS=0xb7f2e000
[    1.902114] efivars: Registered efivars operations

Значення: Ви хочете бачити нормальну ініціалізацію EFI. Якщо бачите «efivars: write error» або «no space left on device», це ваша причина.

Рішення: Якщо є помилки запису — плануйте fallback-бот або очищення записів NVRAM (Завдання 14–15).

Завдання 10: Підготуйте chroot (коли ремонтуєте з rescue)

cr0x@server:~$ sudo cryptsetup open /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:
cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ sudo mount /dev/vg0/root /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

Значення: Root вашої встановленої системи, /boot і ESP змонтовані у звичних точках для Debian.

Рішення: Якщо /boot/efi не змонтований в chroot — grub-install може записати не туди, і ви нічого не виправите.

Завдання 11: Bind-mount системні директорії та chroot

cr0x@server:~$ for d in /dev /dev/pts /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | grep -E '/boot/efi|efivars'
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/sys/firmware/efi/efivars on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Значення: Chroot бачить реальний ESP і efivars. Добре. Ви працюєте з реальним станом системи.

Рішення: Якщо efivars не видно в chroot — bind-mount /sys коректно та підтвердіть, що rescue-середовище завантажене у режимі UEFI.

Завдання 12: Перевстановіть UEFI-пакети Debian (підписаний ланцюжок)

cr0x@server:/# apt-get update
Hit:1 cdrom://Debian GNU/Linux 13.0.0 _Trixie_ - Official amd64 NETINST 20251201-10:22  trixie InRelease
Reading package lists... Done
cr0x@server:/# apt-get install --reinstall grub-efi-amd64 shim-signed
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded.
Setting up shim-signed (1.60+15.8-1) ...
Setting up grub-efi-amd64 (2.12-2) ...

Значення: Ви відновлюєте відомі робочі EFI-бінарники та скрипти. Пакети Debian зазвичай також запускають потрібні postinst кроки.

Рішення: Якщо Secure Boot вимкнений і ви не хочете shim — можна його пропустити. Але в змішаних парках перевстановлення shim уникатиме сюрпризів надалі.

Жарт #1: NVRAM UEFI — як крихітна шафа: все вміщається, поки не з’явиться ще одне пальто, а потім ніщо не влазить і всі звинувачують пальто.

Завдання 13: Запустіть grub-install явно (коли пакетів недостатньо)

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

Значення: Це записує завантажувач на ESP у /boot/efi/EFI/debian/, і може також створити NVRAM-запис.

Рішення: Якщо помилка «cannot find EFI directory» — ваш ESP не змонтований там, де ви думаєте. Зупиніться і виправте монтування.

Завдання 14: Перегенеруйте конфіг GRUB (для впевненості)

cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done

Значення: Це підтверджує, що встановлена система бачить ядра і може згенерувати коректне меню.

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

Завдання 15: Створіть (або відновіть) UEFI-запис за допомогою efibootmgr

cr0x@server:/# efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
BootCurrent: 0007
BootOrder: 0007,0001,0002
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Значення: Це записує нову змінну Boot####, що вказує на завантажувач. Зверніть увагу на диск (-d) і номер розділу (-p) — це ключове.

Рішення: Якщо вдалось, встановіть BootOrder, щоб віддати йому пріоритет (Завдання 16). Якщо помилка «No space left on device» — переходьте до очищення NVRAM або fallback-бота (далі).

Завдання 16: Поставте Debian першим у BootOrder (будь впевненим)

cr0x@server:/# efibootmgr
BootCurrent: 0007
BootOrder: 0007,0001,0002,0008
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)
cr0x@server:/# efibootmgr -o 0008,0007,0001,0002
BootOrder: 0008,0007,0001,0002

Значення: Ви явно встановлюєте порядок завантаження. Інакше прошивка може продовжувати завантажувати PXE чи оболонку першою.

Рішення: Завжди встановлюйте BootOrder свідомо на серверах. Людинозручні меню завантаження — не стратегія надійності.

Завдання 17: Тимчасово завантажтесь у новий запис (безпечний тест)

cr0x@server:/# efibootmgr -n 0008
BootNext: 0008

Значення: BootNext встановлює одноразовий завантажувальний запис. Це низькоризиковий спосіб протестувати без постійних змін.

Рішення: Використовуйте BootNext, коли ви віддалено і хочете, щоб система повернулась до відомого дефолту, якщо зміни не спрацюють.

Завдання 18: Перевірте наявність fallback-завантажувача (страховка)

cr0x@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 09:26 /boot/efi/EFI/BOOT/BOOTX64.EFI

Значення: Деякі платформи завантажують цей файл автоматично, коли записи NVRAM відсутні. Інші — ні. Але мати його корисно при імпровізації.

Рішення: Якщо відсутній — подумайте про його створення (секція fallback) після відновлення основного запису.

Завдання 19: Коректно вийдіть з chroot і перезавантажтесь

cr0x@server:/# exit
cr0x@server:~$ sudo umount -R /mnt
cr0x@server:~$ sudo reboot

Значення: Ви скидаєте змонтовані файлові системи і уникнете «брудного» стану. Особливо важливо після fsck або зміни ESP.

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

Відтворення UEFI-запису Debian за допомогою efibootmgr (хірургічне виправлення)

Найважливіша команда:

• -c створити новий запис
• -d диск (не розділ)
• -p номер розділу ESP на цьому диску
• -L мітка, що відображається в меню прошивки
• -l шлях до завантажувача всередині ESP, використовуючи зворотні слеші й абсолютний шлях від кореня ESP

Два підходи, які я використовую:

Шаблон A: Сумісно з Secure Boot (shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
Boot0009* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Коли використовувати: Secure Boot увімкнений, або ви не контролюєте політику парку і хочете запис, що працюватиме незалежно від неї.

Шаблон B: Прямий GRUB (без shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian (grub)" -l '\EFI\debian\grubx64.efi'
Boot0010* debian (grub)	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\grubx64.efi)

Коли використовувати: Secure Boot вимкнений, і ви хочете найпростіший ланцюжок. Також корисно для налагодження проблем, пов’язаних зі shim.

Коли efibootmgr «працює», але завантаження все одно не вдається

UEFI-записи можуть виглядати коректно, але бути неправильними. Прошивка зберігає шлях пристрою, який включає GUID розділу GPT. Якщо ви клонуєте диски, відновлюєте образи або міняєте апарат, GUID може змінитися. Іноді записи продовжують вказувати на старий GUID і стають мертвими.

На практиці: якщо ваш запис показує шлях HD() з GUID, що не відповідає PARTUUID поточного ESP — відтворіть його за допомогою efibootmgr замість спроби редагувати.

Цитата, яку варто пам’ятати

Paraphrased idea: Gene Kranz наголошував, що в реагуванні на збої треба зберігати спокій, системно працювати над проблемою і уникати панічних імпровізацій.

Використання fallback-шляху: BOOTX64.EFI (коли NVRAM ворожий)

Іноді NVRAM не зберігає записи. Ви створюєте запис, перезавантажуєтесь, і він зникає, ніби ви зробили щось незаконне. Або efibootmgr повертає «No space left on device». Або платформа блокує записи змінних, якщо не використовувати вендорські інструменти.

Тут у пригоді виявляється fallback-шлях UEFI: \EFI\BOOT\BOOTX64.EFI для x86_64. Багато прошивок завантажать його, коли записи відсутні, або ви можете вручну вибрати опцію «UEFI: <пристрій>» і прошивка підхопить fallback.

Зробіть Debian завантажуваним через fallback

Якщо на ESP вже є shim Debian, скопіюйте його у fallback-розташування. Віддавайте перевагу shim, коли Secure Boot може бути увімкнений.

cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo mkdir -p /mnt/esp/EFI/BOOT
cr0x@server:~$ sudo cp -a /mnt/esp/EFI/debian/shimx64.efi /mnt/esp/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo sync
cr0x@server:~$ sudo ls -l /mnt/esp/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 10:11 /mnt/esp/EFI/BOOT/BOOTX64.EFI

Значення: Тепер у вас є fallback-завантажувач, навіть якщо NVRAM очищують.

Рішення: Використовуйте це, коли підозрюєте, що прошивка видаляє записи, коли NVRAM переповнений, або коли ви на віддаленому сайті і хочете просту страховку, яка дозволить машині завантажитись.

А що з конфігурацією при використанні fallback?

Shim/GRUB все ще має знайти конфіг GRUB і файлову систему Linux. Debian-ский GRUB зазвичай містить логіку для пошуку /boot/grub. Якщо у вас екзотична розкладка (mdadm, LUKS, кілька ESP) — тестуйте. Не робіть припущень.

Жарт #2: Fallback-шлях UEFI — як сховати запасний ключ під килимок, тільки килимок стандартизований комітетом.

Реальність Secure Boot: shim, підписаний GRUB і як уникнути самостійних проблем

Secure Boot змінює моди відмов. При увімкненому Secure Boot:

• Прошивка виконуватиме тільки ті EFI-бінарники, які підписані довіреними ключами.
• Debian зазвичай використовує shimx64.efi, підписаний таким чином, щоб прошивка його приймала (через загальні довірчі корені), потім shim перевіряє GRUB.
• Якщо вказати запис прямо на непідписаний grubx64.efi, ви отримаєте негайний відмовний стан, який виглядає як «не завантажилось» без логів.

Практичні поради:

• Якщо ви не знаєте стан Secure Boot — вважайте, що він може бути увімкнений. Створіть запис, що вказує на shim. Це найменше драматичний варіант за замовчуванням.
• Не переключайте Secure Boot як «швидке виправлення». Це не виправлення, а зміна політики. Це також може поламати інші хости, якщо ви ставитесь до цього як до звичайної опції перезавантаження.
• Тримайте ESP читабельним і простим. Дехто намагається «оптимізувати» шляхом стиснення або дедуплікації вмісту ESP (за допомогою дивних інструментів). Не треба. Це FAT32. Нехай він буде FAT32.

Три корпоративні міні-історії з поля бою завантаження

Міні-історія 1: Інцидент через неправильне припущення

Команда мала невеликий парк Debian-серверів, які завантажувались з дзеркальних NVMe. Запланували оновлення прошивки материнських плат в вікні техобслуговування. Усе здавалося рутинним: патч, перезавантаження, перевірка сервісів, додому.

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

Справжня проблема: оновлення прошивки скинуло NVRAM і також змінило преференції режиму завантаження. Сервери тепер віддавали перевагу PXE та shell-записам, а запис Debian зник. Перевстановлення GRUB записало файли на ESP коректно, але ніхто не відтворив NVRAM-запис або не виправив BootOrder.

Коли хтось нарешті запустив efibootmgr -v і подивився — рішення було тривіальне: створити запис на shim і встановити BootOrder. Урок не в тому, що оновлення прошивки — погане. Урок: не робіть припущень «завантажувач пошкоджено», якщо система навіть не намагається його завантажити.

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

Інша організація захотіла «чистіші boot-розділи». Вони стандартизували образи і обрізали ESP до мінімуму: один завантажувач, один вендорський каталог, без зайвого. Також автоматизація агресивно видаляла «непотрібні» UEFI-записи під час провізії, бо деякі машини приходили з купою заводської діагностики.

Потім вони додали робочі станції з dual-boot у ту саму автоматизацію. Один скрипт, який повторно використовувався, видаляв усе, що не було точно міткою «debian» і перевпорядковував BootOrder. На папері акуратно. Насправді — робочі станції мали Windows з BitLocker, який потребував стабільного запису завантаження.

Наступне оновлення Windows переписало свій запис і BootOrder (як це часто буває). Автоматизація запустилась, видалила його і знову впорядкувала. Windows recovery спрацював, користувачі звернулись у службу підтримки, а платформа отримала тижневий нагадувач, що «стандартизація» не означає «видаляти те, чого не розумієш».

Вони виправили це, зробивши скрипт усвідомленим щодо ролей платформ, залишаючи записи інших ОС недоторканими, якщо не вказано явно, і покладаючись більше на fallback-шлях як запобіжний клапан замість намагання нав’язати єдиний ідеальний BootOrder скрізь.

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

Один банк мав політику: кожен сервер з UEFI повинен мати і правильний NVRAM-запис, і підтримуваний fallback-завантажувач у \EFI\BOOT\BOOTX64.EFI. Також ESP входив у процедури бекапу/відновлення, хоча він маленький і здається «несерйозним».

На сайті були проблеми з електропостачанням. Кілька систем повернулись із очищеними записами NVRAM. Зазвичай це стає ковзким ланцюгом: віддалені інженери, консолі, вручну налаштування. Але тут хости завантажились через fallback, shim підняв GRUB, і ОС спрацювала. Додатки навіть не помітили. Квиток інциденту був майже антикліматичним.

Пізніше команда відтворила записи NVRAM у світлу пору доби і знайшла корінь проблеми (прошивка плюс нестабільне живлення). Але негайний бізнес-результат був нудним: сервіси працювали. Нудьга — це мета.

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

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

1) Симптом: efibootmgr каже «EFI variables are not supported»

Корінна причина: Ви завантажили rescue середовище в legacy/CSM режимі, або efivarfs недоступний.

Виправлення: Перезавантажте rescue-носій в режимі UEFI (Завдання 1). Переконайтесь, що efivarfs змонтовано (Завдання 2–3).

2) Симптом: запис Debian існує, але система все одно заходить в налаштування прошивки

Корінна причина: BootOrder не включає його, або він стоїть після PXE/shell, або прошивка пропускає його через невдалу спробу.

Виправлення: Встановіть BootOrder явно (Завдання 16). Використайте BootNext для тесту (Завдання 17).

3) Симптом: запис Debian вказує на grubx64.efi, але Secure Boot увімкнений і він не стартує

Корінна причина: Прошивка відмовляється запускати непідписаний завантажувач.

Виправлення: Вкажіть запис на \EFI\debian\shimx64.efi (Завдання 15, Шаблон A). Перевстановіть shim-signed, якщо потрібно (Завдання 12).

4) Симптом: створення efibootmgr зазнає невдачі з «No space left on device»

Корінна причина: Сховище змінних NVRAM переповнене.

Виправлення: Видаліть застарілі записи (efibootmgr -b #### -B) і спробуйте знову, або використайте fallback-шлях (секція fallback), якщо записи не фіксуються.

5) Симптом: efibootmgr працює, але запис зникає після перезавантаження

Корінна причина: Баг прошивки, захист від запису, або скидання налаштувань (іноді через сідаючу батарейку CMOS або агресивні «restore defaults»).

Виправлення: Використовуйте fallback-шлях BOOTX64.EFI для стійкості і заплануйте апаратне/прошивкове виправлення. Якщо можливо — оновіть прошивку знову або вимкніть «OS optimized defaults», що видаляють записи.

6) Симптом: GRUB стартує, але ядро не знайдено / падає в rescue

Корінна причина: Це не проблема зниклого UEFI-запису. Це проблема конфігурації Linux або зберігання: неправильний root UUID, відсутній /boot, некоректна збірка LUKS/mdadm.

Виправлення: Перевірте монтування в chroot (Завдання 10–11), запустіть update-grub (Завдання 14), переконайтесь, що initramfs має потрібні модулі, і перевірте /etc/fstab та crypttab.

7) Симптом: запис вказує на правильний файл, файл існує, але все одно не завантажується

Корінна причина: ESP знаходиться на диску, який прошивка не може прочитати (зміна режиму контролера, перенумерація RAID, зміни NVMe namespace), або запис посилається на застарілий GUID після клонування.

Виправлення: Створіть запис заново з правильним диском і розділом (Завдання 15). Якщо режим контролера змінився (AHCI/RAID) — поверніть або налаштуйте прошивку, щоб вона бачила ESP у цьому режимі.

Чеклісти / покроковий план (нудно, швидко, відтворювано)

Чекліст A: Є консольний доступ і rescue ISO

1. Завантажте rescue ISO в UEFI режимі (підтверджуйте Завдання 1).
2. Змонтйте efivarfs, якщо потрібно (Завдання 2–3).
3. Огляньте записи NVRAM (Завдання 4). Вирішіть, чи запис Debian відсутній або неправильний.
4. Знайдіть і змонтуйте ESP (Завдання 5–6). Підтвердіть наявність файлів завантажувача (Завдання 7).
5. Якщо файлів немає — chroot і перевстановіть (Завдання 10–14).
6. Створіть або відтворіть запис завантаження (Завдання 15).
7. Встановіть BootOrder (Завдання 16). Опціонально встановіть BootNext для тесту (Завдання 17).
8. Перезавантажтесь і спостерігайте.

Чекліст B: NVRAM переповнений або прошивка продовжує забувати

1. Переконайтесь, що ESP містить shim/grub Debian (Завдання 6–7).
2. Створіть fallback-завантажувач у \EFI\BOOT\BOOTX64.EFI (секція fallback).
3. Спробуйте чистку NVRAM лише якщо можете робити це безпечно (видаліть очевидно застарілі PXE або інсталяторські записи).
4. Заплануйте ремонт прошивки: оновлення, обережний скидання, заміну батарейки CMOS якщо потрібно, і задокументуйте поведінку.

Чекліст C: Dual-boot або кілька Linux інсталяцій

1. Не видаляйте записи навмання. Спочатку перелічіть їх (Завдання 4) і зіставте кожен з шляхом на ESP.
2. Використовуйте явні мітки: debian-prod, debian-rescue, windows.
3. Віддавайте перевагу shim-орієнтованим записам, якщо Secure Boot може використовуватися будь-якою ОС.
4. Тримайте fallback-завантажувач, що завантажує вашу основну ОС, а не інсталятор.

FAQ

1) Чому взагалі може зникнути UEFI-запис?

Тому що він зберігається в NVRAM на материнській платі, а не на диску. Оновлення прошивки, скидання, проблеми з живленням або квоти NVRAM можуть стерти або обрізати записи.

2) Якщо ESP цілий, чому машина не знаходить його автоматично?

UEFI зазвичай не «сканує і не вгадує» як старий BIOS. Воно слідує записам BootOrder. Деякі прошивки пробують fallback-шляхи, але не надійтесь на це, поки не налаштуєте його.

3) Чи потрібен efibootmgr або можна просто перевстановити GRUB?

Перевстановлення GRUB виправляє файли на диску. efibootmgr виправляє вказівники в NVRAM. Коли запис зник, зазвичай потрібен efibootmgr (або fallback-бот), щоб відновити вказівник.

4) Який правильний формат шляху завантажувача в efibootmgr?

Використовуйте шлях всередині ESP з зворотними слешами, наприклад \EFI\debian\shimx64.efi. Не використовуйте Linux-шляхи на кшталт /boot/efi/... для параметра -l.

5) Куди вказувати: shim чи grub?

Якщо Secure Boot увімкнений (або може бути увімкнений пізніше), вказуйте shimx64.efi. Якщо ви впевнені, що Secure Boot вимкнений і таким залишиться — прямий GRUB підходить.

6) Система завантажується після встановлення BootNext, але не після звичайного перезавантаження. Чому?

BootNext — це одноразове переваження. Ваш постійний BootOrder досі віддає перевагу іншому пункту (PXE, shell, інший диск). Виправте BootOrder (Завдання 16).

7) efibootmgr може перерахувати записи, але не може їх створити. В чому річ?

Читання змінних може працювати, тоді як запис не вдається, особливо при перевантаженні квоти NVRAM або обмеженнях прошивки. Перевірте логи (Завдання 9) і розгляньте fallback-бот, якщо записи не фіксуються.

8) Чи безпечно видаляти старі записи Boot####, щоб звільнити NVRAM?

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

9) Що робити, якщо є кілька ESP?

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

10) Чи замінює копіювання shim у BOOTX64.EFI потребу в NVRAM-записах?

Часто це працює як страховка, але залежить від прошивки. Розглядайте це як додаткову стійкість, а не як заміну коректних NVRAM-записів.

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

Якщо ваш UEFI-запис Debian 13 зник, найшвидше надійне виправлення — не гадання. Це короткий цикл дій:

1. Завантажтесь в UEFI режимі, підтвердіть роботу efivars.
2. Змонтйте ESP і перевірте наявність файлів завантажувача.
3. Перевстановіть shim/GRUB тільки якщо файли відсутні.
4. Відтворіть NVRAM-запис через efibootmgr, потім встановіть BootOrder.
5. Додайте fallback-завантажувач у \EFI\BOOT\BOOTX64.EFI, якщо платформа має історію «забування».

Зробіть ще одну річ після відновлення: запишіть точну команду efibootmgr, яка спрацювала для цієї моделі апаратури, включно з диском і розділом. Майбутній ви подякує вам, а призначити поточному вам зустріч нелегко.