Створити завантажувальний USB, який дійсно завантажується (UEFI/Legacy правильно)

Ментальна модель: що насправді означає “завантажувальний”

Коли люди кажуть «зробіть завантажувальний USB», зазвичай мають на увазі: «Помістіть ISO на флешку так, щоб прошивка його знайшла, завантажила завантажувач, а той — ядро або інсталятор.» Це одне речення, за яким ховаються три незалежні системи, що можуть давати збої незалежно одна від одної:

• Носій USB і розмітка розділів: чи показує флешка коректну таблицю розділів і файлові системи, які прошивка може прочитати?
• Шлях завантаження прошивки: UEFI або BIOS (Legacy). Кожен має різні очікування щодо розділів, завантажувальних секторів та структури файлової системи.
• Ланцюжок завантажувача: EFI-утиліта, GRUB/syslinux, Windows boot manager тощо. Він має відповідати режиму машини (UEFI чи Legacy) та архітектурі CPU.

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

Ще одне: ваша прошивка — не ваш друг. Вона — самовпевнений бібліотекар з суворою системою зберігання і без емпатії. Або ви правильно маркуєте книги, або обслуговування не буде.

Цікаві факти та історичний контекст

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

1. BIOS-завантаження походить від дисків, що взагалі не мали розділів. Початковий модель завантажувального сектора передує сучасній розмітці. Тому «завантажувальний код у перших 446 байтах» все ще має значення у 2026 році.
2. Таблиця розділів MBR завжди була тісною. Чотири первинні розділи колись здавалися щедрістю, поки це не стало проблемою; тому з’явилися розширені розділи, а також люди перейшли на GPT.
3. UEFI стандартизував завантаження як «завантажити EFI-утиліту з файлової системи». Це великий зсув: прошивка може читати файлові системи FAT і виконувати файли типу BOOTX64.EFI.
4. «EFI System Partition» (ESP) зазвичай FAT32 не випадково. FAT — проста і широко підтримувана прошивками файлові система, на відміну від ext4, NTFS або інших жорсткіших FS.
5. Secure Boot — це не шифрування; це контроль підписів. Він відмовляється виконувати EFI-бінарі, не підписані ключами, яким прошивка довіряє.
6. Існують гібридні ISO, бо вендори хотіли один образ для багатьох шляхів завантаження. Деякі Linux-ISO — це ISO9660 із вбудованою таблицею розділів, тому їх можна записувати на USB через dd напряму.
7. Windows-інсталяційні носії мають власні обмеження щодо FAT32 і розміру файлів. Файл install.wim може перевищувати 4 GiB, що FAT32 не підтримує; багато інструментів розбивають його або переходять на NTFS — з наслідками для сумісності з UEFI.
8. Записи завантаження UEFI можуть бути «прилипливими» і вводити в оману. NVRAM прошивки пам’ятає записи, які вказують на пристрої, що більше не існують, отже з’являються фантомні опції завантаження й хибна впевненість.
9. USB-флешки брешуть. Деякі поводяться як «fixed disk» на відміну від «removable», що змінює поведінку інструментів Windows; деякі контролери нестабільні при тривалому записі і мовчазно корумпують дані.

Цитата, яку варто тримати на столі:

«парафразована ідея» — Gene Kranz: строгість дисципліни й чіткі процедури запобігають уникненим помилкам.

Виберіть метод створення USB (і чому)

Метод A: Сирий запис ISO (найкращий для гібридних Linux-ISO)

Якщо ISO призначене для запису «як є» на USB (поширено для Linux-інсталяторів), найнадійніший підхід — сирий запис. Ви клонуватимете макет образу, який тестував дистрибутив. Ніякої творчої інтерпретації інструментами. Ніякого «корисного» переформатування, що ламає UEFI-завантаження.

Використовуйте, коли:

• ISO — сучасний Linux-інсталятор і вендор явно підтримує dd або сире створення образу.
• Ви хочете найпростішу ланцюжок довіри: checksum → запис → завантаження.

Уникайте, коли:

