Debian 13: Сервер не завантажується після оновлень — чистий відкат GRUB, який справді працює

November 26, 2025 • February 3, 2026 • Читання: 15 хв • Views: 14

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

Ваш maintenance window закінчився 20 хвилин тому. Сервер досі «падіння». Консоль гіпервізора показує ввічливий grub rescue> prompt, якому байдуже на ваш SLA. А хтось у Slack набирає «did we brick it?» з упевненістю людини, яка ніколи нічого не відновлювала.

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

Fast diagnosis playbook (what to check 1st/2nd/3rd)

Збої завантаження після оновлень рідко містять «містику». Зазвичай це одна з чотирьох категорій: невірний пристрій/EFI запис, зламана GRUB core/config, відсутні kernel/initramfs або проблеми зі збиранням/розблокуванням сховища (LUKS/RAID/ZFS). Ваше завдання — визначити категорію за хвилини, не години.

First: identify the failure stage by the exact screen

UEFI firmware screen loops back to BIOS/UEFI menu: firmware не може знайти boot entry або EFI бінарник відсутній/нерозбірливий.
grub rescue>: GRUB завантажився, але не може знайти свої модулі або конфіг; часто prefix вказує неправильно або файлову систему переміщено.
grub> (full prompt): GRUB функціональний; ймовірно може завантажити kernel, якщо вказати правильний розділ.
Kernel loads then drops to initramfs: initramfs не може знайти root (UUID не збігається, відсутній драйвер, prompt LUKS не з’являється, mdraid не збирається).
Kernel panic immediately after update: неправильне ядро, зламаний initramfs або регресія в драйвері; відкат ядра зазвичай найшвидший.

Second: collect one hard fact: what disk and what boot mode

Перед тим як «ліпити» виправлення, вирішіть: UEFI чи legacy BIOS? NVMe чи SATA? mdraid/LUKS/ZFS? Якщо ви гадаєте, під навантаженням ви помилитесь.

Third: decide the lowest-risk recovery route

If you can reach GRUB menu: завантажте попереднє ядро. Це найменш інвазивний відкат.
If you can reach a rescue environment: змонтуйте, chroot, чисто переінсталюйте GRUB, згенеруйте initramfs і перевірте вільне місце на /boot.
If disks aren’t assembling/unlocking: виправте mdadm/LUKS спочатку; переінсталяція GRUB на диск, який система не читає, — мистецтво перформансу.

Operational rule: не записуйте на диски, поки не зможете пояснити, що саме і куди пишете. Найшвидший шлях перетворити інцидент завантаження в інцидент відновлення даних — це «просто запустити grub-install скрізь».

Why Debian “won’t boot after updates” happens (and what’s actually broken)

Оновлення Debian зачіпають критичні для завантаження частини таким чином, що вони й водночас суворі. Пакети зазвичай роблять правильно — доки ваша конфігурація трохи незвична, /boot тісний, firmware вибагливий або ви використовуєте стеки сховища, які потребують раннього userspace.

Звичайні тригери:

GRUB package update wrote new core files але ваш EFI System Partition (ESP) не був змонтований. Оновлення «успішне», але firmware усе ще завантажує старий бінарник.
/boot filled up тому генерація kernel або initramfs була частковою. У вас тепер пункт у меню GRUB вказує на kernel, який існує, але initramfs відсутній — або навпаки.
Disk IDs/UUIDs changed (клонування, заміна диска, RAID reshaping). GRUB конфіг посилається на старі UUID, тому не може знайти /boot/grub або kernel.
UEFI NVRAM boot entries got reset (оновлення firmware, скидання CMOS, vendor firmware сам по собі). Диск може бути цілим; firmware просто забуло, як його знайти.
Initramfs lost a needed driver or hook (особливо з mdraid, LUKS, екзотичні HBA або ZFS-on-root). Kernel завантажився, але ранній userspace не може знайти root.
Secure Boot interactions: shim, підписаний GRUB або підписи kernel не збігаються з очікуванням firmware. Симптоми — від тихої відмови до короткого мерехтіння та перезавантаження.

Якщо шукати єдиного винуватця, зазвичай це не «GRUB винний». Це «ланцюг опіки за артефактами завантаження плутаний». Ваш відкат має відновити ланцюг, а не додавати випадкові копії grubx64.efi у дивні місця.

