Єдиний правильний спосіб створити завантажувальний USB для Windows 11 (UEFI + Secure Boot)

February 22, 2026 • February 22, 2026 • Читання: 6 хв • Views: 0

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

Деякі проблеми нудні, поки вони не стають дорогими. USB з інсталятором Windows 11, який «майже» завантажується, — один із таких: він з’являється в меню завантаження, миготить і повертає вас до прошивки, ніби нічого не сталося. Тим часом ви стоїте перед конференц-залом, повним ноутбуків, яким «потрібно зробити образ до 14:00».

Це промислово-надійний спосіб створити USB з інсталятором Windows 11, який завантажується на сучасних системах UEFI з увімкненим Secure Boot. Ніякого фольклору. Ніякого «працює на моєму комп’ютері». Лише механіка, режими відмов і найшвидші способи переконатися, що насправді не так.

Що означає «правильно» (реалії UEFI + Secure Boot)

«Завантажувальний USB» — це не одне й те саме. Це набір вимог, що відрізняються залежно від того, чи завантажуєте ви в Legacy BIOS/CSM або в рідний UEFI, а також чи застосовується Secure Boot. Для Windows 11 у корпоративній реальності «правильно» означає наступне:

Завантаження UEFI: Прошивка запускає EFI-завантажувач з FAT32-розділу (зазвичай \EFI\BOOT\BOOTX64.EFI).
Сумісність із Secure Boot: EFI-завантажувач підписаний ключем, якому довіряє прошивка (зазвичай Microsoft UEFI CA / ключі Windows Production на OEM-системах).
Цілісність вмісту інсталятора: файли Windows setup відповідають ISO; жодних «таємних репаків», жодних напівскопійованих файлів, жодного пошкодженого install.wim/install.esd.
Правильний макет розділів для знімного носія: Зазвичай GPT працює без проблем; MBR також може завантажуватися в UEFI, якщо FAT32-розділ має потрібні файли, але GPT — це чистий дефолт для сучасних систем.
Коректна робота з обмеженнями FAT32: FAT32 має обмеження 4 GiB на один файл; сучасні образи Windows інколи перевищують це для install.wim.

Ось у чому суть: більшість проблем «мій USB не завантажується» не містять містики прошивки. Це одна з таких причин:

Флешка відформатована в NTFS, а прошивка системи не вміє UEFI-завантажуватися з NTFS (багато не вміють, деякі — вміють, багато поводяться непослідовно).
install.wim більший за те, що підтримує FAT32, тож хтось «вирішив» проблему, перевівши весь диск в NTFS, зламавши UEFI-завантаження на частині парку.
ISO був скопійований неповністю або пошкоджений, і помилка проявляється тільки після першого перезавантаження інсталятора, коли звинувачення вже спрямовано на «драйвери».
Хтось переключив CSM/Legacy або налаштування Secure Boot і забув про це.

Одну інженерну цитату варто тут навести, бо вона — суть в опсі: Надія — не стратегія. — Gene Kranz. Користуйтеся перевірками, а не відчуттями.

Жарт №1: Secure Boot як аеропортова безпека: він не судить вашу моральність, він перевіряє документи.

Цікаві факти та історичний контекст (коротко, по суті)

Це маленькі істини, що пояснюють, чому «прості» USB-інсталятори зраджують людей:

UEFI замінив BIOS поступово. Перехід почався в середині 2000-х, але багато вендорів роками поставляли «UEFI у костюмі BIOS» (CSM).
Secure Boot з’явився на обладнанні ери Windows 8. Він став поширеним на OEM-системах близько 2012 року, і організації роками вивчали, які інструменти завантаження раптом перестали працювати.
Обмеження FAT32 4 GiB старі, але все ще мають значення. Специфікація UEFI очікує, що прошивка зможе читати FAT, а FAT32 — найширше підтримуваний варіант.
Раніше інсталяційні носії Windows легко вміщалися. З часом більше драйверів, мов та функцій збільшили install.wim, і «просто відформатувати FAT32» стало нетривіально.
Багато прошивок не вміють завантажуватися з exFAT. exFAT чудовий для файлів, але поганий для «чи завантажиться це на випадковій моделі ноутбука».
Деякі UEFI-прошивки вміють завантажуватися з NTFS, але на це не покладайтесь. Декілька вендорів додали драйвери NTFS; інші — ні; деякі роблять це лише в певних шляхах завантаження.
Media Creation Tool від Microsoft — не магія. Він хороший, але все одно залежить від стабільного вводу/виводу, стабільного мережевого з’єднання та контролерів USB, що не глючать під час тривалого запису.
Раніше «removable media bit» мав більше значення. Старі версії Windows поводилися по-різному в залежності від того, чи пристрій повідомляв себе як знімний. Нині це менш критично, але спадкова логіка лишається в інструментах.
GPT vs MBR — це не лише стиль. GPT узгоджується з дизайном UEFI і уникає деяких дивних випадків виявлення розділів на сучасних системах.