• Ви створюєте Windows-інсталяційний носій з ISO (сирий запис Windows-ISO зазвичай не дає того, що ви очікуєте).
• Вам потрібне постійне сховище на тій самій флешці без додаткових кроків.

Метод B: Копіювання файлів на правильно підготовлений ESP (краще, коли ви контролюєте розмітку)

Для UEFI важливо: FAT32-розділ з \EFI\BOOT\BOOTX64.EFI (або відповідним для архітектури). Ви можете побудувати це навмисно. Це чудово, коли потрібні кастомні завантажувачі, власні аргументи ядра або ви створюєте аварійне середовище в контрольованому середовищі.

Метод C: Використовуйте мультизавантажувальний інструмент (стиль Ventoy), коли важлива гнучкість

Ці інструменти встановлюють завантажувач один раз, а потім ви копіюєте ISO як файли. Це зручно й часто працює, але це не магія. Деякі налаштування Secure Boot блокують його, деякі прошивки мають дивну поведінку, і деякі ISO потребують спеціального оброблення.

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

Жарт #1: Завантажувальний USB — як парашут: якщо він «ймовірно підходить», ви дуже швидко дізнаєтесь щось нове.

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

Це перевірені в полі завдання. Кожне містить команду, приклад виводу, що цей вивід означає, та рішення, яке ви приймаєте. Виконуйте їх у Linux; якщо ви на macOS або Windows, перекладайте ідеї, а не синтаксис.

Завдання 1: Вірно визначте пристрій USB (перед тим як знищити диск)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,TRAN,RM,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            TRAN RM FSTYPE MOUNTPOINTS
sda   953.9G Samsung_SSD      sata  0        
├─sda1  512M                  0    vfat   /boot/efi
├─sda2  200G                  0    ext4   /
└─sda3  753G                  0    ext4   /var
sdb    28.9G SanDisk_Ultra     usb  1        
└─sdb1 28.9G                   1    exfat  /media/cr0x/USB

Що це означає: sdb — змінний носій (RM=1) з USB-транспортом. Це ваша цільова флешка.

Рішення: Якщо ціль не виглядає явно як змінний USB-пристрій, зупиніться. Перезапустіть команду з флешкою витягнутою/вставленою, щоб підтвердити різницю.

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

cr0x@server:~$ mount | grep -E '^/dev/sdb'
/dev/sdb1 on /media/cr0x/USB type exfat (rw,nosuid,nodev,relatime)

Що це означає: ОС активно використовує файлову систему.

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

Завдання 3: Чисто відмонтируйте

cr0x@server:~$ sudo umount /dev/sdb1
cr0x@server:~$ echo $?
0

Що це означає: Код виходу 0 означає успіх.

Рішення: Якщо відмонтування не вдається через «busy», закрийте файлові менеджери, термінали, в яких виконано cd у цей каталог, або використайте lsof щоб знайти блокуючі процеси.

Завдання 4: Перевірте контрольну суму ISO (не дебагте пошкоджений завантажений файл)

cr0x@server:~$ sha256sum ubuntu-24.04.1-live-server-amd64.iso
d7b1e3c3f8f2b6d7d8a4c1c6f0d2a0b3a4d7c5a0b8f2e1d3c4b5a6f7e8d9c0b1  ubuntu-24.04.1-live-server-amd64.iso

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

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

Завдання 5: Перевірте, чи ISO є гібридним образом (підказка для сирого запису)

cr0x@server:~$ file ubuntu-24.04.1-live-server-amd64.iso
ubuntu-24.04.1-live-server-amd64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Ubuntu-Server 24.04.1 LTS amd64'

Що це означає: «DOS/MBR boot sector» натякає на гібридний ISO з вбудованими структурами завантаження.

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

Завдання 6: Сировий запис ISO на USB (Linux)

cr0x@server:~$ sudo dd if=ubuntu-24.04.1-live-server-amd64.iso of=/dev/sdb bs=4M conv=fsync status=progress
1562378240 bytes (1.6 GB, 1.5 GiB) copied, 32 s, 48.8 MB/s
2971666432 bytes (3.0 GB, 2.8 GiB) copied, 61 s, 48.7 MB/s
4026531840 bytes (4.0 GB, 3.8 GiB) copied, 83 s, 48.5 MB/s
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96 s, 48.2 MB/s
1103+1 records in
1103+1 records out
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96.1312 s, 48.2 MB/s