Interesting facts and a little bootloader history

GRUB’s name is literal: він починався як «GRand Unified Bootloader» під проєктом GNU, щоб упорядкувати хаос ранніх PC boot manager-ів.
BIOS-era GRUB used multi-stage loading (stage1 в MBR, stage1.5 у «MBR gap», stage2 у /boot). GPT і сучасні інструменти зробили «gap» ненадійним, що підштовхнуло до використання BIOS Boot Partition.
UEFI changed the game: bootloader-и стали звичайними файлами на FAT-подібному ESP, що простіше, але крихкіше (легко перезаписати, легко забути змонтувати).
The “fallback” UEFI path exists for a reason: \EFI\BOOT\BOOTX64.EFI — це шлях за замовчуванням, який багато firmware пробують, коли NVRAM entries відсутні або пошкоджені.
Debian’s kernel packaging is conservative порівняно з деякими дистрибутивами: старі ядра зберігаються навмисно, тому часто можна відкотитися, вибравши старіший запис — якщо тільки /boot не вичерпано.
Initramfs is not optional theater: для зашифрованого root, RAID або багатьох драйверів сховища це ранній userspace, який збирає середовище перед тим, як /sbin/init отримає контроль.
“update-grub” is a friendly wrapper навколо grub-mkconfig. Важливе — згенерований конфіг і модулі, які GRUB справді може завантажити.
UEFI NVRAM is finite і реалізації firmware вендорів дуже різняться. Системи можуть і забувають boot entries під час оновлень firmware або коли NVRAM заповнюється.

Цитата, яка варта запам’ятати, приписується Werner Vogels: «Everything fails, all the time.» Це не нігілізм; це вимога до дизайну.

On-console triage: GRUB screen types and what they mean

Case A: “No bootable device” or firmware drops into setup

Зазвичай firmware не знаходить EFI loader (UEFI) або бракує boot code (legacy BIOS). ОС може бути цілою. Ваше завдання — відновити валідний шлях завантаження.

Case B: `grub rescue>`

GRUB працює в скороченому режимі. Він не знаходить звичайні модулі/конфіг. Типові причини: неправильний prefix, переміщені розділи, відсутній /boot/grub або файлову систему, яку GRUB не читає (рідше на Debian defaults, частіше з екзотичними FS).

Case C: GRUB menu appears, kernel loads, then you land in initramfs

GRUB зробив свою частину. Тепер initramfs не може змонтувати root filesystem. Звичайні причини: неправильний root UUID у kernel cmdline, незібраний mdraid, не розблокований LUKS-device, відсутній модуль драйвера або регресія. Це часто виглядає як «Debian не завантажується», але GRUB тут ні при чому.

Joke #1: GRUB — як швейцар: виглядає страшно, але здебільшого просто контролює список, який ви йому дали.

The clean GRUB rollback that actually works

«Відкат» у світі bootloader-ів — це не одна кнопка. Потрібен відомий робочий набір артефактів: GRUB бінарник, який firmware може завантажити, модулі GRUB там, де GRUB їх чекає, і конфіг, що вказує на реальні kernel та initramfs. Отримати це можна двома чистими способами:

Soft rollback (preferred when possible): завантажте старіше ядро з меню «Advanced options». Потім у робочій системі перебудуйте initramfs і GRUB config, і лише при потребі переінсталюйте bootloader.
Hard rollback (when it won’t boot at all): завантажте rescue environment, змонтуйте файлові системи, chroot, чисто переінсталюйте GRUB на правильну ціль (UEFI або BIOS), перебудуйте initramfs і GRUB config, перевірте EFI entries.

Чого уникати: копіювання випадкових EFI бінарників без розуміння, який саме використовує firmware; переінсталяція GRUB на всі диски «на всяк випадок»; або ручне редагування grub.cfg як у 2004 році. Debian його перезапише пізніше, і ви забудете, що правили, а майбутній ви заслуговуватиме кращого.

Recovery environment choice

Використовуйте те, що найближче до системи: Debian installer у rescue mode, live image або remote rescue system вашого дата-центру. Головне — змонтувати встановлений root filesystem і виконувати Debian інструменти проти нього.

Decide boot mode: UEFI vs BIOS

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

What “clean” means for GRUB

