GPT проти MBR: обереш неправильно — зламається завантаження. Обирай правильно за цим правилом

February 11, 2026 • February 11, 2026 • Читання: 7 хв • Views: 0

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

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

Це тип відмови, який виглядає як проблема зі сховищем, відчувається як проблема завантажувача і фактично є проблемою вибору. Хороша новина: можна припинити гадати. Існує просте правило для вибору GPT чи MBR, що запобігає більшості катастроф при завантаженні — плюс набір перевірок, які точно скажуть, з чим ви маєте справу, перш ніж щось чіпати.

Правило: не «обирайте», узгоджуйте прошивку й режим завантаження

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

Якщо машина завантажена у режимі UEFI — використовуйте GPT. Створіть EFI System Partition (ESP) і встановіть туди завантажувач.
Якщо машина завантажена в режимі legacy BIOS — використовуйте MBR. Або використовуйте GPT з BIOS boot partition тільки якщо точно знаєте, навіщо це робите (далі про це буде більше).

Це правило — не ідеологія. Йдеться про узгодження першого виконуваного коду, який прошивка очікує знайти, з розміткою диска. Коли вони не співпадають, ви не отримуєте «попередження». Ви отримуєте «немає завантажувального пристрою», GRUB rescue або вікно відновлення Windows, яке робить вигляд, ніби ніколи не бачило вашу ОС.

Є ще одна обмежувальна умова, що важить більше за особисті вподобання: якщо диск більший за 2 TB і вам потрібно використовувати весь обсяг на одному диску, MBR відпадає. Ви все ще можете завантажувати BIOS з GPT-диска, але це має бути усвідомленим вибором.

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

Що насправді ламається, коли обирають неправильно

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

MBR: чого він очікує

MBR-завантаження зазвичай очікує:

На LBA0 диска має бути дійсний MBR з виконуваним кодом завантаження і таблицею розділів.
Розділ, позначений як «active/bootable» (для класичних BIOS-сценаріїв).
Завантажувальний код, який завантажує другий етап з відомого місця (наприклад, файли GRUB чи Windows boot manager).

Якщо ви клонували GPT-диск на MBR (або навпаки) і забули про завантажувальний код, ви можете скопіювати 100% файлів і все одно отримати мертву ланку завантаження.

GPT: чого він очікує

GPT-завантаження залежить від прошивки:

UEFI + GPT: прошивка читає GPT, знаходить ESP (FAT32), завантажує EFI-виконавчий файл за шляхом, записаним у NVRAM або через запасні (fallback) шляхи.
BIOS + GPT: BIOS не може читати GPT-розділи так, як UEFI; GRUB використовує маленький BIOS boot partition для збереження свого core-образу.

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

Одна цитата, щоб не забувати реальність: «Hope is not a strategy.» — General Gordon R. Sullivan. Це не з операційних цитат спочатку, але щодня точно відображає суть у операціях.

Цікаві факти та історія, які допоможуть у рішеннях

Це не факти для вікторини. Вони пояснюють, чому інструменти поводяться так, як поводяться, і навіщо існують деякі «дивні» розділи.

MBR походить з ранньої ери PC і використовує 32-бітну адресацію для підрахунку секторів, через що класичний ліміт опиняється близько 2 TB при 512-байтових секторах.
GPT був визначений як частина специфікації UEFI щоб замінити MBR, а не просто «розширити» його. Він призначений для сучасної прошивки і великих дисків.
GPT зберігає резервний заголовок і масив розділів у кінці диска. Це не теоретично — коли первинний заголовок пошкоджений через невдале клонування, часто можна відновитися з резервного.
GPT містить CRC для заголовків і записів розділів. Інструменти можуть виявляти корупцію замість того, щоб мовчки продовжувати з абракадаброю.
«Protective MBR» існує на GPT-дисках щоб старі MBR-утиліти не бачили диск як «порожній» і не перезаписали його. Це одночасно пастка сумісності і захисна функція.
UEFI не «завантажує розділ», а завантажує EFI-виконуваний файл. Тому ви можете мати кілька завантажувачів ОС на одній ESP без покладання на прапор «active».
Windows історично використовувала маленький розділ «System Reserved» у BIOS/MBR-інсталяціях для зберігання файлів завантаження і метаданих BitLocker, що плутає процес клонування і питання «чому C: не завантажується?».
Багато систем постачаються з UEFI-прошивкою, налаштованою на сумісність «Legacy/CSM». Та сама машина може завантажуватися в двох сумісних режимах залежно від одного перемикача в прошивці.
«BIOS boot partition» — це тип GPT-розділу, який використовується переважно для GRUB на BIOS-системах. Він дуже малий (зазвичай 1–2 MiB) і виглядає безглуздо, доки він не стане потрібен.