Інструменти: Media Creation Tool vs Rufus vs ручне

Обирайте інструменти, як обираєте файлові системи: за режимами відмов, а не за популярністю.

Варіант A (рекомендовано на Windows): Media Creation Tool

Якщо ви на робочій станції Windows з нормальним інтернетом, Media Creation Tool від Microsoft — найкоротший шлях. Зазвичай воно створює носій, який просто працює із Secure Boot, бо йде по «благословеному» шляху.

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

Варіант B (рекомендовано, коли потрібен контроль): Rufus

Rufus — інструмент, до якого звертаються, коли:

У вас вже є ISO (можливо з внутрішнього сховища).
Потрібно свідомо обрати GPT/MBR.
Потрібно FAT32-завантаження з великим образом (Rufus може розбити WIM або використовувати UEFI:NTFS-шийми залежно від вибору).

Недолік: гнучкість провокує «кмітливі» налаштування. Кмітливість — ворог надійності парку.

Варіант C (Linux або «сьогодні я не довіряю GUI»): ручне створення розділів + копіювання файлів

Ручне створення — найдетермінованіший, якщо виконано правильно. Це також найпростіший шлях створити USB, який завантажується на вашій машині і провалюється всюди, якщо зекономити на деталях (NTFS, exFAT, неправильний тип розділу, відсутній EFI-путь).

Чого слід уникати:

dd ISO на USB і вважати роботу зробленою. Це працює для багатьох Linux-ISO. Windows-інсталяційні ISO не призначені як гібридні образи таким чином, щоб надійно UEFI-завантажуватися при сирому записі на USB на всіх вендорах.
«один NTFS-розділ, бо WIM великий.» Так ви отримаєте флешку, що завантажується на одній моделі і не завантажується на іншій.

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

Коли USB не завантажується, у вас немає часу на інтерпретативні танці. Ось порядок триажу, що швидко знаходить вузьке місце.

Перший: чи бачить прошивка його як опцію UEFI?

Якщо в меню завантаження показано UEFI: <назва USB> (або схоже), ви принаймні в правильному всесвіті.
Якщо пристрій показано лише під записами legacy/BIOS, ймовірно неправильно відформатовано, відсутній EFI-завантажувач або прошивка в режимі legacy.

Другий: чи EFI System Partition дійсно FAT32 і сформована правильно?

Перевірте наявність \EFI\BOOT\BOOTX64.EFI. Якщо воно відсутнє, USB може бути «завантажувальним» теоретично, але не так, як очікує UEFI.

Третій: взаємодія зі Secure Boot

Якщо відключення Secure Boot дозволяє завантажитись — ви не використовуєте Microsoft-підписаний шлях завантаження (або у вас кастомні/жорсткі ключі прошивки).
Якщо і після відключення не завантажується — проблема не в Secure Boot; це macет носія, корупція або налаштування прошивки, як-от CSM.

Четвертий: пастка FAT32 4 GiB

Якщо USB — FAT32, але ISO містить install.wim більше 4 GiB, хтось або:

переключив на NTFS (порушивши UEFI-завантаження на багатьох системах), або
розбив WIM (правильний шлях), або
використав install.esd (зазвичай менше), або
скопіював файли частково (гірший варіант, виглядає «добре», доки setup дійсно не потребує файлу).

П’ятий: сама флешка

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

Жарт №2: Найдешевша флешка — та, що коштує вам лише саму флешку, а не ваш вечір.

Контрольні списки / покроковий план (нудний, але правильний шлях)

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

Контрольний список: передумови

Перевірений ISO Windows 11 з надійного джерела (або вивід Media Creation Tool).
Флешка від відомого вендора, 16 ГБ або більше. 8 ГБ іноді працює, іноді ні, і завжди марнує час.
Машина для створення носія з стабільним живленням і стабільними USB-портами (надавайте перевагу портам на материнській платі, а не хитким хабам).
Цільові системи налаштовані на UEFI-завантаження (CSM/Legacy вимкнено), якщо у вас немає конкретної причини інакше.

