Відновлення завантаження GPT/MBR: виправити «Немає завантажувального пристрою» без втрати даних

Що насправді означає «Немає завантажувального пристрою» (і чого це не означає)

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

Цей шлях відрізняється залежно від стилю завантаження:

• Legacy BIOS + MBR: BIOS читає перший сектор диска (MBR). MBR вказує на код завантаження (часто «stage 1.5»), а далі — на завантажувач ОС.
• Legacy BIOS + GPT (таке буває): BIOS не може нативно завантажувати GPT; зазвичай потрібен BIOS boot partition для збереження ядра GRUB. Деякі системи імітують це ненадійно.
• UEFI + GPT: UEFI читає EFI System Partition (ESP) — FAT32-розділ з .efi бінарниками. Воно використовує NVRAM-записи завантаження, щоб вибрати, яку .efi виконати.

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

• Прошивка дивиться не туди: неправильний порядок завантаження, неправильний диск, неправильний режим UEFI/Legacy.
• Таблиця розділів в порядку, але метадані завантаження зламані: відсутні файли на ESP, відсутній Windows BCD, зламана інсталяція GRUB, видалений NVRAM-запис.
• Диск присутній, але його не читають: змінено режим SATA, NVMe не виявляється, переключено режим RAID, проблеми з контролером або реальний збій диска.
• Хтось уже «виправляв»: і їхнє виправлення записало дані на невірний диск.

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

Факти й історія, які реально допомагають діагностувати

Завдання з завантаження легше, коли ви знаєте, чому світ влаштований таким чином. Ось кілька конкретних фактів, які з’являються у реальних інцидентах:

1. MBR маленький за конструкцією: класичний MBR код завантаження займає перші 446 байт сектору 0, залишаючи 64 байти для чотирьох записів розділів і 2 байти для сигнатури 0x55AA.
2. GPT існує тому, що MBR вичерпав ресурс: 32-бітна адресація секторів MBR обмежує розмір близько 2 TiB при 512-байтових секторах; GPT використовує 64-бітні LBA і не має такого ліміту.
3. GPT все одно зберігає «захисний MBR»: сектор 0 часто містить MBR, який каже «один великий розділ» типу 0xEE, щоб старі інструменти не псували диск.
4. UEFI не «сканує ОС» так, як думають люди: воно використовує NVRAM-записи, що вказують на конкретні EFI-бінарники на конкретному шляху диска/розділу.
5. EFI System Partition навмисно нудний FAT: FAT32 обрано для широкої сумісності з прошивкою, а не тому, що хтось його любить.
6. Secure Boot змінює режими відмов: диск може бути ідеальним, а завантажувач — цілий, але прошивка відмовляється виконувати неподписаний (або інакше підписаний) завантажувач.
7. Windows і Linux можуть співіснувати, але сперечаються, хто «головний»: оновлення Windows іноді відновлює Windows Boot Manager як за замовчуванням, тоді як інсталяції Linux часто ставлять GRUB першим.
8. BIOS-завантаження з GPT — особливий випадок: GRUB потребує маленького нефайлуваного «BIOS boot partition» (зазвичай 1–2 MiB), щоб зберігти ядро, яке не вміщується в проміжок MBR.
9. Клонування дисків може мовчки дублювати ідентифікатори дисків: це руйнує записи завантаження і іноді плутає монтування на рівні ОС, бо система бачить «два однакових диски».

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

Перше: перевірка реальності прошивки (60 секунд)

• Чи взагалі диск виявлений? Якщо BIOS/UEFI його не бачить — зупиніться. Це кабелі, режим контролера або апаратна проблема.
• Ви в режимі UEFI чи Legacy/CSM? Невірний режим — причина №1 випадків «диск ніби в порядку, але не завантажується».
• Порядок завантаження: якщо ви щойно підключили USB, деяка прошивка ввічливо вирішує, що він тепер головний.

Друге: ідентифікуйте диск і стиль розділів (5 хвилин)

