Подвійне завантаження зламалося? Безпечно відновіть завантажувач Windows

Виправлення завантажувача без забобонів: модель мислення

Коли Windows «не завантажується» після зміни в dual-boot, зазвичай ламається один із чотирьох рівнів:

Рівень 1: Точки входу прошивки (UEFI NVRAM або BIOS)

UEFI-машини зберігають записи завантаження в NVRAM: маленькі вказівники типу “Boot0003 → \EFI\Microsoft\Boot\bootmgfw.efi on disk X partition Y”. Якщо цей вказівник видалено, перейменовано або він вказує на інший диск, Windows може бути цілком цілою й одночасно недоступною.

Старіші BIOS-машини не мають NVRAM-записів. Вони завантажують першорядний код з MBR диска, який потім знаходить активний розділ і його завантажувальний сектор, який вже знаходить завантажувач. Інша епоха — інші режими відмов, та та сама паніка.

Рівень 2: Розклад дисків (GPT vs MBR і де живе EFI System Partition)

На UEFI-системах EFI System Partition (ESP) — це невеликий FAT32-розділ, що містить завантажувачі для Windows, Linux і будь-чого іншого. ESP не опціональний. Якщо він відсутній, пошкоджений або примонтований/зміненний неправильно, машина перетворюється на дорогий прес-пап’єр із світлодіодами.

Рівень 3: Файли завантажувача (Windows Boot Manager)

Для Windows під UEFI основний файл зазвичай \EFI\Microsoft\Boot\bootmgfw.efi. Під BIOS/MBR «файли завантажувача» більше стосуються коду завантаження тома і \Boot\BCD на System Reserved розділі (іноді — на C:, якщо хтось «оптимізував» структуру).

Рівень 4: Сховище BCD (конфігурація завантаження Windows)

BCD (Boot Configuration Data) — це меню завантаження Windows і параметри завантаження. Якщо BCD пошкоджений, ви можете дістатися до Windows Boot Manager, але провалитися на останньому кроці входу в ОС.

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

Цитата, яку варто пам’ятати: «Сподівання — не стратегія.» — перефразована думка, часто цитована в роботі з експлуатації та надійності.

Жарт для розвантаження: Завантажувачі як аеропортні покажчики — коли вони помилкові, літак ще є, але ви нікуди не полетите.

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

Якщо хочете швидко виправити проблему, не починайте з заклинань bootrec. Почніть з триступеневого огляду, який звузить проблему за кілька хвилин.

По-перше: підтвердьте режим прошивки і диск, з якого ви насправді завантажуєтесь

• Перевірте, чи Windows встановлена в UEFI чи Legacy режимі. Змішані режими — причина №1, чому «ремонти» здаються успішними, але система не завантажується.
• Перевірте порядок завантаження прошивки. Встановлення Linux може додати новий запис і змістити Windows униз списку.
• Перевірте, на якому фізичному диску знаходиться ESP або System Reserved. Системи з кількома дисками — місце, де помилки у припущеннях ростуть як гриби.

По-друге: переконайтеся, що ESP/System розділ існує і читається

• UEFI: знайдіть FAT32 ESP, змонтуйте його і підтвердіть, що \EFI\Microsoft\Boot існує.
• BIOS: знайдіть активний NTFS «System Reserved» розділ (або еквівалент) і підтвердіть наявність \Boot\BCD.

По-третє: лише потім ремонтуйте найменший зламаний рівень

• NVRAM-запис відсутній? Відтворіть запис (або запустіть bcdboot, що часто робить це автоматично).
• Файли завантажувача відсутні? Відтворіть їх на ESP через bcdboot.
• BCD пошкоджений? Реконструюйте BCD (обережно) після ідентифікації установки Windows.
• Код MBR пошкоджений? Використайте шлях MBR (bootrec, bootsect).

Не пропускайте прямо до видалення/перепризначення розділів. Більшість випадків «Windows зникла» — це просто проблема вказівника завантаження.

Цікаві факти та контекст для нарад