Що це означає: Образ записано повністю, а conv=fsync змушує скинути кеш на диск.

Рішення: Після dd не виривайте флешку одразу. Дайте udev осісти, потім перевірте розмітку.

Завдання 7: Примусьте ядро перечитати таблицю розділів

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk -f /dev/sdb
NAME   FSTYPE FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb                                                                   
├─sdb1 iso9660      Ubuntu-Server 2024-08-28-14-10-41-00             0     100%  
└─sdb2 vfat   FAT16 UEFI_BOOT   2A1B-3C4D                            

Що це означає: Тепер у вас є розділ ISO9660 і маленький FAT-розділ для UEFI-завантаження. Це типовo для багатьох гібридних образів.

Рішення: Якщо ви не бачите FAT-розділу, а очікуєте UEFI-завантаження, перевірте ISO; деякі образи — лише для Legacy або покладаються на інші структури.

Завдання 8: Підтвердьте наявність UEFI fallback-шляху на флешці

cr0x@server:~$ sudo mkdir -p /mnt/usb-uefi
cr0x@server:~$ sudo mount /dev/sdb2 /mnt/usb-uefi
cr0x@server:~$ sudo find /mnt/usb-uefi/EFI -maxdepth 2 -type f
/mnt/usb-uefi/EFI/BOOT/BOOTX64.EFI
/mnt/usb-uefi/EFI/BOOT/grubx64.efi

Що це означає: Прошивка, яка не може або не хоче використовувати NVRAM-записи, все одно може завантажитись через стандартний шлях \EFI\BOOT\BOOTX64.EFI.

Рішення: Якщо BOOTX64.EFI відсутній, UEFI-завантаження, швидше за все, буде мертве при прибутті, якщо лише вендор не дає іншого шляху і ви не додасте запис вручну.

Завдання 9: Перевірте, чи ISO записано правильно, зіставивши початкові байти

cr0x@server:~$ sudo cmp -n 1048576 ubuntu-24.04.1-live-server-amd64.iso /dev/sdb && echo "first 1MiB matches"
first 1MiB matches

Що це означає: Початок пристрою збігається з ISO. Це виявляє несподівану кількість проблем через «брехню» контролера.

Рішення: Якщо відрізняється, спробуйте інший USB-порт, вимкніть USB selective suspend або замініть флешку. Дебагування $8-пристрою — це хобі, а не операційна задача.

Завдання 10: Перевірте, GPT чи MBR на USB (допомагає зрозуміти поведінку прошивки)

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,20p'
Disk /dev/sdb: 28.9 GiB, 31016853504 bytes, 60579840 sectors
Disk model: SanDisk Ultra
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e9b2a1c

Що це означає: Ця флешка використовує мітку MBR («dos»). Багато гібридних ISO так роблять.

Рішення: Якщо вам потрібен GPT явно (деяка корпоративна прошивка поводиться краще), розгляньте метод копіювання файлів з GPT-розміткою і FAT32 ESP.

Завдання 11: Створіть навмисний GPT + FAT32 ESP (для кастомного UEFI-boot)

cr0x@server:~$ sudo wipefs -a /dev/sdb
cr0x@server:~$ sudo parted -s /dev/sdb mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sdb mkpart ESP fat32 1MiB 1025MiB
cr0x@server:~$ sudo parted -s /dev/sdb set 1 esp on
cr0x@server:~$ sudo mkfs.vfat -F32 -n UEFI_INSTALL /dev/sdb1
mkfs.fat 4.2 (2021-01-31)

Що це означає: Тепер у вас чистий FAT32-розділ розміру ESP з правильним GPT-флагом.

Рішення: Використовуйте це, коли ви створюєте носій вручну (кастомні EFI-бінарі, підписані shim, провайдерське аварійне середовище).