• З live-середовища визначте: GPT чи MBR? Є ESP? Є BIOS boot partition? Присутній розділ ОС?
• Якщо Windows: знайдіть EFI-розділ і розділ Windows. Якщо Linux: знайдіть /boot, /boot/efi і root.

Третє: вирішіть, що саме ви ремонтуєте (10 хвилин)

• UEFI/GPT: відновити NVRAM-запис і/або відновити файли на ESP; можливо перебудувати BCD або перевстановити GRUB EFI.
• BIOS/MBR: відновити код MBR, прапор активного розділу (для деяких налаштувань) та ланцюжок завантажувача ОС.
• BIOS/GPT: переконатися, що існує BIOS boot partition; перевстановити GRUB на диск (не в розділ).

Умови зупину (коли не слід «просто щось пробувати»)

• SMART показує явний збій (зростання reallocated sectors, помилки читання). Спочатку клонуйте.
• Ви не впевнені, який диск який. Позначте їх. Якщо можливо — відключіть зайві.
• Система зашифрована і ви не знаєте процес відновлення. Відновлення завантаження — просте; відновлення «ой, я зламав єдиний шлях розблокування» — ні.

Перед тим як щось чіпати: правила безпеки, що запобігають втраті даних

Якщо ви хочете «без втрати даних», треба діяти серйозно.

Правило 1: Не записуйте, поки не зможете пояснити, що саме записуєте

Команди на кшталт bootrec /FixMbr, grub-install або efibootmgr -c — це не «діагностика». Вони змінюють стан диска або NVRAM. Використовуйте їх лише після того, як ідентифікували правильний диск і режим завантаження.

Правило 2: Клонуйте або зробіть образ, якщо диск виглядає хворим

Якщо диск виходить з ладу, кожен перезавантаження і кожен скан файлової системи — це кидок монети. Зробіть образ на інший диск і працюйте з копією.

Правило 3: Надавайте перевагу зворотним змінам

Зміна порядку завантаження UEFI, створення нового NVRAM-запису або перевстановлення завантажувача в ESP зазвичай відновлювані. Конвертація GPT↔MBR у місці — це не «ремонт», це міграція з гострими краями.

Правило 4: Один підключений диск — найкращий варіант

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

Короткий жарт #1: Ремонт завантаження як хірургія: легко бути відважним, коли це не ваші дані на столі.

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

Ці завдання припускають, що ви завантажилися з Linux live USB (бо це нейтральний набір інструментів), якщо завдання не специфічне для Windows. Команди реалістичні. Виводи — приклади; ваші відрізнятимуться. Суть у тому, як їх інтерпретувати і вирішити.

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

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Feb  4 10:12 /sys/firmware/efi

Що це означає: Якщо цей каталог існує, ви працюєте в UEFI-режимі. Якщо його немає — у Legacy BIOS.

Рішення: Співставте режим ремонту з режимом встановленої ОС. Якщо Windows встановлено в UEFI, а live USB завантажився в Legacy, ви будете гонитись за примарами.

Завдання 2: Швидко ідентифікувати диски й таблиці розділів

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL    MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1   260M part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2    16M part        e3c9e316-0b5c-4db8-817d-f92df00215ae Microsoft reserved
├─nvme0n1p3   200G part ntfs   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 Basic data
└─nvme0n1p4 276.6G part ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 Linux filesystem

Що це означає: GUID-типи розділів GPT відображаються в PARTTYPE. ESP — vfat і має відомий EFI GUID.

Рішення: Це система UEFI/GPT. Ремонт завантаження зосередиться на ESP і UEFI-записах, а не на MBR «active» прапорцях.

Завдання 3: Перевірити GPT чи MBR через parted (детальніше)