1. UEFI поступово замінив BIOS у 2010-х, і багато машин досі пропонують «Legacy» сумісність, що призводить до випадкових змішаних установок.
2. Диски GPT не використовують прапорець «active» так, як це робили MBR-диски; ця концепція — артефакт епохи BIOS.
3. EFI System Partition зазвичай FAT32, оскільки прошивки надійно читають FAT32 у різних постачальників ще до завантаження ОС.
4. Windows Boot Manager під UEFI — це просто .efi файл; його не існує нічого містичного — видаліть або перейменуйте його і Windows перестане завантажуватися.
5. GRUB може chainload-ити Windows, але оновлення Windows іноді переписує порядок завантаження на користь Windows Boot Manager, що дивує Linux-користувачів.
6. BCD замінив boot.ini (який був у старих версіях Windows), щоб підтримувати гнучкіші сценарії завантаження й сучасну взаємодію з прошивкою.
7. Багато OEM-систем мають кілька розділів відновлення; видалення «невідомих маленьких розділів» може позбавити вас єдиної копії критичних файлів завантаження.
8. BitLocker змінює профіль ризиків для ремонтів завантаження: навіть коректні виправлення можуть викликати запити ключа відновлення, якщо шлях завантаження змінився.
9. На системах з кількома дисками інсталятори часто вибирають «перший» ESP (за переліком прошивки), а не диск, який ви вважали потрібним для кожної ОС.

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

Нижче — реальні завдання, які можна виконати з Command Prompt Windows Recovery Environment (WinRE) або з Linux live USB. Кожне завдання містить: команду, типовий результат і наступне рішення.

Завдання 1: У WinRE ідентифікуйте диски й розділи (підказки UEFI vs BIOS)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online          931 GB      0 B

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WinRE        NTFS   Partition    980 MB  Healthy    Hidden
  Volume 1     S   SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     C   Windows      NTFS   Partition    475 GB  Healthy    Boot

Що це означає: Disk 0 — GPT (зірочка в колонці «Gpt»). Тома S: — FAT32 і позначений як «System» — це ваш ESP. Ви в UEFI-світі.

Рішення: Використовуйте шлях ремонту для UEFI і сфокусуйтеся на ESP + BCD/файлах завантаження. Не запускайте MBR-орієнтовані команди типу bootrec /fixmbr, якщо не хочете плутанини.

Завдання 2: Підтвердьте шлях установки Windows і літери дисків у WinRE

cr0x@server:~$ dir C:\Windows\System32
 Volume in drive C has no label.
 Volume Serial Number is 3A1B-19C2

 Directory of C:\Windows\System32

01/15/2026  10:21 AM    <DIR>          .
01/15/2026  10:21 AM    <DIR>          ..
...

Що це означає: Ваш розділ Windows змонтований як C: у WinRE (не завжди так). Якщо dir не вдається, Windows може бути на D: або E: у WinRE.

Рішення: Використовуйте правильну літеру в наступних командах. Неправильні літери — як «полагодити» не ту ОС і звинуватити космічні промені.

Завдання 3: Змонтуйте й перевірте ESP у WinRE (перевірка здорового глузду)

cr0x@server:~$ diskpart
DISKPART> sel vol S
Volume 1 is the selected volume.

DISKPART> assign letter=Z
DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

cr0x@server:~$ dir Z:\EFI
 Volume in drive Z is SYSTEM
 Volume Serial Number is 8C2A-4E1D

 Directory of Z:\EFI

01/15/2026  10:18 AM    <DIR>          .
01/15/2026  10:18 AM    <DIR>          ..
01/15/2026  10:19 AM    <DIR>          Microsoft
01/15/2026  10:19 AM    <DIR>          ubuntu

Що це означає: ESP існує, читається і має директорії Microsoft та ubuntu. Це добре. Якщо \EFI\Microsoft відсутня, її, ймовірно, відновлять.

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

Завдання 4: Відтворіть файли завантаження Windows на ESP через bcdboot (UEFI)

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

Що це означає: Файли завантаження Windows скопійовано на ESP і, можливо, зареєстровано запис завантаження. Це дивовижно часто виправляє помилки «Windows Boot Manager відсутній».

Рішення: Перезавантажтеся і оберіть «Windows Boot Manager» у прошивковому меню. Якщо система все ще йде в GRUB, перевірте порядок завантаження і NVRAM-записи.