Завдання 12: Скопіюйте EFI-завантажувач у fallback-шлях

cr0x@server:~$ sudo mount /dev/sdb1 /mnt/usb
cr0x@server:~$ sudo mkdir -p /mnt/usb/EFI/BOOT
cr0x@server:~$ sudo cp BOOTX64.EFI /mnt/usb/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo ls -l /mnt/usb/EFI/BOOT
total 1312
-rwxr-xr-x 1 root root 1343488 Feb  4 09:10 BOOTX64.EFI

Що це означає: Прошивка має стандартне місце для пошуку, незалежно від стану NVRAM.

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

Завдання 13: Переконайтеся, що машина завантажилась у режимі UEFI (з середовища live)

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

Що це означає: Linux надає доступ до служб UEFI через /sys/firmware/efi.

Рішення: Якщо ви очікували UEFI, а отримали Legacy — перестаньте звинувачувати USB. Виправте вибір режиму в прошивці.

Завдання 14: Огляньте наявні UEFI-записи завантаження (допомагає, коли прошивка спантеличена)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0003,0001
Boot0001* ubuntu	HD(1,GPT,2f1c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003* UEFI: SanDisk, Partition 2	PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/HD(2,MBR,0x6e9b2a1c,0x3a00,0x8000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0007* UEFI: Built-in EFI Shell	FvFile(7C04...)

Що це означає: Прошивка бачить шлях EFI на флешці, і ви можете підтвердити, який запис фактично завантажився (BootCurrent).

Рішення: Якщо запис USB відсутній, але флешка має \EFI\BOOT\BOOTX64.EFI, використайте одноразове меню завантаження; деякі прошивки не зараховують його автоматично.

Завдання 15: Виявлення стану Secure Boot (поширена причина «чому воно одразу падає»)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Що це означає: Непідписані EFI-бінарі не будуть виконані, якщо тільки не додані відповідні ключі.

Рішення: Якщо ваша флешка використовує непідписаний завантажувач, або вимкніть Secure Boot для інсталяції, або використайте підписану shim-ланку.

UEFI vs Legacy: як машина вирішує, що завантажувати

Legacy BIOS завантаження в одному абзаці

Legacy BIOS дивиться на перший сектор диска (MBR) і виконує код там. Той код потім знаходить «наступний етап» завантажувача десь ще. Ось чому дрібниці — наприклад, де завантажувач очікує знайти stage2 — мають значення. Також тому файловий тип спочатку не має прямого значення для BIOS: BIOS не читає файли; він запускає завантажувальний код.

UEFI завантаження в одному абзаці

UEFI читає розділи, монтує файлову систему (зазвичай FAT) і завантажує EFI-утиліту. Воно може робити це через NVRAM-записи завантаження (явні шляхи) або через fallback-шлях \EFI\BOOT\BOOTX64.EFI. UEFI чистіший, але реалізації прошивок дуже різняться, особливо щодо підтримки файлових систем і поведінки знімних носіїв.

Ключові правила сумісності, якими варто керуватися

• Якщо хочете UEFI-завантаження повсюдно: забезпечте FAT32-розділ з \EFI\BOOT\BOOTX64.EFI.
• Якщо хочете Legacy-завантаження повсюдно: переконайтеся, що є дійсний MBR-завантажувальний код, і завантажувач підтримує BIOS-режим.
• Якщо хочете обидва: використовуйте гібридні ISO від вендора або побудуйте носій, що підтримує обидва ланцюжки. Не припускайте, що «UEFI-спроможний» носій завантажиться в Legacy-режимі, або навпаки.
• Не змішуйте режими під час інсталяції. Встановлення ОС у режимі UEFI зазвичай вимагає ESP на цільовому диску; установка в Legacy використовує інші завантажувальні сектори. Змішування веде до класичної трагедії «встановлено, але не завантажується».

Жарт #2: Меню налаштувань прошивки — єдине місце, де «Save & Exit» відчувається як загроза.

Secure Boot: коли “працює” стає “заблоковано”

Secure Boot — причина, через яку USB нормально завантажувався на старому сервері, але падав на новому ноутбуці з корпоративним образом. Прошивка перевіряє підписи EFI-бінарів перед їх виконанням. Якщо бінар не підписаний ключем, якому прошивка довіряє, його не запустять. Деякі прошивки показують повідомлення; деякі мовчки відмовляються і переходять до наступної опції завантаження, що виглядає як «USB не виявлено». Насправді його виявили. Його відхилили.

Що робити в реальних середовищах

• Для основних Linux-інсталяторів: використовуйте образи зі підписаним shim і підписаним GRUB. Більшість так робить.
• Для кастомних аварійних інструментів: або підписуйте свої EFI-бінарі й реєструйте свій ключ (MOK або DB прошивки), або плануйте контрольовану процедуру вимкнення Secure Boot.
• Для Windows-носіїв: дотримуйтесь офіційного шляху створення, адже компоненти Windows підписані і очікують відповідності.

У корпоративному середовищі вимкнення Secure Boot може бути забороненим, крім випадків «break-glass». У такому випадку метод створення USB — це не особистий вибір; це вимога відповідності.

Три корпоративні міні-історії (анонімізовано, ймовірні та технічно реальні)

Інцидент №1: Неправильне припущення (UEFI — «в основному BIOS, правда?»)

Середня компанія розгорнула новий флот ноутбуків для розробників. Команда складання створила внутрішню «золоту» USB з Linux-інсталятором. Вона завантажувалась на тестовому стенді, який складався з кількох старіших десктопів, налаштованих на Legacy BIOS, бо так завжди було на стенді.

На нових ноутбуках флешка з’являлась у одноразовому меню завантаження — навіть двічі: як «UEFI: USB» і як «USB HDD». Техніки обирали ту опцію, що звучала знайомо. «USB HDD» заспокоювала. Вона давала чорний екран, а потім повернення в меню. Вони вирішили, що образ поганий.

Перебудували флешку — та ж сама помилка. Спробували інші флешки — те саме. Справжня проблема: ноутбуки були налаштовані забороняти Legacy-завантаження зовсім. «USB HDD» — це Legacy-шлях. UEFI-запис працював, але тільки якщо його обирали. Ніхто не повідомив команді складання, що новий флот — тільки UEFI і Secure Boot увімкнений.

Коли вибрали «UEFI: USB», інсталятор одразу завантажився. Виправлення було операційним: оновити рукопис (runbook), щоб явно інструктувати техніків обирати UEFI-запис, і оновити процес іміджування, щоб перевіряти /sys/firmware/efi в live-середовищі перед тим як продовжити. Постмортем не закінчився на «люди повинні знати краще». Висновок: «ми відправили процес, що залежав від племінного знання».

Інцидент №2: Оптимізація, що відкотилась (NTFS заради швидкості, UEFI заради суму)

Інша організація будувала Windows-USB для внутрішньої програми оновлення. Хтось помітив, що форматування FAT32 було повільнішим і іноді давало збої, коли install.wim перевищував 4 GiB. «Оптимізація» була в тому, щоб форматувати флешку як NTFS і копіювати файли, бо NTFS справляється з великими файлами і копіювання швидше, ніж запис образу.

Це працювало на більшості десктопів. Потім потрапило на партію малих форм-факторів з прошивкою, яка відмовлялася завантажуватися в UEFI з NTFS на знімних носіях. У меню появлялась флешка, але вибір просто повертав у меню. Техніки звинуватили партію апаратури і відкрили кейс у вендора.

Відповідь вендора була нудною: «Прошивка UEFI зобов’язана підтримувати FAT для знімних носіїв не завжди; NTFS підтримка опціональна». Їхні пристрої цього не реалізували. «Оптимізація» фактично стала регресією сумісності. Флот отримав два класи пристроїв, і флешка працювала тільки на одному класі.

Виправлення було теж нудним: повернутися до FAT32 і розбити WIM, або використовувати інструмент, який створює два розділи (малий FAT32 ESP для завантаження + NTFS для великих інсталяційних файлів) з завантажувачем, що вміє читати NTFS. Урок: оптимізації швидкості, що змінюють файлову систему, — це не оптимізації; це продуктове рішення з радіусом ураження.

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

Команда фінпослуг тримала «break-glass» USB-кит для відновлення серверів. Кит містив перевірений Linux rescue ISO і дві конкретні моделі флешок, куплені оптом. Рукопис вимагав перевірити хеш ISO, записати образ сиро, потім перевірити перший MiB через cmp.

Звучало як церемонія. Так і було. І це працювало.

Під час великого інциденту їм потрібно було завантажити машину, яка мала пошкоджений завантажувач після невдалого заміщення диска. Перша флешка з кита не завантажилась. Замість паніки, on-call дотримувався рукопису: перевірили розмітку флешки, підтвердили режим UEFI і протестували флешку на другому хості. Там вона теж не працювала.

Вони взяли другу флешку — той самий ISO, та сама процедура — і вона одразу завантажилася. Перша флешка фізично відмовляла. Оскільки мали детерміновані кроки перевірки і запасну відому модель, вони не витратили годину на пошуки винних. Вони відновили завантажувач і завершили інцидент. Урок не інтригуючий: резервність і перевірки в «простих речах» зменшують MTTR краще за все.

План для швидкої діагностики

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

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

• Перевірте настройки прошивки: чи вимкнено Legacy-завантаження? Чи увімкнений Secure Boot? Чи дозволено завантаження з USB?
• У меню завантаження: чи бачите окремі записи для UEFI і Legacy для тієї самої флешки?
• Рішення: Якщо середовище тільки UEFI, припиніть пробувати Legacy-носії. Якщо Secure Boot примусовий, припиніть пробувати непідписані завантажувачі.

По-друге: підтвердіть, що USB записано правильно (не «скопійовано» неправильно)

• Перевірте контрольну суму ISO.
• Підтвердьте розмітку флешки через lsblk та fdisk -l.
• Переконайтесь у наявності \EFI\BOOT\BOOTX64.EFI для UEFI-завантаження.
• Рішення: Якщо розмітка неправильна — відтворіть флешку, використовуючи метод, відповідний цьому ISO.

По-третє: визначте клас помилки

• USB зовсім не відображається: апаратна проблема/порт, завантаження USB відключено в прошивці, флешка померла.
• USB відображається, але повертає в меню: відхилення Secure Boot, неправильна архітектура EFI, відсутній fallback-шлях, прошивка не може прочитати файлову систему.
• Завантажувач починається, потім помилка: пошкоджений запис, відсутні файли, невідповідність kernel/initrd, погана конфігурація, битий ISO.
• Інсталятор стартує, але не бачить дисків: драйвери контролера зберігання, RAID/HBA режим, VMD, RST або налаштування контролера — це не проблема USB.

По-четверте: валідуйте зсередини робочого live-середовища

• Підтвердіть режим через /sys/firmware/efi.
• Перевірте стан Secure Boot через mokutil.
• Огляньте записи UEFI через efibootmgr (якщо встановлено).
• Рішення: Якщо режим не той, який ви думаєте, виправте це перед будь-якими іншими діями.

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

1) Симптом: USB не з’являється в меню завантаження

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

Виправлення: Увімкніть завантаження з USB у прошивці; спробуйте задній порт материнської плати; використайте USB 2.0 якщо є (деякі прошивки мають проблеми з 3.x); повністю вимкніть живлення і ввімкніть; протестуйте флешку на іншому хості.

2) Симптом: USB з’являється, але вибір відразу повертає в меню