UEFI: правильний ESP змонтовано в /boot/efi у chroot, встановлено grub-efi-amd64 (або arm64-еквівалент), ви запускаєте grub-install один раз з правильним --efi-directory, і підтверджуєте, що NVRAM entry (або fallback file) існує.
BIOS: встановлюєте grub-pc, запускаєте grub-install /dev/sdX на правильний диск(и), не на розділ(и), і перевіряєте, що BIOS Boot Partition існує на GPT якщо потрібно.

Practical tasks: commands, expected output, and the decision you make

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

Task 1: Confirm whether you’re booted in UEFI mode (in rescue/live)

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

Meaning: directory exists → you are currently booted in UEFI mode. If it’s missing, you’re in legacy BIOS/CSM mode.

Decision: match the installed system’s boot mode. If the server was installed UEFI but your rescue boot is BIOS, reinstalling UEFI GRUB may fail or install the wrong thing.

Task 2: Inventory disks/partitions and spot the ESP and /boot

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,FSVER,LABEL,PARTLABEL,PARTUUID,MOUNTPOINTS
NAME        SIZE FSTYPE FSVER LABEL PARTLABEL        PARTUUID                             MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   FAT32       EFI System     7c2f2d6a-7f0a-4d6b-8a8d-1a2d2b8c0c1e
├─nvme0n1p2     2G ext4         boot  Linux filesystem 1b2c3d4e-...                      
└─nvme0n1p3 951.4G crypto_LUKS        luks  Linux filesystem 9a8b7c6d-...

Meaning: look for vfat with “EFI System” → that’s your ESP. Look for ext4 labeled boot → likely /boot.

Decision: you now know what to mount where. If you don’t see an ESP on a UEFI system, you may be looking at the wrong disk or the ESP is missing/corrupt.

Task 3: If using LUKS, unlock root (or the container that contains root)

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

cr0x@server:~$ ls /dev/mapper/cryptroot
/dev/mapper/cryptroot

Meaning: the mapping exists → decrypted block device is available.

Decision: proceed to mount LVM or filesystems inside it. If unlock fails, stop and fix keys/TPM/prompting first—bootloader work won’t help.

Task 4: If using LVM inside LUKS, activate volume groups

cr0x@server:~$ vgscan
  Found volume group "vg0" using metadata type lvm2

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

Meaning: LVs are active and will show up under /dev/vg0/....

Decision: mount the root LV. If VGs don’t show, you might be missing the right device mapper nodes, or you’re unlocking the wrong container.

Task 5: Mount the installed system (root, /boot, ESP) correctly

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

Meaning: all expected mountpoints are present. This is where many “reinstall GRUB” attempts go wrong: the ESP wasn’t mounted, so the new EFI binary went into a directory on the root filesystem, not into firmware-readable FAT.

Decision: if /mnt/boot/efi isn’t vfat, fix your mounts before touching GRUB.

Task 6: Bind-mount runtime filesystems and chroot

cr0x@server:~$ mount --bind /dev /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys /mnt/sys
cr0x@server:~$ chroot /mnt /bin/bash
root@server:/#

Meaning: you’re now operating as if booted into the installed OS, using its packages and configs.

Decision: all remediation should now use Debian’s tooling from inside this chroot.

Task 7: Check for a half-configured dpkg state (common after interrupted updates)

root@server:/# dpkg --audit
The following packages are only half configured, probably due to problems configuring them the first time.
 grub-efi-amd64
 linux-image-6.12.0-amd64

Meaning: packaging state is inconsistent. This can leave GRUB files missing or kernel artifacts incomplete.

Decision: run recovery steps for dpkg before reinstalling bootloader.

Task 8: Finish interrupted package configuration cleanly

root@server:/# apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-6.12.0-amd64 (6.12.18-1) ...
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64
Setting up grub-efi-amd64 (2.12-5) ...

Meaning: initramfs generation and GRUB package configuration ran. Watch for errors about /boot being full or ESP not mounted.

Decision: if errors appear, address them immediately (space, mounts) before continuing.

Task 9: Check `/boot` space (this one bites constantly)

root@server:/# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  2.0G  1.9G   42M  98% /boot

Meaning: /boot is effectively full. Kernel updates may have left partial images or refused to install new ones cleanly.

Decision: remove old kernels properly (not by deleting random files) before regenerating initramfs/GRUB config.

Task 10: List installed kernels and remove stale ones safely