cr0x@server:~$ sudo parted -s /dev/nvme0n1 print
Model: Samsung SSD 970 (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  274MB   273MB   fat32        EFI System Partition          boot, esp
 2      274MB   291MB   16.8MB               Microsoft reserved partition  msftres
 3      291MB   215GB   215GB   ntfs         Basic data partition          msftdata
 4      215GB   512GB   297GB   ext4                                       

Що це означає: Partition Table: gpt та прапорці boot, esp вказують на EFI System Partition.

Рішення: Не витрачайте час на MBR-команди ремонту. Можливо, потрібно змонтувати ESP і відновити файли завантажувача.

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

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ ls -R /mnt/esp/EFI | head
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Boot:
BOOTX64.EFI

Що це означає: Є стандартні директорії. EFI/Boot/BOOTX64.EFI — це «шлях fallback», який багато прошивок спробують, якщо NVRAM-записи відсутні.

Рішення: Якщо /mnt/esp/EFI порожній або відсутні Microsoft/ubuntu, ймовірно, у вас ушкодження або видалення ESP. Ремонт буде «відновити файли», а не «перепризначити розділи».

Завдання 5: Переглянути UEFI NVRAM-записи завантаження (UEFI-системи)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Windows Boot Manager  HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* ubuntu                HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* UEFI: USB Flash Disk  PciRoot(0x0)/Pci(0x14,0x0)/USB(0x3,0x0)/HD(1,MBR,0x1234,0x800,0x3a9800)

Що це означає: Є записи для Windows і Ubuntu. Це добре. Якщо система все ще каже «Немає завантажувального пристрою», можливо, вона завантажилася в Legacy режим, диск не виявляється під час POST, або Secure Boot блокує завантажувач.

Рішення: Якщо запис «Windows Boot Manager» відсутній — створіть його. Якщо записи існують, але вказують на невірний GUID диска (поширено після клонування), виправте їх або використайте fallback-шлях.

Завдання 6: Відтворити відсутній запис Windows Boot Manager (UEFI)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0002
BootOrder: 0003,0002,0000,0001
Boot0003* Windows Boot Manager  HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

Що це означає: Ви створили новий NVRAM-запис, що вказує на Microsoft EFI-бінарник на розділі 1.

Рішення: Перезавантажте і виберіть його в прошивці. Якщо воно завантажується — усе готово. Якщо прошивка забуває запис після перезавантаження — підозрюйте батарейку CMOS/баг прошивки або «Fast Boot»; користуйтеся fallback-шляхом або оновленням прошивки.

Завдання 7: Перевірити BIOS/MBR прапорці і активний розділ (legacy системи)

cr0x@server:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disklabel type: dos
Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048  1026047  1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2        1026048 1048575999 1047549952 499.5G 7 HPFS/NTFS/exFAT

Що це означає: Disklabel type dos вказує на MBR. Зірочка * позначає активний (завантажувальний) розділ — важливо для деяких BIOS-ланцюжків.

Рішення: Якщо в BIOS/Windows налаштуванні відсутній активний розділ, встановіть його (акуратно) на системний/резервний розділ, а не на розділ з даними.

Завдання 8: Встановити прапор active на правильному розділі (MBR)

cr0x@server:~$ sudo fdisk /dev/sda
Command (m for help): a
Partition number (1-2): 1
Command (m for help): p

Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048  1026047  1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2        1026048 1048575999 1047549952 499.5G 7 HPFS/NTFS/exFAT

Command (m for help): w
The partition table has been altered!

Що це означає: Ви перемикнули прапорець завантажувального розділу.

Рішення: Перезавантажте і протестуйте. Якщо завантаження все ще не вдається — ймовірно, треба відновити код завантаження (MBR/VBR/BCD), а не лише прапорці.

Завдання 9: Оцінити стан диска перед записом структури завантаження

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated|Pending|Uncorrect|SMART overall"
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Що це означає: Немає явних ознак відмови носія. «PASSED» не гарантує нічого, але паніки немає.

Рішення: Продовжуйте ремонт завантаження. Якби Current_Pending_Sector був ненульовий — клонуйте спочатку і уникайте інструментів з інтенсивними записами.

Завдання 10: Клонувати диск перед ремонтом, коли відчуваєте проблеми

cr0x@server:~$ sudo ddrescue -f -n /dev/sda /dev/sdb /mnt/recovery/ddrescue.log
GNU ddrescue 1.27
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:        0 B,  errsize:        0 B,  errors:       0
Current status
rescued:  500000 MB,  errsize:      0 B,  current rate:  120 MB/s
ipos: 500000 MB,  errors:       0,    average rate:  115 MB/s
Finished

Що це означає: Ви скопіювали джерельний диск на цільовий, логуючи можливості відновлення. ddrescue створено для неповних носіїв.

Рішення: Виконуйте всі подальші ремонти на /dev/sdb (клоні). Зберігайте /dev/sda як оригінальний доказ.

Завдання 11: Змонтувати Linux-розділи правильно для chroot-ремонту

cr0x@server:~$ sudo mount /dev/nvme0n1p4 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
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:/# ls /boot/efi/EFI
Boot  Microsoft  ubuntu

Що це означає: Ви працюєте всередині встановленого ОС середовища з ESP змонтованим там, де ОС його очікує.

Рішення: Це правильний контекст для перевстановлення GRUB або регенерації initramfs без шкоди середовищу live USB.

Завдання 12: Перевстановити GRUB для UEFI-систем (Linux)

cr0x@server:~$ sudo chroot /mnt /bin/bash -c "grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu && update-grub"
Installing for x86_64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
done

Що це означає: EFI-бінарник GRUB та конфіг встановлені, і він виявив Windows також.

Рішення: Перезавантажте і оберіть «ubuntu» або встановіть порядок завантаження. Якщо увімкнений Secure Boot і ви встановили несигнований GRUB — можливо, потрібні пакети shim або тимчасове відключення Secure Boot для підтвердження діагнозу.

Завдання 13: Встановити GRUB для BIOS/MBR систем (Linux)

cr0x@server:~$ sudo chroot /mnt /bin/bash -c "grub-install /dev/sda && update-grub"
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
done

Що це означає: GRUB встановлено в область MBR диска (не в розділ), і конфіг згенеровано.

Рішення: Перезавантажте. Якщо все ще не працює — перевірте, чи BIOS дійсно встановлений на завантаження з /dev/sda і чи диск перший у порядку.

Завдання 14: Виявити потребу BIOS/GRUB на GPT у BIOS-режимі (Linux на GPT у BIOS)

cr0x@server:~$ sudo parted -s /dev/sda print | sed -n '1,20p'
Model: ATA ST1000DM010 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   ext4
 2      538MB   1000GB  999GB   ext4

Що це означає: GPT-диск, але немає маленького розділу з прапорцем bios_grub. BIOS-завантаження GRUB з GPT зазвичай потребує цього розділу.

Рішення: Якщо машина завантажується в Legacy режимі, створіть 1–2 MiB BIOS boot partition (без форматування) і встановіть прапорець bios_grub — тільки якщо безпечно можна зменшити/перемістити розділи. Якщо можете переключити прошивку в UEFI-режим — зробіть це замість цього. Це чистіше.

Завдання 15: Windows UEFI: перебудувати BCD з середовища відновлення

У командному рядку Windows Recovery (не в Linux) зазвичай присвоюють букву ESP і відновлюють файли завантаження. Приклад:

cr0x@server:~$ diskpart
DISKPART> list vol
Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
----------  ---  -----------  -----  ----------  -------  ---------  --------
Volume 0     C                NTFS   Partition    200 GB  Healthy    Boot
Volume 1          SYSTEM      FAT32  Partition    260 MB  Healthy    System

DISKPART> sel vol 1
DISKPART> assign letter=S
DISKPART> exit

cr0x@server:~$ bcdboot C:\Windows /s S: /f UEFI
Boot files successfully created.

Що це означає: bcdboot скопіював файли завантаження Windows на ESP і створив BCD-хранилище, придатне для UEFI.

Рішення: Перезавантажте і встановіть Windows Boot Manager першим у прошивці за потреби. Якщо не вдається — ESP могло бути змонтовано неправильно, або Windows не знаходиться за C:\Windows в режимі відновлення — перевірте букви томів.

Завдання 16: Windows BIOS/MBR: аккуратно відновити ланцюг завантаження

cr0x@server:~$ bootrec /FixMbr
The operation completed successfully.
cr0x@server:~$ bootrec /FixBoot
Access is denied.
cr0x@server:~$ bootrec /RebuildBcd
Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  D:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): Y
The operation completed successfully.