Завдання 5: Перелік записів прошивки з Linux live (перевірка UEFI)

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

Що це означає: Прошивка бачить і Windows Boot Manager, і ubuntu, і обидва вказують на файли на одній ESP. Добре. Якщо запис Windows відсутній або вказує на невірний диск/розділ, ви знайшли проблему.

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

Завдання 6: Підтвердіть ESP і файлову систему з Linux (не гадати)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTLABEL,PARTUUID,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTLABEL            PARTUUID                             MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1 100M part vfat   EFI System Partition  7C1B-...-...                        /mnt/esp
├─nvme0n1p2  16M part        Microsoft reserved   1a2b-...-...
└─nvme0n1p3 476G part ntfs   Basic data partition 3c4d-...-...                        /mnt/win

Що це означає: ESP — vfat і маленький (100M), Windows — NTFS. Якщо ESP змонтовано в дивному місці або на іншому диску, зупиніться і відобразіть карту дисків.

Рішення: Використовуйте ESP, з якого фактично завантажує прошивка, а не той, який вам би хотілося використовувати.

Завдання 7: Змонтуйте ESP і перевірте шлях Microsoft з Linux

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ ls -R /mnt/esp/EFI/Microsoft/Boot | head
/mnt/esp/EFI/Microsoft/Boot:
BCD
BCD.LOG
bootmgfw.efi
bootmgr.efi
memtest.efi

Що це означає: Файли існують. Якщо bootmgfw.efi відсутній, Windows не зможе завантажитися. Якщо на ESP є лише директорії Linux, файли Windows були видалені або ніколи не були створені на цій ESP.

Рішення: Якщо відсутні — краще використовувати bcdboot з WinRE. Копіювання випадкових .efi файлів з інтернету часто призводить до «secure boot violation» і поганого дня.

Завдання 8: У WinRE перевірте стан BitLocker перед «ремонтом»

cr0x@server:~$ manage-bde -status C:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume C: [Windows]
    Size:                 475.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        TPM
        Numerical Password

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

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

Завдання 9: Використайте bootrec для сканування Windows інсталяцій (корисно для BIOS/MBR, іноді для UEFI)

cr0x@server:~$ bootrec /scanos
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  C:\Windows

Що це означає: WinRE бачить одну інсталяцію Windows. Якщо знайдено нуль — можлива проблема з драйверами сховища/RAID, заблокований BitLocker або пошкоджена файлова система.

Рішення: Якщо нуль — не реконструюйте BCD одразу. Спершу зробіть том Windows видимим і читабельним.

Завдання 10: Реконструюйте BCD правильно (для UEFI і BIOS)

cr0x@server:~$ bcdedit /enum
The boot configuration data store could not be opened.
The system cannot find the file specified.

Що це означає: Сховище BCD відсутнє або не там, де WinRE його очікує. Це типовий наслідок змін ESP.

Рішення: Використайте bcdboot для генерації свіжого BCD на правильному системному розділі/ESP замість того, щоб намагатися воскресити напівзламане сховище.

Завдання 11: Перевірте цілісність файлової системи Windows із WinRE

cr0x@server:~$ chkdsk C: /f
The type of the file system is NTFS.
Volume label is Windows.

Stage 1: Examining basic file system structure ...
File verification completed.
Stage 2: Examining file name linkage ...
Index verification completed.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Windows has made corrections to the file system.
No further action is required.

Що це означає: Файлова система мала незначні проблеми і їх виправлено. Якщо бачите багато бад-секторів або «unable to recover», у вас апаратна проблема, що видає себе за помилку завантаження.

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

Завдання 12: Перевірте наявність файлів завантаження Windows на ESP після ремонту

cr0x@server:~$ dir Z:\EFI\Microsoft\Boot
 Volume in drive Z is SYSTEM
 Volume Serial Number is 8C2A-4E1D

 Directory of Z:\EFI\Microsoft\Boot

01/15/2026  10:32 AM    <DIR>          .
01/15/2026  10:32 AM    <DIR>          ..
01/15/2026  10:32 AM           1,048,576 bootmgfw.efi
01/15/2026  10:32 AM              12,288 BCD