root@server:/# dpkg -l 'linux-image-*' | awk '/^ii/ {print $2 "\t" $3}'
linux-image-6.10.0-amd64	6.10.12-1
linux-image-6.12.0-amd64	6.12.18-1
linux-image-amd64	6.12.18-1

root@server:/# apt-get remove --purge linux-image-6.10.0-amd64
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  linux-image-6.10.0-amd64*
After this operation, 412 MB disk space will be freed.
Removing linux-image-6.10.0-amd64 (6.10.12-1) ...
update-initramfs: Deleting /boot/initrd.img-6.10.0-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 6.10.0-amd64 /boot/vmlinuz-6.10.0-amd64
Generating grub configuration file ...
done

Meaning: space reclaimed and GRUB config updated as part of kernel removal hooks.

Decision: re-check /boot space; you want headroom for at least one new kernel + initramfs.

Task 11: Regenerate initramfs for the kernel you intend to boot

root@server:/# update-initramfs -u -k 6.12.0-amd64
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Meaning: initramfs exists and was rebuilt with current hooks/modules.

Decision: if this errors, fix it before touching GRUB. A perfect bootloader pointing to a broken initramfs still won’t boot.

Task 12: Verify the root filesystem UUIDs match what the system expects

root@server:/# blkid /dev/vg0/root
/dev/vg0/root: UUID="f3a1f9e4-7d72-4d88-8c7f-2b1b9d1a0d4c" BLOCK_SIZE="4096" TYPE="ext4"

root@server:/# grep -E '^\s*UUID=|^\s*/dev/' /etc/fstab
UUID=f3a1f9e4-7d72-4d88-8c7f-2b1b9d1a0d4c / ext4 defaults 0 1
UUID=2D3A-11F0 /boot/efi vfat umask=0077 0 1

Meaning: fstab references current UUIDs. If they mismatch, boot can fail in initramfs or later.

Decision: if UUIDs are wrong, fix /etc/fstab and any crypttab/mdadm references before rebuilding initramfs again.

Task 13: Generate a fresh GRUB config (don’t hand-edit grub.cfg)

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

Meaning: GRUB sees the kernel and initramfs in /boot. If it says it found no kernels, your /boot isn’t mounted, or kernels are missing, or the scripts aren’t seeing them.

Decision: only proceed to reinstall GRUB when update-grub produces sane output.

Task 14: Reinstall GRUB for UEFI cleanly (the common Debian 13 server case)

root@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.

Meaning: the EFI binary was written to the mounted ESP in the expected directory tree. No error is good; but you still need to verify that firmware entries exist and the files are actually on the ESP.

Decision: check NVRAM boot entries and ESP contents next.

Task 15: Check UEFI NVRAM boot entries and confirm Debian is present

root@server:/# efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0003* debian	HD(1,GPT,7c2f2d6a-7f0a-4d6b-8a8d-1a2d2b8c0c1e,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0001* UEFI: Built-in EFI Shell
Boot0000* UEFI PXEv4

Meaning: firmware knows about \EFI\debian\grubx64.efi and it’s in BootOrder.

Decision: if the entry is missing or points to the wrong disk GUID, create/fix it, or put a fallback binary in the default path as a pragmatic backup.

Task 16: Verify ESP file layout (because “mounted” isn’t “correct”)

root@server:/# ls -R /boot/efi/EFI
/boot/efi/EFI:
BOOT  debian

/boot/efi/EFI/BOOT:
BOOTX64.EFI

/boot/efi/EFI/debian:
grubx64.efi  grub.cfg

Meaning: both vendor-neutral fallback and Debian entry exist. On servers with flaky NVRAM, that fallback file is a quiet hero.

Decision: if /boot/efi/EFI is empty, you installed to the wrong place or the ESP isn’t mounted. Stop and correct it.

Task 17: Reinstall GRUB for legacy BIOS (only if that’s your system)

root@server:/# grub-install --target=i386-pc --recheck /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Meaning: GRUB core written to the disk’s boot area. On GPT/BIOS, you also need a BIOS Boot Partition; without it, installs can “succeed” but not boot reliably.

Decision: if you’re on GPT and don’t have a BIOS boot partition, reconsider: switching to UEFI is often cleaner on modern servers.

Task 18: Last-mile sanity check: what kernel cmdline will be used