Що це означає: /FixMbr записав MBR-код. /FixBoot, що повернув «Access is denied», — поширена проблема в деяких збірках Windows і може вказувати на права/плутанину ESP (особливо коли насправді це UEFI/GPT) або невідповідне середовище відновлення.

Рішення: Якщо ви справді в BIOS/MBR, переконайтесь, що правильний системний розділ активний і має завантажувальний сектор; іноді використовують bootsect /nt60 SYS. Якщо диск — GPT, припиніть використовувати BIOS-інструменти і перейдіть до UEFI-ремонту (bcdboot).

Завдання 17: Перевірити цілісність файлової системи на ESP (FAT може дивувати)

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -a /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
FATs differ but appear to be intact. Using first FAT.
Reclaimed 12 unused clusters (49152 bytes) in 3 chains.

Що це означає: Невеликі невідповідності FAT були виправлені. Якщо повідомляє про серйозну корупцію — можливо треба відтворити ESP і відновити файли завантаження.

Рішення: Після ремонту змонтуйте знову і перевірте вміст директорії EFI.

Шляхи ремонту за платформою та стилем завантаження

UEFI + GPT: «сучасний» стандарт

Це більшість ноутбуків і десктопів останнього десятиліття. Відновлення зводиться до трьох речей: розділи диска, файли на ESP і NVRAM-записи.