Моделі завантаження, що мають значення: BIOS+MBR, BIOS+GPT, UEFI+GPT, UEFI+MBR

UEFI + GPT (сучасний стандарт, якого варто дотримуватися)

Це поєднання, яке викликає найменше проблем при правильній конфігурації.

Схема розділів: GPT
Обов’язково: EFI System Partition (FAT32), зазвичай 100–550 MiB залежно від дистрибутиву/вендора
Розташування завантажувача: \EFI\…\*.efi на ESP
Стан прошивки: режим UEFI (не legacy)

Режим відмови: ви клонували розділ ОС, але не ESP, або відтворили ESP, але не відновили NVRAM-записи. Диск «виглядає в порядку», але прошивка не знає, що завантажувати.

BIOS + MBR (досі поширено в деяких пристроях і старих парках)

Це поєднання ви обираєте при роботі зі старою прошивкою, деякими гіпервізорами налаштованими на legacy boot або корпоративними образами, які не оновлювалися.

Схема розділів: MBR
Обов’язково: код завантаження в MBR, активний розділ у багатьох налаштуваннях
Обмеження: адресація до ~2 TB на один диск, 4 первинні розділи без extended/logical

Режим відмови: хтось конвертував у GPT «для сучасності» і забув, що BIOS не зможе завантажити без підходу GRUB з BIOS-boot partition.

BIOS + GPT (працює, але має бути усвідомленим вибором)

BIOS не розуміє GPT так, як UEFI. Але завантажувачі на кшталт GRUB можуть зробити це можливим за рахунок спеціального BIOS boot partition.

Схема розділів: GPT
Обов’язково: малий BIOS boot partition (тип EF02 в термінах gdisk), зазвичай 1–2 MiB, неформатований
Випадок використання: завантаження BIOS-систем з дисків >2 TB або уніфікована GPT-розмітка у всьому парку

Режим відмови: відсутній BIOS boot partition або диск без проміжку після MBR для вбудовування core-образу GRUB.

UEFI + MBR (можливо, але це пастка)

Деякі UEFI-прошивки можуть завантажувати з MBR, але поведінка між вендорами непослідовна. Якщо хочете передбачуваності: не робіть цього.

Схема розділів: MBR
Може бути: FAT-подібний розділ схожий на ESP, але це не стандарт у тому ж сенсі
Краща практика: якщо ви в режимі UEFI — використовуйте GPT

Другий короткий жарт: UEFI+MBR — як носити краватку з шортами для занять спортом — технічно одяг, але практично червоний прапор.

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

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

Task 1: Check whether you booted in UEFI mode (Linux)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Значення: Якщо ви бачите UEFI, ядро було завантажене через UEFI. Якщо BIOS, ви в режимі legacy.

Рішення: У режимі UEFI — орієнтуйтесь на GPT і переконайтесь, що ESP існує і змонтована в /boot/efi (або відповідному шляху дистрибутива). У BIOS-режимі не припускайте, що GPT завантажиться, якщо ви не підготували BIOS+GPT.

Task 2: Identify the partition table type on a disk

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

Значення: Partition Table: gpt або msdos (parted називає MBR «msdos»).

Рішення: Порівняйте це з режимом завантаження. UEFI+msdos викликає підозру. BIOS+gpt вимагає перевірки наявності BIOS boot partition і методу встановлення GRUB.

Task 3: Inspect block devices and mountpoints at a glance

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,PARTTYPENAME,MOUNTPOINTS /dev/sda
NAME   SIZE TYPE FSTYPE FSVER PARTTYPENAME                  MOUNTPOINTS
sda    953G disk
├─sda1  512M part vfat   FAT32 EFI System                   /boot/efi
├─sda2    1G part ext4         Linux filesystem             /boot
└─sda3  952G part ext4         Linux filesystem             /