Що це означає: Ключові файли присутні. Якщо їх немає — ESP був не тим, що ви думали, або копіювання завершилося помилкою через права/файлову систему.

Рішення: Якщо файли є, а Windows все одно не завантажується — ймовірна проблема з NVRAM-записом, Secure Boot/shim або вимогами BitLocker до відновлення, а не з відсутністю файлів.

Завдання 13: З Linux перевірте, чи випадково Windows встановлена в BIOS-режимі (виявлення змішаних режимів)

cr0x@server:~$ sudo parted -l | sed -n '1,120p'
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  106MB   105MB   fat32              boot, esp
 2      106MB   123MB   16.8MB                     msftres
 3      123MB   512GB   512GB   ntfs               msftdata

Що це означає: Цей диск GPT з ESP. Це узгоджується з UEFI Windows. Якщо бачите MBR («msdos») і «active» NTFS-розділ без ESP — це legacy Windows.

Рішення: Підбирайте стратегію ремонту з урахуванням того, що реально є на диску. Не намагайтеся «перетворити BIOS-інсталяцію на UEFI» під час інциденту, якщо ви не готові до більшого простою.

Завдання 14: У WinRE позначте правильний розділ як активний (тільки для BIOS/MBR)

cr0x@server:~$ diskpart
DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB  1024 KB

DISKPART> sel disk 0
Disk 0 is now the selected disk.

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            500 MB  1024 KB
  Partition 2    Primary            475 GB   501 MB

DISKPART> sel part 1
Partition 1 is now the selected partition.

DISKPART> active
DiskPart marked the current partition as active.

DISKPART> exit

Що це означає: Ви позначили розділ як активний, щоб BIOS-завантаження знало, куди дивитися далі. На GPT/UEFI це не має значення і може вводити в оману.

Рішення: Робіть це тільки якщо впевнені в MBR/Legacy режимі. Якщо диск GPT — відійдіть від команди active.

Шлях A: UEFI + GPT (більшість сучасних систем)

Якщо у вас UEFI (а більшість машин після ~2012 року такі), поводьтеся з ESP як зі спільною інфраструктурою. Мета — відновити Windows Boot Manager на ESP і NVRAM-запис, що на нього вказує.

Крок 1: Увійдіть у WinRE Command Prompt

Використайте Windows installation USB або recovery media. Оберіть «Repair your computer» → «Troubleshoot» → «Command Prompt». Якщо розкладка клавіатури неправильна — виправте це на початку; вводити ключі відновлення з неправильною розкладкою — комедія, якої краще уникнути.

Крок 2: Ідентифікуйте ESP і розділ Windows

Використовуйте diskpart, list vol. ESP буде FAT32, маленький (100–550MB типово) і позначений «System». Розділ Windows зазвичай великий і NTFS.

Крок 3: Призначте літери і запустіть bcdboot

Це найчистіший UEFI-ремонт у світі Windows: він копіює файли завантаження в ESP і створює BCD для вказаної інсталяції.

cr0x@server:~$ diskpart
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     C   Windows      NTFS   Partition    475 GB  Healthy    Boot

DISKPART> sel vol 1
Volume 1 is the selected volume.

DISKPART> assign letter=Z
DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

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

Що ви щойно зробили: Ви сказали Windows: «Використай інсталяцію Windows у C:\Windows, поклади її файли завантаження на Z: (ESP) і зроби їх сумісними з UEFI.»

Крок 4: Підтвердіть файли на ESP

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

Крок 5: Виправте порядок завантаження прошивки, якщо потрібно

Якщо машина все ще стартує в GRUB за замовчуванням, можливо, вона просто вибирає запис ubuntu першим. Переупорядкуйте в налаштуваннях прошивки, або з Linux за допомогою efibootmgr.

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* Windows Boot Manager
Boot0001* ubuntu

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

Secure Boot і реалії shim

Secure Boot ускладнює dual-boot, бо прошивка дозволяє запускати лише підписані EFI-бінарники. Багато дистрибутивів Linux використовують підписаний shim (shimx64.efi), який потім завантажує GRUB. Windows користується підписаним Microsoft boot manager. Якщо ви заміните файли на непідписані бінарники або спробуєте chainload з невідповідними компонентами, Secure Boot заблокує запуск.

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