• Якщо диск не виявляється в прошивці: це не проблема завантажувача. Перевірте режим контролера (AHCI vs RAID), налаштування NVMe, кабелі, оновлення прошивки.
• Якщо ESP існує, але порожній/пошкоджений: відновіть EFI/Microsoft через bcdboot (Windows) або перевстановіть GRUB (Linux). Використайте fsck.vfat для дрібних відновлень.
• Якщо ESP в порядку, але записи завантаження відсутні: відновіть записи за допомогою efibootmgr (Linux) або дозвольте інструментам Windows відновити їх (Windows Recovery).
• Якщо записи існують, але вказують на невірний ідентифікатор диска (після клонування): створіть нові записи, що посилаються на правильний диск/розділ, і видаліть старі.
• Якщо Secure Boot блокує: використайте підписані пакети shim/GRUB, налаштуйте ключі або тимчасово відключіть Secure Boot для діагностики.

Legacy BIOS + MBR: ще живий в обладнанні й старих системах

Тут більше «код» і менше «файли». Ваші цілі:

• Код завантаження MBR (перший сектор)
• Завантажувальний сектор розділу (VBR) для активного розділу (Windows) або налаштування етапів GRUB (Linux)
• BCD (Windows) або конфіг GRUB (Linux)

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

Legacy BIOS + GPT: «робіть це тільки якщо треба»

Це може працювати, але тонко і часто ламається після переміщення дисків чи переключення прошивки. Якщо успадкували таку конфігурацію, найкращий результат — переключити на UEFI, якщо апарат це підтримує. Інакше знадобиться BIOS boot partition (місце для GRUB) і правильно встановлений GRUB на диск.

Чого не робити: конвертації «на місці» під час простою

Конвертація MBR↔GPT можлива. Це також інший проєкт, ніж «ремонт завантаження», особливо якщо ви намагаєтесь зберегти дані. Виконуйте тільки з бекапом і контрольованими змінами. Якщо ваша мета — запустити систему сьогодні, не починайте форматні пригоди.