Значення: Ви бачите ESP (vfat, «EFI System»), плюс стандартні Linux-розділи.

Рішення: Якщо очікується UEFI і ви не бачите змонтованого ESP — виправте це перед будь-якими іншими діями.

Task 4: Confirm the ESP is really FAT32 and has EFI files

cr0x@server:~$ sudo find /boot/efi/EFI -maxdepth 2 -type f -name '*.efi' | head
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/shimx64.efi

Значення: Існують EFI-виконавчі файли. Якщо цей каталог порожній або відсутній, ймовірно ви клонували тільки кореневу файлову систему, а не шлях завантаження.

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

Task 5: Check UEFI NVRAM boot entries

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: Built-in EFI Shell	...
Boot0002* UEFI: PXE IPv4 Intel(R)	...
Boot0003* ubuntu	HD(1,GPT,7b2c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Значення: Прошивка знає, де ваш завантажувач на диску. Якщо запис ОС відсутній, прошивка може перейти на PXE або shell.

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

Task 6: Detect “GPT header not at end of disk” after cloning to a larger disk

cr0x@server:~$ sudo sgdisk -v /dev/sda
Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk.
Problem: The secondary header is placed too early on the disk.
No problems found. 1000 free sectors (500.0 KiB) available in 1 segments, the largest of which is 1000 (500.0 KiB) in size.

Значення: Поширена ситуація після клонування диска на більший диск: резервний GPT-заголовок все ще знаходиться на кінці старого диска.

Рішення: Виправте метадані GPT перед зміною розмірів розділів/файлових систем. Зазвичай виправляють перенесенням резервного заголовка командою sgdisk -e.

Task 7: Repair GPT backup header location

cr0x@server:~$ sudo sgdisk -e /dev/sda
The operation has completed successfully.

Значення: Резервний GPT-заголовок переміщено в фактичний кінець диска.

Рішення: Перезапустіть sgdisk -v для перевірки чистого стану, потім продовжуйте з операціями зміни розмірів.

Task 8: Check whether BIOS boot partition exists on BIOS+GPT

cr0x@server:~$ sudo parted -s /dev/sda print
Model: ATA ST4000NM000 (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3146kB  2097kB               grub  bios_grub
 2      3146kB  1077MB  1074MB  ext4               boot
 3      1077MB  4001GB  4000GB  ext4               root

Значення: Прапорець bios_grub вказує на BIOS boot partition, необхідний GRUB для BIOS-на-GPT.

Рішення: Якщо ви завантажуєтеся через BIOS з GPT-диска і цього розділу немає — створіть його перед перевстановленням GRUB, інакше «встановлення» буде ні до чого.

Task 9: Confirm which disk GRUB thinks it’s installed to (Linux)

cr0x@server:~$ sudo grub-probe -t device /boot
/dev/sda2

Значення: Показує, який блочний пристрій підтримує /boot.

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

Task 10: Reinstall GRUB for BIOS systems (carefully)

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

Значення: GRUB встановлено в режимі BIOS/MBR на диск. На BIOS+GPT це все одно використовує BIOS boot partition, якщо він присутній.

Рішення: Виконуйте це тільки після підтвердження режиму завантаження. Встановлення i386-pc на UEFI-системі не створить робочий UEFI-запис.

Task 11: Reinstall GRUB for UEFI systems

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

Значення: EFI-байти GRUB встановлено в ESP і зазвичай створено запис у NVRAM.

Рішення: Якщо efibootmgr все ще не показує запис після цього, прошивка може блокувати запис (поширено у деяких віртуальних платформах) або NVRAM заповнений; використайте fallback-путь або очистьте старі записи.

Task 12: Validate MBR 2 TB limitations on a large disk

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,12p'
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2a3b4c5d

Значення: Диск ~3.64 TiB, але таблиця розділів — «dos» (MBR). Ви не зможете адресувати весь диск класичною MBR-розміткою.

Рішення: Конвертуйте в GPT, якщо потрібен весь простір. Якщо це диск для завантаження, також переконайтеся, що прошивка/режим завантаження підтримують цільовий метод.

Task 13: Check for the “active” boot flag in MBR setups

cr0x@server:~$ sudo fdisk -l /dev/sda | sed -n '1,25p'
Disklabel type: dos

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1  *     2048   1050623   1048576  512M 83 Linux
/dev/sda2     1050624 500118191 499067568  238G 83 Linux

Значення: * вказує на активний розділ. Деякі BIOS/шляхи завантаження очікують його.

Рішення: Якщо BIOS/MBR система говорить «no bootable device» після редагування розділів, перевірте, чи не був знятий прапорець завантаження.

Task 14: See what your initramfs/boot config references (UUID mismatches after cloning)

cr0x@server:~$ grep -E 'UUID=|PARTUUID=' /etc/fstab
UUID=9f2e8d1a-0e2b-4c3a-9c36-2d2a3d0c1f1b / ext4 defaults 0 1
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

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

Рішення: Якщо завантаження падає в initramfs зі словами, що не може знайти root — порівняйте ці UUID зі виводом blkid і виправте /etc/fstab або реконструюйте initramfs.

Task 15: Confirm filesystem UUIDs and partition identifiers

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda2 /dev/sda3
/dev/sda1: UUID="1A2B-3C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="7b2c..."
/dev/sda2: UUID="d0c1..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f10..."
/dev/sda3: UUID="9f2e..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8aa1..."

Значення: Підтверджує, що система повинна монтувати і що GRUB/ядро можуть посилатися на ці ідентифікатори.

Рішення: Якщо /etc/fstab посилається на старий UUID — оновіть його. Якщо GRUB посилається на неправильний UUID — згенеруйте конфіг і перевстановіть його.

Task 16: Spot “legacy vs UEFI” mismatch inside GRUB config

cr0x@server:~$ sudo file /boot/grub/i386-pc/core.img
/boot/grub/i386-pc/core.img: GRUB2 core image, i386-pc, ...

Значення: Це вказує, що існують артефакти GRUB, націлені на BIOS. На чисто UEFI-настроєній системі ви очікували б EFI-байти в ESP замість покладання на i386-pc.

Рішення: Якщо прошивка — UEFI, але система була встановлена в BIOS-режимі, вирішіть, чи конвертуєте режим завантаження (перерозмітка/ESP), чи зберігаєте legacy. Змішування — це шлях до 2:00 ранкових інцидентів.

Швидкий план діагностики: що перевіряти першим/другим/третім

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

Першим: підтвердьте режим завантаження і узгодженість таблиці розділів

Перевірте режим завантаження: існує /sys/firmware/efi?
Перевірте таблицю розділів: GPT чи MBR?
Перевірте наявність ESP (UEFI) або активного розділу / BIOS boot partition (сценарії legacy).

Причина: Якщо UEFI увімкнено, а диск MBR без ESP/NVRAM-записів, або BIOS увімкнено, а диск GPT без BIOS boot partition — ваш «ремонт файлової системи» буде декоративним.

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

UEFI: чи містить ESP \EFI\...\*.efi?
UEFI: чи показує efibootmgr -v запис, що вказує на цей файл?
BIOS: чи встановлено GRUB на правильний диск (не тільки в розділ)? Чи є код у MBR?

Третім: перевірте передачу керування ОС (ядро + ідентифікація root)

Чи скаржиться initramfs на відсутній root? Це UUID/PARTUUID-невідповідність або відсутні драйвери.
Чи потрапляє в GRUB rescue? Це зазвичай відсутність /boot, неправильний диск або пошкоджене вбудовування.
Чи стартує Windows boot manager, але ОС не завантажується? Це проблема BCD/шляху пристрою або зміни режиму контролера дисків.

Швидка ідентифікація вузького місця

Якщо підсумувати:

Немає завантажувального пристрою / екран прошивки: прошивка не може знайти завантажувач (ESP/NVRAM/несумісність коду MBR).
Підказка GRUB/rescue: завантажувач стартував, але не може знайти свій конфіг або модулі (неправильні ID розділів, відсутній /boot).
Kernel panic / initramfs shell: ОС стартувала, але не може змонтувати root (UUID mismatch, відсутні драйвери RAID/LVM тощо).

Три корпоративні міні-історії (і чого вони навчають)

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

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

Старий хост завантажувався в legacy BIOS (MBR). Новий хост постачався з UEFI ввімкненим за замовчуванням. Клон скопіював розділи і файлові системи бездоганно. Він також скопіював ланцюжок завантаження, що виходив з припущення MBR і активного розділу, на систему, прошивка якої шукала ESP і EFI-виконавчий файл.

Після перезавантаження: відразу в прошивку. Немає запису завантаження. Жодних очевидних помилок. On-call почав перевіряти здоров’я RAID і SMART, бо «не бачить диск». Диск був у порядку. Прошивка не знала, що з ним робити.

Виправлення було стидливо просте: або переключити прошивку в legacy/CSM (неідеально), або виконати правильний шлях UEFI+GPT — GPT-розмітка, створити ESP, перевстановити завантажувач, створити запис NVRAM. Вони обрали другий варіант і стандартизували збірку так, щоб визначати режим завантаження і розмічати диск відповідно.

Висновок: ніколи не припускайте, що режим завантаження переноситься між поколіннями апаратури. Перевіряйте явно і закладайте це в автоматизацію.

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

Група платформи хотіла прискорити розгортання. Вони вирішили попередньо збирати «золоті» образи як raw-образи диска і записувати їх безпосередньо на диски нових серверів. Було швидко. Це також тихо впровадило розмітку розділів і конфіг завантаження, що працювали тільки під однією конкретною конфігурацією прошивки.

Оптимізація була «ми будемо використовувати GPT скрізь, бо це сучасно». Добрий інстинкт. Проблема була в тому, що частина їхнього парку — старі стійки та деякі периферійні пристрої — все ще завантажувалася в BIOS-режимі, і не всі мали надійний BIOS+GPT-процес. Деяким потрібен був BIOS boot partition. Деякі мали прошивкові особливості. Деякі завантажувалися тільки коли диск мав певну MBR-структуру.

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

Вони «виправили» шляхом створення множинних образів і дозволили технікам обирати потрібний. Це зробило процес повільнішим і все одно помилковим. Реальне виправлення — перестати ставитися до режиму завантаження як до післямови: опитуйте платформу (UEFI чи BIOS), підбирайте правильний рецепт розмітки/завантажувача і генеруйте розмітки динамічно. Золотий образ став артефактом файлової системи, а не блобом диска.

Висновок: дискові образи швидкі, поки не стають такими. Якщо ваш парк неоднорідний, статичні дискові блоби — податок на надійність.

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

Команда, що працювала поруч з фінансами, мала політику, яка дратувала всіх: перед будь-якою міграцією чи зміною розмірів диска вони знімали невеликий «пакет фактів завантаження» — режим завантаження, тип таблиці розділів, lsblk, і якщо UEFI — efibootmgr -v. Це займало дві хвилини й виглядало як паперова тяганина.

Одного кварталу вони перенесли навантаження зі старих SSD на нові диски. Інструмент вендора виконав клон і змінив розмір останнього розділу. Розділ ОС виглядав у порядку, але після перезавантаження система опинилася в GRUB rescue. Паніка, бо вікно змін було коротким і система була «доволі критичною».

Заздалегідь зібрані факти показали тонку деталь: старий диск мав ESP змонтований у /boot/efi з певним шляхом вендора, і запис завантаження посилався на конкретний PARTUUID розділу. Після клонування ESP був, але не змонтований; інструмент клонування змінив PARTUUID. Прошивка слідувала за застарілим NVRAM-записом і потрапляла в нікуди.

Маючи ці свідчення, шлях відновлення був простим: змонтувати ESP, перевстановити завантажувач, створити NVRAM-запис і перевірити fallback-шлях. Без гадань. Без чистки файлових систем. Система повернулась в рамках вікна.

Висновок: нудний збір свідчень перемагає героїчні дебаги. Кожного разу.

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

Ця секція — те, що ви шукаєте о 2:00 ночі. Все гаразд. Я писав її для таких моментів.

1) Симптом: «No bootable device» відразу після клонування диска

Корінна причина: Змінився режим прошивки (UEFI проти BIOS) або схема диска не відповідає очікуванням прошивки (UEFI на MBR-диску без ESP/NVRAM).

Виправлення: Підтвердьте режим завантаження, потім вирівняйте диск:

UEFI: GPT + ESP + grub-install --target=x86_64-efi + запис у efibootmgr.
BIOS: MBR + активний розділ + grub-install --target=i386-pc /dev/sdX.

2) Симптом: підказка GRUB rescue, не може знайти `normal.mod`