Контрольний список: як має виглядати завершений USB

Таблиця розділів: GPT (переважно) або MBR (прийнятно, якщо зроблено правильно).
Щонайменше один FAT32-розділ, що містить:
- \EFI\BOOT\BOOTX64.EFI
- \sources\boot.wim
- \sources\install.wim (або частини розбитого WIM) / install.esd
Якщо install.wim занадто великий для FAT32: або розбийте його, або використайте підхід з двома розділами (FAT32 для завантаження + NTFS для великого payload) лише якщо ви впевнені, що ваш парк прошивок це підтримує. Для змішаного парку консервативний варіант — розбивка WIM.

Контрольний список: перевірки перед тим, як йти

Перевірте контрольну суму ISO або цілісність файлу.
Переконайтесь, що на USB є очікувані файли та розміри.
Тестово завантажте хоча б на двох різних моделях обладнання, якщо це для парку.
Під час тестування тримайте Secure Boot увімкненим. Якщо ви тестували тільки з вимкненим Secure Boot — ви не тестували.

Методи для Windows (рекомендовано та альтернативи)

Метод 1: Media Creation Tool (мінімум драм)

Запустіть інструмент, оберіть «Create installation media», виберіть USB. Потім проведіть валідацію (не пропускайте її просто тому, що «Microsoft зробив це»). Проблеми зазвичай походять із середовищем: проксі, endpoint-захист і нестабільність USB.

Коли процес завершиться, все одно огляньте флешку: підтвердіть FAT32 і переконайтесь, що існує EFI-завантажувач.

Метод 2: Rufus з GPT + UEFI + FAT32 (кращий баланс)

Використовуйте Rufus, коли у вас вже є ISO і ви хочете передбачуваний результат.

Схема розділів: GPT
Цільова система: UEFI (без CSM)
Файлова система: FAT32 (дефолт для UEFI)

Якщо Rufus попереджає, що install.wim занадто великий для FAT32, оберіть опцію, яка розбиває WIM (якщо вона доступна), а не перемикає все на NTFS заради зручності. Зручність — короткостроковий кредит з жахливими відсотками.

Метод 3: Diskpart + монтування ISO + копіювання (для тих, хто любить докази)

Це явно і налагоджувано. Недолік — вам доведеться самостійно вирішувати проблему FAT32 4 GiB.

Методи для Linux (коли ви в датацентрі або на jumpbox)

Якщо ви на Linux, ви можете створити чудові інсталяційні носії Windows. Хитрість у тому, щоб прийняти, що «записати ISO на USB» — не мета. Мета: FAT32 EFI-завантажувальний розділ з правильними файлами і спосіб перенести великий інсталяційний образ.

Найбільш сумісний підхід: один FAT32-розділ, копіювання файлів і, за потреби, розбиття install.wim на частини install.swm. Windows Setup розуміє розбиті WIM-файли.

Параметри Secure Boot: що перевіряє, а що — ні

Secure Boot часто звинувачують у проблемах, які він насправді не спричинив. Він прискіпливий, але не випадковий.

Secure Boot перевіряє підписи EFI-бінарників (завантажувачі, шими, деякі шляхи Option ROM). Якщо EFI-бінарник не підписаний довіреним ключем, прошивка відмовиться його виконати.
Secure Boot не перевіряє весь вміст USB. Він не обчислює хеші кожного файлу в \sources. Це ваша відповідальність.
Збої Secure Boot часто виглядають як «нічого не відбувається». Деякі прошивки показують повідомлення. Інші просто повертають вас у меню завантаження, як ввічливий вахтар.
Існують кастомні ключі Secure Boot. Організації іноді реєструють власний Platform Key (PK) і бази (db/dbx). Це може зламати універсальний носій, який працює на споживчих ноутбуках.

Якщо ви в середовищі з кастомною політикою Secure Boot, «єдиний правильний шлях» може включати використання затверджених корпоративних носіїв або процесів підпису. Але для стандартного OEM-набору ключів правильно побудований інсталятор Windows 11 завантажиться під Secure Boot.

Три корпоративні історії (біль з уроком)

Міні-історія 1: інцидент через хибне припущення