Короткий жарт #2: UEFI NVRAM-записи як налаштування принтера: всі впевнені, що це просто, поки це не стане єдиною річчю між вами і дедлайном.

Три корпоративні міні‑історії з реального життя

Інцидент №1: Неправильне припущення («Це мертвий диск»)

Повернувся польовий ноутбук з «Немає завантажувального пристрою». Користувач присягався, що це сталося після розряду батареї. Сервісна служба відразу вирішила: «SSD помер», бо це зручна історія і всім подобається міняти деталі.

Хтось замінив SSD. Завантаження не відбулося. Тепер почали говорити про «помилку материнської плати», бо якщо новий SSD не завантажується — машина проклята. Квиток катався день, поки дедлайн користувача наближався.

Коли справа дійшла до SRE, що вже колись помилявся, перший крок був принизливо простим: підтвердити, чи прошивка в UEFI-режимі. Вона ні. Скидання BIOS перевернуло його в Legacy/CSM. Початкова інсталяція Windows була UEFI/GPT. У Legacy режимі прошивка шукала MBR-підпис, не знайшла і здалася.

Переключили прошивку назад в UEFI, Windows Boot Manager з’явився — машина завантажилась. «Мертвий SSD» був цілим. Замінений SSD став новою проблемою: його треба було стерти і повернути на інвентар.

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

Інцидент №2: Оптимізація, що відвернулася проти (ESP «золотого образу»)

ІТ‑команда створила «золотий образ» клонування дисків для швидшого розгортання: однакова структура GPT, однакові ОС та пакети. У лабораторії працювало. У виробництві — теж, до певного моменту.

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

Корінна причина: процес клонування дублював ідентифікатори дисків і залишав NVRAM-записи, що вказували на конкретний диск/розділ, які не були стабільними у серії. Деякі прошивки терпіли це і «перечитували» записи; інші — ні. Після оновлення NVRAM очищався, і шлях fallback не був послідовно заповнений, тому машини не мали валідного вказівника на EFI-бінарник.

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

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

Інцидент №3: Нудна правильна практика, що врятувала день (спершу іміджування)

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

Фахівець зі зберігання даних поставив одне питання: «Що каже SMART?» Було видно відкладені сектори. Не багато, але достатньо. Диск не був мертвим, але ненадійним. Кожне додаткове читання могло бути останнім.

Вони зробили образ диска за допомогою ddrescue на надійний SSD, з логом, щоб повторювати спроби читання поганих ділянок без перечитування хороших. Лише потім робили ремонт завантаження на клоні. Клон завантажився після ремонту EFI і перебудови BCD. Оригінальний диск потім деградував далі, як і передбачалось.

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

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

Одна операційна максима, варта запам’ятовування (парафраз ідеї Річарда Кука): Складні системи успішні тому, що люди постійно адаптуються і виправляють приховані проблеми.

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

1) Симптом: «Немає завантажувального пристрою» відразу після скидання BIOS або оновлення прошивки

Корінна причина: Режим завантаження перевернутий (UEFI ↔ Legacy/CSM) або порядок завантаження скинуто.

Виправлення: Поставте режим у значення, в якому встановлена ОС. Якщо є GPT + ESP — використовуйте UEFI. Відновіть порядок завантаження на Windows Boot Manager або ваш запис GRUB.

2) Симптом: Диск видно в Linux live USB, але не в меню завантаження прошивки

Корінна причина: Відсутній UEFI-запис; прошивка завантажується лише з зареєстрованих записів і ігнорує fallback, або шлях ESP неправильний.

Виправлення: Використайте efibootmgr -v для перегляду записів; створіть новий запис, що вказує на \EFI\Microsoft\Boot\bootmgfw.efi або \EFI\ubuntu\shimx64.efi. Переконайтесь, що fallback \EFI\Boot\BOOTX64.EFI існує.

3) Симптом: Інструменти відновлення Windows скаржаться «Access is denied» при FixBoot