Корінна причина: Ядро GRUB завантажилось, але не може знайти свої модулі/конфіг — часто через переміщення /boot, зміну ID розділів або відсутність BIOS boot partition на BIOS+GPT.

Виправлення: Завантажтесь з rescue-media, змонтуйте root і boot, перевстановіть GRUB для правильного таргету, згенеруйте конфіг (update-grub або аналог для дистрибутива). На BIOS+GPT — переконайтесь, що існує BIOS boot partition.

3) Симптом: Ядро запускається, потім initramfs shell: «cannot find UUID=…»

Корінна причина: Ідентифікатор root-файлової системи змінився (UUID/PARTUUID mismatch), або змінився режим контролера дисків (AHCI/RAID) і в initramfs немає потрібних модулів.

Виправлення: Порівняйте /etc/fstab і аргументи ядра для завантажувача з виводом blkid. Оновіть ідентифікатори, перебудуйте initramfs. Якщо змінився режим контролера — поверніть або перебудуйте initramfs з потрібними модулями.

4) Симптом: Диск — GPT, але інструменти скаржаться на пошкоджені заголовки після зміни розмірів

Корінна причина: Резервний GPT-заголовок не переміщено в кінець після клонування; або таблицю розділів правили MBR-утиліти.

Виправлення: Використайте sgdisk -v для валідації; відновіть з sgdisk -e; уникайте legacy-утиліт, що перезаписують protective MBR неправильно.