Вони розгортали ноутбуки для нового офісу. Команда мала «відомо робочий» USB з Windows 11, зроблений місяцями раніше, підписаний маркером і оброблявся як реліквія. Він працював на старіших моделях. Потім прийшла нова партія, і половина машин відмовлялась завантажувати його під UEFI.

Припущення було простим: «Якщо завантажується на одному ноутбуку, він завантажувальний». Це ігнорує неприємну правду: реалізації UEFI відрізняються, особливо щодо драйверів файлових систем і того, як вони перераховують знімні носії.

Після години перемикань налаштувань BIOS і звинувачень «партії ноутбуків» хтось перевірив макет USB. Це був один NTFS-розділ, бо творець вдарився об обмеження FAT32 4 GiB і вирішив переставити на NTFS. Старі моделі випадково вміли завантажувати NTFS. Нові — ні.

Виправлення було нудним: перебудувати носій з FAT32-розділом для завантаження і розбити install.wim. Цей урок потрапив до руйнбука: ніколи не покладайтеся на NTFS-завантаження, якщо ви не контролюєте моделі та версії прошивок. «Працює на одному» — це не план тестування.

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

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

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

Постмортем був передбачуваним: підтримка exFAT у прошивках UEFI не універсальна. Деякі вендори включають драйвери exFAT; багато — ні. Навіть в межах одного вендора це може змінюватись між поколіннями.

Вони повернулись до FAT32 і розбитих WIM. Продуктивність трохи погіршилась, але надійність різко покращилась, і час на образування зменшився, бо процес перестав випадково падати. Це SRE-версія «оптимізації»: спершу зменшуйте дисперсію.

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

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

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

Манифест виявив, що \sources\boot.wim існує, але має неправильний розмір на підмножині флешок. Це миттєво звузило пошук: часткове копіювання або збій запису. Знайшли партію флешок з контролерами, які скидались під час тривалих записів, мовчки обриваючи великі файли.

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

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

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

1) USB не з’являється в UEFI-меню

Симптом: USB видно в ОС, але в меню завантаження немає UEFI-запису для нього.
Причина: відсутній FAT32-розділ з EFI-путем; неправильна таблиця розділів/прапори; флешка відформатована в exFAT/NTFS; прошивка в режимі тільки legacy.
Виправлення: Перебудувати з GPT + FAT32 і забезпечити наявність \EFI\BOOT\BOOTX64.EFI. Вимкнути CSM/Legacy і увімкнути UEFI.

2) USB видно, але при завантаженні відразу повертає в прошивку

Симптом: Вибираєте USB, екран миготить, і ви повертаєтесь у BIOS/меню завантаження.
Причина: Secure Boot відкинув завантажувач; відсутні/пошкоджені EFI-файли; прошивка не може надійно читати файлову систему.
Виправлення: Підтвердити FAT32 і наявність EFI-файлів; тимчасово відключити Secure Boot для ізоляції проблеми; перебудувати з відомо робочого ISO на іншій флешці/порті.

3) Windows Setup починається, а потім помилка «відсутні драйвери» або «не знайдено носія»

Симптом: Інтерфейс setup завантажується, потім просить драйвер або каже, що не може знайти файли інсталяції.
Причина: пошкоджене/часткове копіювання; зламаний install.wim; використання USB 3 портів з глючним контролером/прошивкою; рідкісні відсутні драйвери контролера зберігання для цільового обладнання.
Виправлення: Перевірити розміри/хеші файлів; скопіювати знову; спробувати інший порт USB (часто USB 2 більш толерантний); підтвердити цілісність ISO; лише потім думати про інжекцію драйверів.

4) Помилка копіювання файлів у FAT32: «файл занадто великий»

Симптом: Копіювання падає на install.wim.
Причина: Обмеження FAT32 4 GiB на один файл.
Виправлення: Розбити WIM (dism /Split-Image) або використати ISO з install.esd (зазвичай менше). Уникайте переведення всієї флешки в NTFS, якщо ви не контролюєте прошивки.

5) Завантажується на одній моделі, не працює на іншій

Симптом: Та сама флешка дає різні результати на різних пристроях.
Причина: Різниця прошивок (підтримка NTFS/exFAT, особливості перерахунку USB, набори ключів Secure Boot).
Виправлення: Стандартизувати FAT32 UEFI-завантажувальний шлях; розбити WIM; тестувати на репрезентативному обладнанні. Якщо розгорнуті кастомні ключі Secure Boot — використовуйте затверджений носій/підпис.

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