root@server:/# cat /etc/default/grub | sed -n 's/^GRUB_CMDLINE_LINUX_DEFAULT=//p'
"quiet"

root@server:/# cat /etc/default/grub | sed -n 's/^GRUB_CMDLINE_LINUX=//p'
""

Meaning: if you require special parameters (mdraid, cryptdevice, rootdelay, console=ttyS0), this is where persistent config lives. Don’t jam it into grub.cfg.

Decision: if you’re remote-only, set serial console params now, regenerate GRUB config, and spare yourself the next blind incident.

Task 19: Exit chroot, unmount cleanly, reboot

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

Meaning: clean unmount reduces filesystem surprises. Reboot tests the full chain: firmware → GRUB → kernel → initramfs → root.

Decision: if it still fails, capture the exact new failure stage; don’t repeat the same fix hoping for different physics.

Joke #2: Rebooting is not a fix. It’s a vote. Sometimes it votes for “still broken.”

Three corporate mini-stories (how this fails in production)

Mini-story 1: The incident caused by a wrong assumption

Вони оперували флотом Debian серверів у приватному хмарі. Більшість були встановлені в UEFI. Декілька старіших вузлів були legacy BIOS тому що «це не мало значення» тоді, а опції інсталятора були тими, які технік випадково вибрав того дня. Ніхто не документував, який режим де використано. Звісно, ні.

Під час циклу оновлень пройшов kernel та оновлення GRUB. Один вузол не повернувся. Консоль показувала firmware boot menu. Інженер завантажив rescue ISO, chroot і по звичці запустив grub-install /dev/sda. «Працювало». Система все ще не завантажувалась.

Вони повторювалися інтенсивніше: встановили GRUB на обидва диски (було дзеркало), перебудували конфіги, перезавантажили. Фірмвер меню залишалося. Години зникали в тій особливій манері, яку тільки boot loop може викрасти.

Проблема була проста і принизлива: вузол був встановлений у UEFI режимі, а firmware шукало EFI entry і ESP файл. Встановлення BIOS GRUB у MBR нічого не дало, лише додало шуму. Rescue ISO завантажився в BIOS режимі, що укріпило хибне припущення.

Після перезавантаження rescue ISO в UEFI режимі, змонтували ESP і запустили UEFI-орієнтований grub-install, і вузол відразу повернувся. Дія після інциденту була також проста: записати boot mode в інвентар. Не у чиїсь голові. Не в wiki, яку ніхто не відкриває під час інциденту. А в системних фактах, які автоматика може опитати.

Mini-story 2: The optimization that backfired

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

Це працювало місяцями. Потім планове оновлення включало kernel та microcode пакети. initramfs став більшим, як це зазвичай буває, коли підтримка апаратного забезпечення зростає і хуки накопичуються. На одному вузлі /boot заповнився під час оновлення. Пакет kernel записав свої файли, але генерація initramfs провалилася. Вивід пакетного менеджера був десь — але автоматика не сприйняла це як жорстку помилку.

Після перезавантаження GRUB показав новий запис ядра (бо vmlinuz існував) і спробував його завантажити. У меню initramfs, на який посилався запис, відсутній. Вузол потрапив у initramfs shell, потім таймаут, потім перезавантаження, і так далі. Ідеальний самопідтримуючий outage.

Виправлення було не містичним: завантажити попереднє ядро, видалити старі ядра коректно, перебудувати initramfs, згенерувати GRUB config. Урок: оптимізація, яка прибирає запас на критичному сховищі, — це пози́ка. З часом ви платите її з відсотками, зазвичай під час maintenance window, який ви обіцяли зробити нудним.

Mini-story 3: The boring but correct practice that saved the day

Фінансово-орієнтована організація запускала Debian сервери із зашифрованим root (LUKS) і строгим change control. Їхні оновлення автоматизовані, але свідомо поетапні: оновити канарку, почекати, потім рулингу. Вони також тримали два відомо-робочі ядра й моніторили використання /boot.

Одного вечора update ядра вніс регресію для конкретної версії firmware контролера сховища. Канарка перезавантажилась і потрапила в initramfs через те, що root не знайдено. Сервіс на тому вузлі був недоступний, але інцидент не поширився, бо rollout автоматично призупинився після невдалого health check.

Ops використали консоль, щоб вибрати попереднє ядро з Advanced options у GRUB. Вузол повернувся. Вони тимчасово зафіксували версію ядра, перебудували initramfs з конкретним включенням модуля і запланували оновлення firmware контролера окремо.