Корінна причина: Часто ви фактично в UEFI/GPT і використовуєте неправильний шлях ремонту, або системний розділ не той, що ви думаєте.

Виправлення: Віддавайте перевагу bcdboot C:\Windows /s S: /f UEFI після присвоєння букви ESP. Перевірте, який том є ESP (FAT32, «System»).

4) Симптом: GRUB rescue prompt, «unknown filesystem»

Корінна причина: GRUB не може знайти свої модулі/конфіг через переміщені розділи, перезаписаний core image або відсутній /boot.

Виправлення: Завантажте live Linux, змонтуйте root і boot, chroot, перевстановіть GRUB (UEFI: --target=x86_64-efi; BIOS: встановіть на диск), потім update-grub.

5) Симптом: Система з подвійним завантаженням тепер завантажується прямо в Windows

Корінна причина: Оновлення Windows зробило Windows Boot Manager першим у порядку або переписало запис за замовчуванням.

Виправлення: Поміняйте порядок через інтерфейс прошивки або efibootmgr -o. Якщо запис GRUB відсутній — перевстановіть GRUB в ESP і створіть запис.

6) Симптом: Після клонування диск завантажується тільки коли підключено старий диск

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

Виправлення: Створіть нові UEFI-записи, що вказують на клон. Розгляньте видалення дублікатів і використання fallback-шляху EFI/Boot.

7) Симптом: «No bootable device» тільки коли вставлені USB-диски

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

Виправлення: Налаштуйте порядок завантаження; вимкніть «boot from USB», якщо політика дозволяє; або переконайтесь, що USB реально завантажувальний.

8) Симптом: Linux завантажується, Windows відсутній у GRUB

Корінна причина: os-prober відключено політикою дистрибутиву, або Windows-розділ недоступний (BitLocker заблокований, hibernation або fast startup).

Виправлення: Вимкніть Windows fast startup; розблокуйте BitLocker за потреби; увімкніть і запустіть os-prober, потім перегенеруйте конфіг GRUB.

Контрольні списки / покроковий план

Контрольний список A: Мінімально ризиковий потік для «Немає завантажувального пристрою» (загальний)

1. Увійдіть у налаштування прошивки: підтвердьте, що диск виявлений.
2. Підтвердьте режим завантаження: UEFI чи Legacy. Не вгадуйте.
3. Встановіть порядок завантаження на правильний диск/запис (Windows Boot Manager або ваш Linux-запис).
4. Завантажте live USB в тому ж режимі (UEFI або BIOS), що й встановлена ОС.
5. Ідентифікуйте диски та розділи (lsblk, parted).
6. Якщо SMART поганий — спочатку клонуйте з ddrescue.
7. Змонтуйте ESP і перевірте директорії EFI.
8. Перегляньте і виправте UEFI-записи (efibootmgr) або MBR-прапорці (fdisk).
9. Відновіть завантажувач:
   • Windows UEFI: bcdboot
   • Windows BIOS: bootrec (і перевірка активного розділу)
   • Linux UEFI: grub-install --target=x86_64-efi
   • Linux BIOS: grub-install /dev/sdX
10. Перезавантажте один раз. Перевірте. Не робіть десять ремонтних ітерацій; це втрата контролю над станом.

Контрольний список B: UEFI/GPT ремонт, коли ESP є, але запис завантаження відсутній

1. Змонтуйте ESP і переконайтесь, що цільовий .efi існує.
2. Створіть новий запис за допомогою efibootmgr -c, що вказує на нього.
3. Опційно створіть/перевірте fallback: \EFI\Boot\BOOTX64.EFI.
4. Встановіть порядок завантаження так, щоб новий запис був першим.
5. Перезавантажте і підтвердіть.

Контрольний список C: Потік «Я не довіряю цьому диску» (дані перш за все)