Ви просили реальні завдання. Ось вони: не лише команди, але що означає вивід і яке рішення приймати далі. Команди показані так, ніби запускані з Linux-адмінбокса. Якщо ви на Windows — трактуйте їх як еквівалентні перевірки за допомогою Disk Management, PowerShell або вашого інструменту для образування.

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

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            SERIAL        TRAN FSTYPE MOUNTPOINTS
sda    477G Samsung_SSD_860  S3Z...        sata
├─sda1 512M                 ...                 vfat   /boot/efi
├─sda2  50G                 ...                 ext4   /
└─sda3 426G                 ...                 ext4   /var
sdb   28.9G Ultra_Fit        4C53...       usb
└─sdb1  28G                 ...                 exfat  /media/cr0x/USB

Що це означає: sdb — це флешка класу 32 ГБ (28.9G). Вона наразі у форматі exFAT, що є червоним прапором для сумісності UEFI-завантаження.

Рішення: Продовжуйте з переплануванням /dev/sdb. Перед початком ще раз перевірте модель/серійник.

Завдання 2: підтвердити, що USB не змонтований перед стиранням

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

Що це означає: Розділ змонтований.

Рішення: Відмонтуйте його чисто перед розміткою.

Завдання 3: відмонтувати розділи USB

cr0x@server:~$ sudo umount /dev/sdb1

Що це означає: Зазвичай відсутність виводу означає успіх.

Рішення: Перевірте, що його більше немає в mount, і продовжуйте.

Завдання 4: знищити підписи таблиці розділів (швидко й ефективно)

cr0x@server:~$ sudo wipefs -a /dev/sdb
/dev/sdb: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdb: 8 bytes were erased at offset 0x00000438 (exfat): 45 58 46 41 54 20 20 20

Що це означає: Старі DOS MBR та exFAT-підписи були видалені.

Рішення: Створіть новий GPT і розділи явно.

Завдання 5: створити GPT і один FAT32-розділ

cr0x@server:~$ sudo parted -s /dev/sdb mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sdb mkpart primary fat32 1MiB 100%
cr0x@server:~$ sudo parted -s /dev/sdb set 1 esp on
cr0x@server:~$ sudo parted -s /dev/sdb print
Model: SanDisk Ultra Fit (scsi)
Disk /dev/sdb: 31.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  31.0GB  31.0GB               primary  boot, esp

Що це означає: GPT створено; розділ 1 позначений як ESP і займає весь пристрій.

Рішення: Відформатуйте його в FAT32 і дайте нормальну мітку.

Завдання 6: форматувати FAT32 і дати мітку тому

cr0x@server:~$ sudo mkfs.vfat -F 32 -n WIN11_USB /dev/sdb1
mkfs.fat 4.2 (2021-01-31)

Що це означає: Створено файлову систему FAT32. Саме таке UEFI любить завантажуватися.

Рішення: Змонтируйте її і копіюйте вміст ISO.

Завдання 7: змонтувати ISO Windows у режимі тільки для читання

cr0x@server:~$ sudo mkdir -p /mnt/winiso
cr0x@server:~$ sudo mount -o loop,ro Win11_23H2_English_x64.iso /mnt/winiso
cr0x@server:~$ ls /mnt/winiso
autorun.inf  boot  bootmgr  bootmgr.efi  efi  sources  support

Що це означає: ISO змонтовано; він містить очікувану структуру Windows для інсталяції.

Рішення: Перевірте розмір install.wim або install.esd, щоб визначити, чи потрібно розбивати.

Завдання 8: визначити, чи поміщається образ на FAT32

cr0x@server:~$ ls -lh /mnt/winiso/sources/install.*
-r--r--r-- 1 root root 5.3G Jan 10 12:00 /mnt/winiso/sources/install.wim

Що це означає: install.wim має розмір 5.3G. FAT32 не може зберігати такий великий файл.

Рішення: Розбийте WIM на SWM-частини (Windows Setup підтримує це) і скопіюйте все інше звичайно.

Завдання 9: розбити install.wim на install.swm частини

На Linux найпростіший шлях — зробити розбиття на машині Windows за допомогою DISM. Але ви все одно можете організувати роботу тут; принцип важливий: на виході має бути кілька файлів .swm у \sources.