Шлях B: Legacy BIOS + MBR

Це для старіших систем або систем, навмисно налаштованих на legacy-режим. Тут ваші цілі: код MBR, завантажувальний сектор активного розділу і сховище BCD.

Крок 1: Переконайтеся, що ви справді в BIOS/MBR режимі

В diskpart колонка «Gpt» для системного диска буде пуста. Також зазвичай має значення концепт «active» розділу.

Крок 2: Ідентифікуйте System Reserved (або розділ завантаження)

Типовий макет: 100–500MB NTFS розділ з міткою «System Reserved», що містить \Boot\BCD. Якщо його нема — файли завантаження можуть бути на C: (неідеально, але буває).

Крок 3: Позначте правильний розділ активним

На MBR-диску має бути лише один активний розділ. Якщо Linux-інструменти його поміняли, BIOS завантажуватиме «не те».

Крок 4: Відновіть MBR і завантажувальний сектор (точно)

cr0x@server:~$ bootrec /fixmbr
The operation completed successfully.

cr0x@server:~$ bootrec /fixboot
The operation completed successfully.

Що це означає: Код MBR і завантажувальний сектор розділу записано. Якщо /fixboot повертає «Access is denied», можливо, потрібно призначити літеру системному розділу і запустити bootsect або bcdboot, залежно від версії Windows і макету дисків.

Крок 5: Реконструюйте BCD

cr0x@server:~$ bootrec /rebuildbcd
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  C:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): y
The operation completed successfully.

Рішення: Якщо /rebuildbcd знаходить нуль інсталяцій — зупиніться і з’ясуйте, чому Windows не видно (драйвери, BitLocker, пошкоджений NTFS).

Крок 6: Віддавайте перевагу bcdboot, коли BCD переплутано

У багатьох випадках, особливо з дивною історією розбиття розділів, bcdboot є більш детермінованим, ніж bootrec /rebuildbcd. Ви вкажете Windows, а вона створить те, що потрібно на системному розділі.

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

Примітка: Тут S: — це System Reserved, якому ви призначили літеру. Не гадайте — підтверджуйте dir S:\Boot.

Другий короткий жарт (і на цьому все): MBR означає «Mostly Bad Regrets», коли ви запускаєте fixmbr на неправильному диску.

Післядогляд: як утримати dual-boot стабільним

Зробіть ESP нудним знову

ESP — це спільний стан. Спільний стан заслуговує на повагу: робіть резервну копію (принаймні директорії EFI), тримайте його маленьким і чистим, і не монтуйте його для запису в Linux, якщо ви не робите це свідомо.

Визначте, хто відповідає за «завантаження за замовчуванням»

Виберіть одне:

• Windows Boot Manager як за замовчуванням, і використовуйте меню прошивки, щоб запускати Linux за потреби.
• GRUB як за замовчуванням, і chainload-те Windows. Це зручніше для тих, хто насамперед працює на Linux, але може порушуватися оновленнями прошивки або Windows.

Чого варто уникати: ситуації, коли Windows щокварталу скидає порядок завантаження і ви постійно його виправляєте. Це не dual-boot; це сезонний розлад настрою.

BitLocker: призупиняйте перед великими змінами завантаження

Якщо ви використовуєте BitLocker, подумайте про тимчасове призупинення захисту перед суттєвими змінами завантажувача (оновлення прошивки, відтворення ESP, значні зміни розділів), а потім знову увімкніть після підтвердження чистого завантаження. Це зменшить несподівані запити ключа відновлення.

Системи з кількома дисками: чітко визначте, де живе ESP

Якщо у вас два диски (наприклад, NVMe для Windows, SATA SSD для Linux), є два варіанти, що працюють:

• Один спільний ESP на одному диску (просто, але зв’язує диски між собою).
• Окремий ESP на кожному диску (стійкіше, але вимагає уважних записів прошивки і дисципліни інсталяторів).

Що не працює: вірити, що інсталятор «зробить очевидне». Інсталятори роблять перше, що вони бачать.

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