5) Симптом: UEFI-система завантажується тільки якщо вручну вибрати диск у меню прошивки

Корінна причина: NVRAM порядок/записи невірні або відсутні; іноді запис вказує на змінений PARTUUID розділу.

Виправлення: Виконайте аудит efibootmgr -v. Перевстановіть завантажувач або створіть запис заново. Розгляньте розміщення копії уfallback-шляху (\EFI\BOOT\BOOTX64.EFI), якщо політика дозволяє.

6) Симптом: Після «перетворення в GPT» Windows не завантажується

Корінна причина: Конвертували таблицю розділів, але не сконвертували режим завантаження/менеджер завантаження; відсутній ESP; BCD все ще вказує на BIOS-стиль завантаження.

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

7) Симптом: Не можна створити більше чотирьох розділів на MBR

Корінна причина: MBR підтримує лише чотири первинні розділи, якщо не використовувати extended з логічними розділами.

Виправлення: Якщо вам потрібно багато розділів і сучасне завантаження — перейдіть на GPT. Якщо мусите лишатися на MBR — плануйте з extended-розділом і прийміть legacy-складність.

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

Checklist A: Picking GPT vs MBR (the decision path)

Визначте цільовий режим завантаження: UEFI чи BIOS? (Не гадьте; перевірте специфікацію прошивки або поточну ОС.)
Якщо UEFI: обирайте GPT.
Якщо BIOS: обирайте MBR, якщо тільки у вас немає конкретної причини використовувати GPT (диск >2 TB, стандартизація парку) і ви готові створити BIOS boot partition.
Перевірте потреби в обсязі диска: якщо потрібен >2 TB на одному диску, GPT обов’язковий незалежно від ностальгії.
Визначте стратегію завантажувача (GRUB, systemd-boot, Windows boot manager) і переконайтесь, що необхідні розділи існують.