Причина: відхилення Secure Boot, відсутній BOOTX64.EFI, неправильна архітектура EFI (x86_64 vs ARM64), або UEFI не читає файлову систему (NTFS/exFAT).

Виправлення: Використовуйте FAT32 для ESP; переконайтесь, що \EFI\BOOT\BOOTX64.EFI існує; використайте підписану ланку завантаження або вимкніть Secure Boot (якщо дозволено); переконайтесь, що ISO відповідає архітектурі обладнання.

3) Симптом: Завантажується на одній машині, але не на іншій

Причина: на одній машині працює Legacy, на іншій — UEFI; або на одній вимагають Secure Boot; або одна прошивка підтримує NTFS-завантаження, інша — ні.

Виправлення: Стандартизуйте на UEFI-завантаженні і FAT32 ESP з fallback-шляхом; документуйте, яку опцію у меню обирати; уникайте припущень про NTFS-only UEFI-завантаження.

4) Симптом: GRUB стартує, потім «unknown filesystem» або «file not found»

Причина: частковий запис, погана флешка, або конфігурація GRUB вказує на неправильний UUID/пристрій, бо розмітка носія відрізняється.

Виправлення: Створіть флешку заново сирим записом; перевірте через cmp; замініть підозріле обладнання; уникайте «ручного реміксування» вмісту ISO, якщо ви не розумієте конфігурацію завантажувача.