Припускаючи, що у вас є доступ до Windows, треба виконати:

cr0x@server:~$ printf '%s\n' "Run this on Windows:" "dism /Split-Image /ImageFile:D:\sources\install.wim /SWMFile:E:\sources\install.swm /FileSize:3800"
Run this on Windows:
dism /Split-Image /ImageFile:D:\sources\install.wim /SWMFile:E:\sources\install.swm /FileSize:3800

Що це означає: DISM створить install.swm, install2.swm тощо, кожен приблизно ~3.8 GB.

Рішення: Якщо ви не можете цього зробити, використайте Rufus (він може автоматизувати це) або отримайте ISO з install.esd, достатньо малим, щоб вміститись у FAT32. Не «вирішуйте» це переведенням всієї флешки в NTFS, якщо ви не контролюєте прошивки.

Завдання 10: скопіювати файли на USB (без занадто великого WIM)

cr0x@server:~$ sudo mkdir -p /mnt/usb
cr0x@server:~$ sudo mount /dev/sdb1 /mnt/usb
cr0x@server:~$ sudo rsync -avh --exclude='sources/install.wim' /mnt/winiso/ /mnt/usb/
sending incremental file list
./
autorun.inf
boot/
boot/boot.sdi
bootmgr
bootmgr.efi
efi/
efi/boot/
efi/boot/bootx64.efi
sources/
sources/boot.wim
sources/setup.exe
...
sent 1.02G bytes  received 18.4K bytes  54.2M bytes/sec
total size is 5.89G  speedup is 5.75

Що це означає: Все, крім install.wim, скопійовано. Зверніть увагу на наявність efi/boot/bootx64.efi — це критичний шлях UEFI-завантажувача.

Рішення: Розмістіть розбиті файли install*.swm у /mnt/usb/sources/. Потім перевірте наявність файлів та їхні розміри.

Завдання 11: підтвердити наявність EFI-завантажувача на USB

cr0x@server:~$ ls -l /mnt/usb/EFI/BOOT/BOOTX64.EFI
-rwxr-xr-x 1 root root 1556480 Jan 10 12:00 /mnt/usb/EFI/BOOT/BOOTX64.EFI

Що це означає: Канонічний EFI-завантажувач для знімних носіїв присутній.

Рішення: Якщо цього файлу немає — не тестуйте; виправте копіювання або перебудуйте носій.

Завдання 12: перевірити тип файлової системи і мітку (впіймати «ой NTFS» раніше)

cr0x@server:~$ lsblk -f /dev/sdb
NAME   FSTYPE FSVER LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb
└─sdb1 vfat   FAT32 WIN11_USB 2A3B-1C2D                             24.1G    22%  /mnt/usb

Що це означає: FAT32 на місці. Добре.

Рішення: Відмонтуйте акуратно; не виривайте пристрій під час запису.

Завдання 13: скинути буфери запису і відмонтувати

cr0x@server:~$ sync
cr0x@server:~$ sudo umount /mnt/usb

Що це означає: Дані записано, файлова система чиста.

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

Завдання 14: перевірити цілісність ISO за SHA256 (довіряй, але перевіряй)

cr0x@server:~$ sha256sum Win11_23H2_English_x64.iso
5f2a2b1d7d0c1f0c7b7c4d8e2d4f7a6d1c2b3a4f5e6d7c8b9a0f1e2d3c4b  Win11_23H2_English_x64.iso

Що це означає: У вас є хеш для порівняння.

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

Завдання 15: перевірити системний журнал на тихі I/O помилки під час запису

cr0x@server:~$ dmesg --since "10 minutes ago" | tail -n 20
[  +0.000000] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[  +2.143211] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Що це означає: Ядро помітило некоректне відмонтування в якийсь момент. Це може спричиняти «випадкові» відмови завантаження або відсутні файли.

Рішення: Запустіть перевірку файлової системи або перебудуйте флешку. Для інсталяційного носія перебудова часто швидша, ніж довіряти відновленому FAT.

Завдання 16: виконати перевірку FAT файлової системи (коли підозрюєте корупцію)

cr0x@server:~$ sudo fsck.vfat -a /dev/sdb1
fsck.fat 4.2 (2021-01-31)
Reclaimed 12 unused clusters (49152 bytes).
Performing changes.

Що це означає: Невеликі невідповідності виправлено. Це вже запах: знімні носії не повинні потребувати ремонту одразу після створення.