1) Симптом: «No bootable device» після встановлення Linux

Корінь: Порядок завантаження прошивки змінився або NVRAM-запис Windows Boot Manager було видалено/перезаписано.

Виправлення: Використовуйте налаштування прошивки, щоб обрати Windows Boot Manager; якщо його немає — виконайте bcdboot C:\Windows /s Z: /f UEFI після монтування ESP.

2) Симптом: Завантажується прямо в GRUB, Windows відсутня у меню

Корінь: Конфіг GRUB не виявляє Windows або файли Windows Boot Manager відсутні на ESP.

Виправлення: Переконайтесь, що файли Windows на ESP; якщо ні — відновіть через bcdboot. Якщо є — відновіть конфіг GRUB з Linux (залежить від дистрибутива) або використайте меню прошивки для запуску Windows.

3) Симптом: GRUB prompt (grub>) або «minimal BASH-like line editing»

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

Виправлення: Якщо ваша мета — повернути Windows, не боріться з GRUB спершу. Завантажте WinRE і відновіть Windows bootloader як за замовчуванням; потім відновіть GRUB з Linux, коли будете готові.

4) Симптом: Windows Boot Manager з’являється, але далі — синій екран

Корінь: Не обов’язково пов’язано з завантажувачем. Може бути зміна драйверів сховища, пошкодження файлової системи або невдале оновлення Windows.

Виправлення: Запустіть chkdsk з WinRE; розгляньте sfc/dism для ремонту (поза сферою суто завантажувальних виправлень). Ремонт завантажувача не вилікує пошкоджене ядро чи драйвери.

5) Симптом: «Boot configuration data file is missing» або помилки BCD

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

Виправлення: Для UEFI змонтуйте ESP і запустіть bcdboot. Для BIOS переконайтеся, що активний розділ правильний і виконайте bcdboot ... /f BIOS або bootrec /rebuildbcd.

6) Симптом: «Access is denied» на bootrec /fixboot

Корінь: Часто у WinRE Windows 10/11 через права на розділ або неправильний цільовий розділ.

Виправлення: Використовуйте bcdboot для відтворення файлів на правильний розділ. Якщо BIOS/MBR — переконайтеся, що System Reserved має літеру і позначений як active.

7) Симптом: Windows запитує ключ BitLocker після ремонту завантаження

Корінь: TPM виміри змінилися, бо ланцюжок завантаження змінився (новий EFI-бінар, інший шлях, інший запис завантаження).

Виправлення: Введіть ключ відновлення, завантажтеся успішно, потім призупиніть і знову увімкніть BitLocker, щоб «навчити» TPM новому стану завантаження.

8) Симптом: Ремонт пройшов один раз, потім зламався після оновлення прошивки

Корінь: Оновлення прошивки скинуло порядок завантаження або видалило NVRAM-записи.

Виправлення: Відтворіть записи через bcdboot (Windows) або efibootmgr (Linux). Тримайте вміст ESP стабільним і в резерві.

9) Симптом: Все виглядає правильно, але запис Windows Boot Manager вказує на неправильний диск

Корінь: Система з кількома дисками; файли завантаження створено на диску A, а запис прошивки вказує на диск B (або навпаки).

Виправлення: Ідентифікуйте ESP, який використовує прошивка; відтворіть файли там через bcdboot. За потреби приберіть застарілі записи і стандартизуйте конфігурацію.

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

Інцидент №1: Неправильне припущення (казка «є лише один ESP»)

Середня компанія мала робочі станції з dual-boot: Windows для корпоративних інструментів, Linux для збіркових конвеєрів. Нова партія обладнання прийшла з двома дисками в кожній машині: маленький NVMe і більший SATA SSD. Процес знімкування встановив Windows на NVMe. Linux пішов на SATA.

Команда припустила, що ESP лежить на диску Windows. Розумно. Але помилково. Інсталятор Linux, працюючи в поспіху, знайшов існуючий ESP на SATA (залишок від тестового образу вендора) і використав його. Тож машина мала два ESP, і який з них віддає перевагу прошивка залежав від тонких нюансів порядку перелічення дисків.