Checklist B: Safe migration or clone plan (Linux servers)

Зніміть «факти завантаження» перед зміною: режим завантаження, таблиця розділів, lsblk, і якщо UEFI — efibootmgr -v.
Якщо використовуєте GPT: після клонування перевірте заголовки GPT командою sgdisk -v; виправте з sgdisk -e, якщо потрібно.
Переконайтесь, що ESP (UEFI) клоновано або відновлено і змонтовано в очікуваному місці.
Перевірте, що /etc/fstab UUID відповідають blkid.
Перевстановіть завантажувач відповідно до фактичного режиму завантаження (UEFI таргет або BIOS таргет).
Перезавантажте раз, поки у вас ще є консольний доступ і можливість відкотитися.

Checklist C: Converting BIOS/MBR to UEFI/GPT (high-level steps)

Підтвердьте, що апарат/VM підтримує UEFI-завантаження і що ви можете перемикати режим.
Створіть місце для ESP за потреби (акуратно зменшіть розділи).
Конвертуйте таблицю розділів (інструменти залежать від платформи; не робіть це навмання випадковими утилітами).
Створіть ESP (FAT32) і змонтуйте його.
Встановіть EFI-загрузувач, створіть запис NVRAM, перевірте efibootmgr -v.
Переключіть прошивку в режим UEFI і протестуйте завантаження.

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