5) Симптом: Windows USB завантажується в Legacy, але не в UEFI

Причина: флешка відформатована в NTFS без FAT32 ESP; прошивка вимагає FAT32 для UEFI-завантаження з знімних носіїв.

Виправлення: Створіть Windows-носій з FAT32-розділом для завантаження; якщо файли перевищують 4 GiB, розбийте WIM або застосуйте підхід з двома розділами (малий FAT32 ESP + NTFS для великих файлів).

6) Симптом: Інсталятор стартує, але цільовий диск не видно

Причина: режим контролера зберігання (RAID/VMD/RST), відсутній драйвер або NVMe під абстракцією вендора.

Виправлення: Налаштуйте режим зберігання в BIOS (AHCI vs RAID) за потреби; завантажте драйвер в інсталятор; оновіть прошивку; перевірте через lspci та lsblk у live-середовищі. Це не вирішується переписуванням USB п’ять разів.

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

План A: Зробити Linux-USB, що надійно завантажується в UEFI (рекомендовано)

1. Завантажте ISO і значення контрольної суми від вендора.
2. Перевірте контрольну суму через sha256sum. Якщо не співпадає — перезавантажте.
3. Визначте USB-пристрій через lsblk. Підтвердіть, що він змінний і розмір відповідає.
4. Відмонтуйте розділи на цьому пристрої.
5. Сирий-запис ISO через dd з conv=fsync.
6. Перечитайте розділи через partprobe і підтвердіть розмітку.
7. Підтвердіть наявність UEFI-файлу: змонтуйте FAT-розділ і перевірте \EFI\BOOT\BOOTX64.EFI.
8. Протестуйте на двох машинах: одна сучасна тільки UEFI, інша — старіша зі змішаними режимами. Запишіть, яка опція у меню працює.