Інцидент проявився як «Windows час від часу зникає». Після оновлень або вимкнень половина парку завантажувалася в GRUB без опції Windows; інша половина — нормально в Windows. Всі звинувачували оновлення Windows, бо так заведено, коли відчуваєш себе безсилим.

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

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

Інша організація мала звичку «підтискати» розділи, щоб максимізувати доступний простір. Хтось помітив 500MB ESP і вирішив, що це марнотратно. Він звів його до 100MB, бо «це лише файли завантаження».

Працювало. Деякий час. Потім рутинне оновлення Linux додало нові ядра і кілька EFI-артефактів. Оновлення Windows також оновлювали компоненти завантаження. ESP тихо заповнювався, бо система моніторингу не відстежувала «вільне місце на ESP», так само як ніхто не стежить за вільним місцем у кухонній шафі.

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

Урок простий: ставтеся до ESP як до спільного конфігураційного тому з запасом. Заощадити кількасот мегабайт на диску розміром у сотні гігабайт — це вимірювання, а не операційна майстерність.

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

Фінансова компанія мала dual-boot на кількох спеціалізованих ноутбуках для тестування обладнання. SRE команда не любила це, але погодилася з правилами. Одна з таких правил — щоквартальна «снімок ESP»: завантажитись в Linux, змонтувати ESP в режимі тільки для читання коли можливо, і заархівувати директорію EFI в зашифроване внутрішнє сховище.

Одного дня оновлення прошивки скинуло NVRAM-записи, і машина перейшла на нерабочий шлях. Оператор не зміг завантажити Windows, а Linux стартував нестабільно. Ніхто не панікував. Вони завантажили Linux live USB, змонтували ESP, порівняли її з останнім відомо-робочим архівом і відновили відсутні директорії. Потім відтворили записи завантаження.

З того, що могло стати всеосяжним «вихід з ладу ноутбуків», вийшов контрольований ремонт за 40 хвилин. Без втрати даних, без драми й нічних героїчних дій. Практика не була хитрою; вона була послідовною.

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

Чекліст 1: Перш ніж торкатися чогось (засоби безпеки)

1. Підтвердіть, чи Windows UEFI чи BIOS. Використайте diskpart (зірочка Gpt) і перевірку наявності ESP.
2. Зробіть запис поточного розподілу дисків/розділів. Скриншоти або нотатки з list disk, list vol.
3. Якщо BitLocker увімкнений, переконайтеся, що маєте ключ відновлення. Якщо ні — призупиніться.
4. На системах з кількома дисками ідентифікуйте, який диск прошивка завантажує першим. «Disk 0» у Windows не завжди той, який обирає прошивка.

Чекліст 2: Мінімальний ремонт для UEFI-систем (рекомендований за замовчуванням)

1. Завантажтесь у WinRE Command Prompt.
2. Запустіть diskpart → list vol, знайдіть FAT32 «System» (ESP).
3. Призначте ESP літеру (наприклад, Z:).
4. Підтвердіть літеру розділу Windows (C: або інша) перевіркою \Windows.
5. Запустіть bcdboot <WinLetter>:\Windows /s Z: /f UEFI.
6. Перезавантажтесь і оберіть Windows Boot Manager у меню прошивки.
7. Якщо потрібно, змініть порядок записів у прошивці або за допомогою efibootmgr в Linux.

Чекліст 3: Мінімальний ремонт для BIOS/MBR-систем

1. Завантажтесь у WinRE Command Prompt.
2. diskpart → підтвердіть відсутність зірочки Gpt для системного диска.
3. Знайдіть System Reserved; призначте літеру (S:).
4. Позначте System Reserved як active.
5. Запустіть bootrec /fixmbr і bootrec /fixboot.
6. Запустіть bootrec /rebuildbcd або bcdboot C:\Windows /s S: /f BIOS.
7. Перезавантажтесь і перевірте результат.

Чекліст 4: Якщо потрібно зберегти Linux також