1) Чи завжди GPT краще за MBR?

Для сучасних систем — так: більші диски, більше розділів, резервування, контрольні суми. Але «краще» не змусить працювати ваш старий BIOS-only пристрій. Узгоджуйте з режимом завантаження.

2) Чи може BIOS завантажувати з GPT?

Так, часто через GRUB з BIOS boot partition. Це поширено в Linux-парках, що хочуть GPT скрізь. Але це не магія: потрібно створити маленький BIOS boot partition і правильно встановити GRUB.

3) Чому мій GPT-диск показує MBR у деяких інструментах?

Це protective MBR. Він існує, щоб MBR-only інструменти не бачили диск як порожній. Якщо інструмент «допоміжно» його перезапише, це може заплутати інші утиліти.

4) Який розмір ESP слід використовувати?

Для Linux-серверів 512 MiB — безпечний дефолт, що запобігає майбутнім проблемам (кілька ядер, кілька завантажувачів, оновлення від вендорів). Менший теж може працювати, поки не перестане.

5) Чи потрібен прапорець active/boot на GPT?

Ні для UEFI. UEFI не цікавиться «active» в сенсі MBR. Для BIOS+MBR прапорець може мати значення залежно від завантажувача і ланцюжка.

6) Я клоную диск, і тепер UEFI-записи вказують не туди. Чому?

UEFI-записи можуть посилатися на розділ через GUID і шлях до файлу. Клонування або пересозданнє розділів може змінити GUID. Виправте, перевстановивши завантажувач або створивши запис заново.

7) Чи можу я залишити MBR і просто створити ESP?

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

8) У чому різниця між ESP і BIOS boot partition?

ESP — це FAT32-файлова система, що зберігає EFI-виконавчі файли для прошивки UEFI. BIOS boot partition — крихітна неформатована область, яку GRUB використовує на GPT-дисках при завантаженні через BIOS.

9) Чому деякі системи нормально працюють до наступного перезавантаження після зміни розмірів розділів?

Тому що ви не зламали працюючу систему — ви зламали ланку завантаження на наступний старт. Зміна розміру може перемістити або пересоздати розділи, змінити ідентифікатори або стерти область після MBR, від якої залежав GRUB.

10) На чому стандартизувати в змішаному парку?

Стандартизуйте процес прийняття рішень, а не одну відповідь. Виявляйте режим завантаження і апаратні обмеження, потім генеруйте правильну розмітку (за замовчуванням UEFI+GPT; BIOS-випадки обробляйте свідомо).

Наступні кроки, які можна виконати сьогодні

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

Аудит невеликої вибірки парку: перевірте режим завантаження і тип таблиці розділів. Знайдіть невідповідності до того, як вони вас викличуть.
Оновіть скрипти provisioning так, щоб вони явно вибирали UEFI чи BIOS, а потім відтворювали GPT чи MBR відповідно.
Додайте крок «збір фактів завантаження» перед змінами в runbooks для роботи з дисками. Дві хвилини наперед зекономлять години пізніше.
Для будь-якого клонування або міграції: перевіряйте, що ESP/BIOS boot partitions існують і заповнені перед перезавантаженням.

Правило просте. Дисципліна — ні. Але дисципліна дешевша за простій.

Схожі статті

Конвертація MBR у GPT без перевстановлення (за допомогою вбудованих інструментів)