Рішення: Якщо це відбувається повторно з тією ж моделлю флешок — виведіть її з обігу. Носії дешеві; відмови дорогі.

Часті запитання

1) Чи можна просто відформатувати USB в NTFS і скопіювати вміст ISO?

Можна, і воно може завантажитися на деяких системах. На інших прошивка UEFI не читає NTFS під час завантаження. Для змішаного парку FAT32 — безпечніша файлова система для завантаження. Великий WIM вирішуйте розбиттям.

2) Чому FAT32 важливий, якщо Windows підтримує NTFS?

Бо Windows ще не завантажується. Прошивка завантажується. UEFI-прошивка очікується, що читає FAT-файлові системи; підтримка NTFS опціональна і непослідовна серед вендорів.

3) У моєму ISO `install.esd` замість `install.wim`. Це гаразд?

Так. Windows Setup підтримує install.esd. Зазвичай він менший через сильнішу компресію і може поміститися в межах FAT32. Якщо поміщається — життя значно простіше.

4) Який найсумісніший макет для USB інсталятора Windows 11?

Таблиця розділів GPT, один FAT32-розділ, позначений як ESP, та скопійовані туди файли Windows. Якщо образ занадто великий — розбийте install.wim в install*.swm.

5) Якщо USB завантажується лише при вимкненому Secure Boot, що робити?

Це вказує, що ви не використовуєте шлях завантаження, довірений Secure Boot (або в організації кастомні ключі). Перебудуйте носій за допомогою Media Creation Tool або стандартного ISO і консервативного способу створення. Якщо застосовані кастомні ключі — використовуйте затверджені корпоративні носії.

6) Чи є Ventoy «правильним» методом для Windows 11 UEFI + Secure Boot?

Може працювати, і зручно носити кілька ISO. Але він додає ще один шар завантаження і розширює площу політики. Якщо ви образуєте парк і хочете мінімальної дисперсії — використовуйте стандартний інсталяційний носій. Якщо ви лабораторний інженер, що тестує багато ISO — Ventoy може бути придатним, але тестуйте поведінку Secure Boot у вашому середовищі.

7) Чому мій USB показується двічі в меню завантаження?

Часто ви побачите і legacy-запис, і UEFI-запис. Вибирайте UEFI. Якщо завантажуватись у legacy/CSM, надалі ви можете отримати інші налаштування розділів і несподівані взаємодії з BitLocker/TPM.

8) Windows Setup каже, що не може знайти драйвер для мого диска. Чи неправильно зроблений USB?

Можливо, але не завжди. Спочатку перевірте цілісність вмісту USB (розміри/хеші) і спробуйте інший порт. Якщо цільове обладнання потребує драйверів контролера зберігання (рідше на сучасних ноутбуках, частіше на серверах), тоді можливо треба надати драйвери. Не починайте з цього.

9) Чи варто вимкнути Fast Boot у BIOS при завантаженні з інсталяційного USB?

На деяких системах так. «Fast Boot» може пропускати ініціалізацію USB-пристроїв і робити меню завантаження ненадійним. Якщо USB з’являється нестабільно — вимкніть Fast Boot під час інсталяції.

10) Чи важливий GPT на USB, якщо він знімний?

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

Висновок: наступні кроки, що дійсно знижують ризик

Якщо ви хочете USB з інсталятором Windows 11, що завантажується під UEFI з Secure Boot, припиніть ставитись до цього як до задачі «скопіювати файли на флешку». Спостерігайте на ланцюжок завантаження та обмеження файлової системи.

Зробіть наступне:

Стандартизуйте один метод для вашої організації: Media Creation Tool або Rufus з GPT/UEFI/FAT32 і розбиттям WIM. Запишіть його.
Зробіть валідацію обов’язковою: перевіряйте наявність \EFI\BOOT\BOOTX64.EFI, підтверджуйте FAT32, підтверджуйте стратегію образу (.esd або розбиті .swm).
Тестуйте на принаймні двох моделях обладнання з увімкненим Secure Boot, перш ніж оголосити перемогу.
Агресивно виводьте з обігу погані носії: якщо флешка викликає помилки файлової системи або дає часткове копіювання — вона підлягає утилізації. Не торгуйтесь.

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

Схожі статті

Створити завантажувальний USB, який дійсно завантажується (UEFI/Legacy правильно) Встановлення Fedora Workstation 43: метод однієї USB, який просто працює