Нічого героїчного. Ніхто не набирає магічні заклинання. Система вижила, бо робили нудні речі: staged rollout, збереження rollback-ядр, і моніторинг вільного місця в /boot. Саме так виглядає надійність у більшість днів: нудна, повторювана компетентність.

Common mistakes: symptom → root cause → fix

Symptom: grub-install “succeeds” but after reboot you still get firmware boot menu.
Root cause: ESP wasn’t mounted; you installed into /boot/efi on the root filesystem, not the ESP.
Fix: mount the real ESP (vfat), verify with findmnt, rerun grub-install --efi-directory=/boot/efi, check efibootmgr -v.
Symptom: GRUB menu shows new kernel, but boot drops to initramfs with “cannot find UUID”.
Root cause: root UUID changed (disk clone/replacement) or crypt/mdraid mapping name changed; initramfs still has old references.
Fix: correct /etc/fstab, /etc/crypttab, and mdadm config if applicable; run update-initramfs -u -k all.
Symptom: update-grub finds no kernels.
Root cause: /boot not mounted (separate partition), or kernels were removed/never installed due to dpkg errors.
Fix: mount /boot; verify /boot/vmlinuz-*; repair packages with dpkg --configure -a and apt-get -f install.
Symptom: Boot loop after GRUB selection; kernel panic early.
Root cause: broken initramfs, missing storage driver, or regression in new kernel.
Fix: boot older kernel; rebuild initramfs; consider pinning the kernel package until regression is addressed.
Symptom: grub rescue> prompt, ls shows partitions but normal can’t load.
Root cause: GRUB prefix points to the wrong partition or /boot/grub missing/corrupted.
Fix: use rescue/live, mount properly, chroot, reinstall GRUB and regenerate config; also check disk/FS integrity.
Symptom: Secure Boot enabled systems refuse to boot after GRUB update.
Root cause: unsigned or mismatched EFI binaries/shim chain; or wrong package set installed.
Fix: ensure the correct signed packages are installed for your policy; temporarily disable Secure Boot only as a diagnostic step, then restore a compliant boot chain.
Symptom: mdraid root systems drop into initramfs with no arrays assembled.
Root cause: initramfs missing mdadm config or modules; or metadata version/UUID mismatch after disk replacement.
Fix: confirm arrays with mdadm --examine in rescue; fix /etc/mdadm/mdadm.conf; rebuild initramfs.

Checklists / step-by-step plan

Checklist A: If you can see a GRUB menu

Select Advanced options and boot the previous kernel.
Once booted, check /boot space and package state.
Rebuild initramfs for the latest kernel once space is adequate.
Run update-grub, then reboot and test latest kernel.
If firmware still doesn’t consistently find GRUB, reinstall GRUB (UEFI/BIOS correctly) and verify with efibootmgr.

Checklist B: If you’re stuck in firmware menu or grub rescue

Boot a rescue environment in the correct mode (UEFI vs BIOS).
Identify disks/partitions with lsblk. Locate root, /boot, and ESP.
Unlock LUKS / assemble RAID / import pools as needed before mounting.
Mount root at /mnt, then mount /mnt/boot and /mnt/boot/efi if present.
Bind-mount /dev, /proc, /sys, then chroot.
Repair dpkg state: dpkg --audit, apt-get -f install.
Fix /boot space if needed; remove old kernels properly.
Rebuild initramfs for the target kernel.
Run update-grub and confirm it finds kernels/initrd.
Reinstall GRUB to the correct target (UEFI or BIOS).
Verify with efibootmgr -v and listing ESP files.
Reboot and watch the console through the first successful boot.

Checklist C: Guardrails to prevent the next one

Monitor /boot usage and alert at 70–80%.
Keep at least one known-good older kernel installed.
Stage updates with canaries; pause rollout on boot failures.
Ensure ESP is mounted and checked during updates (and in config management).
Standardize boot mode per fleet; record it in inventory.
For remote-only systems, configure serial console kernel parameters persistently.

FAQ

1) Is this really a “GRUB problem” if I drop into initramfs?