1. Завантажте live USB, поки не запускайте перевірки файлових систем.
2. Перевірте SMART; якщо з’являються очікувані/незворотні сектори — зупиніться.
3. Клонуйте за допомогою ddrescue на новий диск.
4. Відключіть оригінальний диск.
5. Ремонтуйте завантаження на клоні.
6. Після відновлення завантаження зробіть повноцінний бекап. Не живіть на клоні, ніби нічого не сталося.

Поширені запитання

1) Чи можу я виправити «Немає завантажувального пристрою» без перевстановлення ОС?

Зазвичай — так. Найчастіше розділи ОС ці, а пошкоджена лише метаінформація завантаження: неправильний режим прошивки, відсутній UEFI-запис, пошкоджений ESP, зламаний BCD або GRUB.

2) Як дізнатися, чи диск GPT або MBR?

У Linux: parted -s /dev/sdX print покаже «Partition Table: gpt» або «msdos». У Windows: diskpart → list disk покаже * під GPT для GPT-дисків.

3) Який найшвидший спосіб визначити, що я в неправильному режимі завантаження?

Якщо диск GPT і має ESP, а прошивка встановлена в Legacy/CSM, часто ви отримаєте «Немає завантажувального пристрою». Навпаки, MBR/BIOS інсталяція не завантажиться у чистому UEFI без UEFI-завантажувача.

4) Чи безпечно запускати bootrec або grub-install?

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

5) Чому UEFI іноді «забуває» записи завантаження?

NVRAM може бути скинутий оновленнями прошивки, скиданням BIOS або багами прошивки. Деякі системи також погано реагують, коли змінюються ідентифікатори дисків після клонування. Наявність валідного fallback-завантажувача у \EFI\Boot\BOOTX64.EFI допомагає.

6) Чи потрібно пересоздавати EFI System Partition, якщо він пошкоджений?

Не завжди. Невеликі помилки FAT можна виправити за допомогою fsck.vfat. Якщо ESP відсутній, серйозно пошкоджений або таблиця розділів змінена — можливо, доведеться його створити і відновити файли завантаження (Windows: bcdboot; Linux: grub-install).

7) Щодо BitLocker або повного шифрування диска?

Шифрування змінює пріоритети. Часто можна відновити EFI/завантажувач, не торкаючись зашифрованих томів, але переконайтесь, що маєте ключі відновлення і розумієте ланцюжок завантаження. Не тисніть «перепризначити розділи» як фікс.

8) Моя система з подвійним завантаженням, і тепер видно лише одну ОС. Чи я втратив іншу?

Не обов’язково. Меню завантаження — це лише вказівники. Інша ОС зазвичай присутня; треба відновити конфіг GRUB або відновити правильний порядок/записи UEFI.

9) Чи варто перетворювати MBR на GPT (або навпаки) щоб виправити завантаження?

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

10) Коли припинити ремонти і визнати апаратну проблему?

Якщо диск не виявляється в прошивці, якщо SMART показує зростаючі помилки читання/очікувані сектори, або якщо ви не можете стабільно читати розділи з live-середовища — вважайте це апаратною відмовою або проблемою носія. Спочатку зніміть образ, потім відновлюйте.

Висновок: практичні наступні кроки

Збої завантаження відчуваються драматично, бо система мовчить, але виправлення часто нудні: прошивка в неправильному режимі, на ESP відсутні файли або запис завантаження не вказує куди треба.

Зробіть наступне, по порядку:

1. Підтвердьте в прошивці виявлення диска і режим завантаження.
2. Завантажте live-середовище в тому ж режимі, що й встановлена ОС.
3. Визначте GPT чи MBR, потім знайдіть ESP/системні розділи.
4. Якщо диск виглядає ненадійним — клонувати з ddrescue і ремонтувати клон.
5. Відновіть відповідний рівень: UEFI-записи + файли на ESP для UEFI/GPT; MBR/активний розділ/BCD або GRUB для BIOS/MBR.
6. Перезавантажте один раз, перевірте, а потім зробіть реальний бекап. Відновлений завантажувач — не стратегія резервного копіювання.