План B: Побудувати кастомний UEFI-USB (для rescue або внутрішніх інструментів)

1. Почніть з відомої хорошої моделі флешки. Купіть кілька. Серйозно.
2. wipefs -a пристрою, щоб видалити конфліктні підписи.
3. Створіть GPT, потім ESP FAT32-розділ (принаймні 512 MiB; я віддаю перевагу 1 GiB для зручності).
4. Помістіть вашу EFI-бінар у \EFI\BOOT\BOOTX64.EFI.
5. Якщо в середовищі увімкнено Secure Boot, переконайтесь, що EFI-бінар підписаний належно або надайте підписану shim-ланку.
6. Перевірте на тестовому хості через efibootmgr -v і обираючи «UEFI: USB» в одноразовому меню завантаження.

План C: Підтримка обох режимів UEFI та Legacy без драм

1. Віддавайте перевагу вендорським гібридним ISO, які явно підтримують обидва режими.
2. Якщо треба кастомізувати: зробіть окремі UEFI та Legacy флешки, фізично позначте їх і припиніть вдавати, що одна флешка задовольнить усі прошивки.
3. Документуйте, який режим потрібен для інсталяції образу, що ви розповсюджуєте (UEFI рекомендовано). Закріпіть це в чеклисті інсталяції.

Операційна гігієна (нудні, але важливі речі)