Зазвичай ні. Якщо kernel стартував і ви в initramfs, GRUB зробив свою частину. Зосередьтесь на виявленні root device: UUID, розблокування LUKS, збірка mdraid, відсутні драйвери або регресія ядра. Перебудуйте initramfs і перевірте /etc/fstab//etc/crypttab.

2) Why does `grub-install` succeed but nothing changes?

Найпоширеніша причина: ESP не був змонтований. Ви записали EFI файли в директорію на root filesystem, а не на FAT-партицію, придатну для firmware. Завжди перевіряйте findmnt /boot/efi і перевіряйте вміст ESP після цього.

3) Should I copy `grubx64.efi` to the fallback path?

На серверах з ненадійним NVRAM, наявність \EFI\BOOT\BOOTX64.EFI може врятувати. Але робіть це свідомо: переконайтесь, що файл на ESP, і він узгоджений з вашою ланцюжком завантаження. Не залишайте три конфліктні лоадери і називайте це стійкістю.

4) Can I just delete old files from `/boot` to free space?

Можете, і іноді це допоможе, але dpkg буде думати, що пакети все ще існують. Видаляйте ядра через apt-get remove --purge linux-image-X, щоб хуки оновили initramfs і GRUB config коректно.

5) My system uses RAID1 for the ESP. Is that okay?

UEFI очікує FAT на ESP; стратегії дзеркалювання різняться. Деякі команди синхронізують ідентичні ESP на обох дисках. Це може працювати, але потрібно це операціоналізувати (процес оновлення, верифікація). Якщо оновлювати лише один ESP, ви створили failover до старішої реальності.

6) What if `efibootmgr` isn’t available in the chroot?

Встановіть його в chroot (apt-get install efibootmgr), якщо є мережа/джерела пакетів. Якщо ні — ви все ще можете переконатися, що ESP має правильні файли; багато firmware завантажать fallback path навіть без NVRAM entry.

7) Does Secure Boot change the rollback steps?

Механіка та сама — змонтувати ESP, перевстановити потрібні пакети, згенерувати конфіги — але дозволені бінарники відрізняються. Якщо Secure Boot enforced, unsigned EFI бінарники можуть бути відхилені. Розглядайте «відключити Secure Boot» як діагностичний крок, а не постійне рішення, якщо політика цього не допускає.

8) How do I know which disk to run `grub-install` on in BIOS mode?

Вибирайте диск, з якого BIOS фактично завантажується (часто перший у порядку завантаження), і на дзеркалованих системах розгляньте встановлення на обидва диски навмисно. Але не робіть «spray and pray»; підтвердіть порядок завантаження firmware і вашу RAID-топологію. У BIOS режимі встановлюють на весь диск, а не на розділ.

9) Why did this happen right after a firmware update?

Оновлення firmware може скинути NVRAM boot entries або змінити порядок завантаження. Ваша ОС і ESP можуть бути в порядку; firmware просто забуло Debian entry. Перевірте efibootmgr -v і відновіть запис або fallback loader path.

10) What’s the single best prevention for “won’t boot after updates”?

Тримайте опції відкату: принаймні одне старе робоче ядро, достатньо місця в /boot, поетапні rollout-и та автоматичні перевірки, що ESP змонтований під час оновлень. Надійність — це не геройський вчинок; це складені проценти.

Conclusion: next steps that reduce repeat incidents

Коли Debian 13 не завантажується після оновлень, розглядайте це як проблему ланцюга. Firmware має знайти loader, loader має знайти модулі/конфіг, GRUB має вказати на kernel і initramfs, які існують, а initramfs має вміти розблокувати/зібрати/змонтувати root. Виправляйте зламане ланка, а не б’єте молотком по всьому ланцюгу.

Зробіть це далі, поки інцидент ще свіжий:

Уніфікуйте boot mode в межах флоту (UEFI строго рекомендовано на сучасному обладнанні) і зафіксуйте це в інвентарі.
Додайте моніторинг використання /boot і сповіщення до того, як це перетвориться на помилку пакування.
Тримайте принаймні одне відомо-робоче старе ядро; не «чистіть» шлях відкату.
Автоматизуйте post-update перевірку: ESP змонтований, update-initramfs успішний, update-grub знайшов ядра, і efibootmgr показує адекватний запис.
Якщо у вас зашифрований root, RAID або ZFS: перевіряйте, що initramfs включає потрібні хуки/модулі після кожної суттєвої зміни. Ранній userspace — частина вашого стеку сховища.