1. Після того, як Windows завантажується, вирішіть, хто буде відповідати за завантаження за замовчуванням (Windows Boot Manager або GRUB).
2. Якщо GRUB було перезаписано або втрачено — відновіть GRUB з Linux (залежить від дистрибутива), щоб повернути меню dual-boot.
3. Збережіть копію вмісту ESP після стабілізації.
4. Задокументуйте обраний ESP і порядок завантаження, щоб майбутній ви не переучувалися цьому уроку.

Питання й відповіді (FAQ)

1) Чи безпечно запускати bcdboot? Чи видалить це Linux?

На UEFI-системах bcdboot записує файли Windows на ESP і оновлює конфігурацію завантаження Windows. Воно зазвичай не видаляє Linux, але якщо ESP дуже малий і заповнений, або пізніше ви «очистите» директорії, можна порушити Linux. Використовуйте bcdboot, але перевірте вільне місце на ESP і не видаляйте каталоги інших постачальників.

2) Чи варто вимикати Secure Boot, щоб виправити dual-boot?

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

3) Чому Windows постійно перехоплює порядок завантаження?

Оновлення Windows і деякі оновлення прошивки можуть скидати NVRAM-порядок на користь Windows Boot Manager. Це не особисто; так виробники прагнуть підтримуваності. Якщо хочете Linux-першим, плануйте періодичне відновлення GRUB як дефолту або користуйтеся меню прошивки для запуску Linux.

4) Мій ESP відсутній. Чи можна створити новий?

Так, але це не найшвидше рішення. Створення нового ESP включає зміну розділів, форматування FAT32, установлення правильного GPT-типу/флагів, потім використання bcdboot для наповнення і efibootmgr/прошивки для реєстрації. Робіть це лише коли оригінальний ESP невідновний.

5) Що якщо bootrec /scanos знаходить нуль інсталяцій Windows?

Це проблема видимості, а не «завантажувача». Типові причини: том заблокований BitLocker, відсутні драйвери сховища (RAID/VMD) або пошкоджений NTFS. Розблокуйте том, завантажте потрібні драйвери і підтвердіть читабельність розділу Windows перед реконструкцією BCD.

6) Чи можна відновити завантажувач Windows тільки з Linux?

Іноді ви можете відновити відсутні EFI-файли, якщо маєте відомо-робочу копію, і створити NVRAM-записи через efibootmgr. Але найбільш надійний спосіб згенерувати коректні файли Windows/BCD — це bcdboot з WinRE.

7) Чи ризикує відновлення завантажувача втратою даних?

Більшість ремонтів — це зміни метаданих і запис невеликих файлів на ESP або системному розділі. Реальний ризик втрати даних виникає при помилках розділювання (форматування непотрібного розділу, зміна розміру невірного диска, «очищення» розділів). Дійте мінімально і перевіряйте цілі кожної команди.

8) Я бачу кілька записів «Windows Boot Manager» у прошивці. Який з них справжній?

Ласкаво просимо у світ мульти-дисків. Кожен запис вказує на конкретний диск/розділ/шлях файлу. Використайте efibootmgr -v у Linux, щоб побачити, який запис вказує на ESP з \EFI\Microsoft\Boot\bootmgfw.efi. Видаляйте застарілі записи лише після підтвердження стабільного завантаження.

9) Чи варто перевстановлювати Windows замість ремонту?

Тільки якщо том ОС пошкоджено настільки, що відновити неможливо, або ви вже планували перевстановлення. Проблеми із завантажувачем зазвичай вирішуються за годину; перевстановлення — ризикованіше і триваліше, люди обирають його, бо це відчуття рішучості.

Наступні кроки (практичний план)

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

1. Визначте, UEFI чи BIOS за допомогою diskpart і наявності ESP.
2. Для UEFI: змонтуйте ESP, запустіть bcdboot, підтвердіть файли і виправте порядок завантаження.
3. Для BIOS/MBR: позначте правильний активний розділ, відновіть MBR/завантажувальний сектор, реконструюйте BCD.
4. Перезавантажтесь один раз і перевірте. Якщо не вдалось — зберіть точну помилку і переосмисліть, який рівень ще залишається зламаним.
5. Після успішного завантаження стабілізуйте dual-boot: визначте дефолтного власника завантаження, задокументуйте місце ESP і збережіть невелику резервну копію ESP.

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