• Тримайте одну «відомо хорошу» флешку запаяною як контроль.
• Тримайте хеші в вашому внутрішньому рукописі для затверджених образів.
• Фіксуйте налаштування прошивки, що потрібні (політика Secure Boot, політика Legacy, режим SATA/RAID).
• Під час дебагу змінюйте тільки одну змінну одночасно. Всесвіт карає за паралельні здогадки.

FAQ

1) Чому сирий запис ISO інколи створює кілька розділів?

Тому що багато інсталяторних ISO — «гібридні» образи, що містять таблиці розділів (часто MBR, іноді GPT). Коли їх записати на диск, ОС бачить ті розділи.

2) Чому я не можу просто скопіювати файл ISO на USB і завантажитися з нього?

Прошивка зазвичай не завантажується з ISO-файлу, що лежить на випадковій файловій системі. Вона завантажується через завантажувальні сектори (Legacy) або через EFI-утиліти на FAT (UEFI). Мультизавантажувальні інструменти додають завантажувач, що розуміє ISO-файли; проста прошивка зазвичай цього не робить.

3) GPT чи MBR для завантажувального USB?

Для UEFI GPT з ESP — чисто і передбачувано. Для Legacy важливий MBR. Гібридні Linux-ISO часто використовують MBR заради сумісності. Якщо ви будуєте кастомний носій для сучасного флоту, GPT + FAT32 ESP — зазвичай правильний вибір за замовчуванням.

4) Моя флешка FAT32, але все одно не завантажується в UEFI. Чому?

Поширені причини: відсутній \EFI\BOOT\BOOTX64.EFI, неправильна архітектура (ARM проти x86_64), Secure Boot відкидає бінар, або buggy-прошивка, яка вимагає вставити флешку до включення живлення.

5) Secure Boot увімкнено. Чи треба його вимикати, щоб завантажити Linux-інсталятори?

Ні, не обов’язково. Багато основних інсталяторів постачаються із підписаним shim і підписаним завантажувачем, що працюють з Secure Boot. Кастомні EFI-бінарі часто не працюватимуть, якщо ви їх не підпишете і прошивка не довіряє ключу.

6) Чому меню завантаження показує два записи для тієї самої флешки?

Один — UEFI-шлях, інший — Legacy/CSM. Обирайте той, що відповідає режиму інсталяції. Якщо хочете встановити в UEFI — обирайте UEFI-позначений запис.

7) Інсталятор завантажується, але після інсталяції машина не стартує. Чи винна флешка?

Зазвичай ні. Це зазвичай невідповідність режиму інсталяції (встановили в Legacy без належного MBR, або встановили в UEFI без ESP), або проблеми з порядком завантаження дисків/записами NVRAM. Перевірте, чи інсталятор працював у UEFI-режимі і чи має цільовий диск ESP.

8) Чому деякі методи створення Windows-USB виходять з ладу на певних ПК?

UEFI зобов’язаний підтримувати FAT для знімних носіїв не завжди; NTFS — опціонально. Windows-USB, що покладається на NTFS-завантаження, може працювати на деяких прошивках і падати на інших.

9) Чи підходить exFAT для завантажувальних USB?

Для UEFI зазвичай ні. Багато прошивок не завантажуються з exFAT. Для розділу завантаження використовуйте FAT32.

10) Яка найкраща базова перевірка після запису USB?

Змонтируйте ESP (або FAT-розділ) і переконайтесь, що \EFI\BOOT\BOOTX64.EFI існує. Потім протестуйте флешку на другій машині. Якщо вона працює тільки на одному хості — ви ще не закінчили.

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

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

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

• Оберіть одну затверджену модель флешки і купіть кілька штук. Позбавтеся від непередбачуваних флешок.
• Стандартизуйте на UEFI-інсталяціях, якщо у вас немає обґрунтованої Legacy-вимоги.
• Додайте три перевірки у ваш рукопис: співпадіння sha256sum, sanity-перевірка lsblk і наявність \EFI\BOOT\BOOTX64.EFI.
• Коли щось не працює, виконуйте план швидкої діагностики в порядку. Мета — швидка ізоляція, а не героїчне налаштування.

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