Двовантаження Windows + Linux: налаштування, що переживе оновлення

Принципи: що насправді ламається і чому

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

Ланцюг завантаження, простою мовою

На сучасних ПК потрібно використовувати UEFI + GPT. Прошивка завантажує запис завантаження (NVRAM-запис, що вказує на EFI виконуваний файл).
Цей виконуваний файл зазвичай — Windows Boot Manager або Linux-завантажувач (GRUB або systemd-boot).
Далі ви обираєте ОС, завантажуєте ядро, і тільки після цього опиняєтеся в звичній системі ініціалізації.

Що ламається під час оновлень, зазвичай одне з:

• Зміни в порядку завантаження UEFI NVRAM (оновлення Windows любить піднімати свій запис вгору).
• Зміни в змісті EFI System Partition (ESP) (файли додаються/видаляються, іноді перезаписуються).
• Невідповідність політики Secure Boot (ключі, shim, підписи).
• Зміни ідентичності диска (клонування, переміщення дисків, оновлення прошивки, що змінюють порядок накопичувачів).
• Конфлікт доступу до файлової системи (Windows Fast Startup і гібернація лишають NTFS «брудним»).

Надійний проєкт — це не «встановити Linux поруч із Windows і молитися». Це:
розділити відповідальності, мінімізувати спільний стан і вміти відтворно відновити завантаження.

Якщо запам’ятати лише одне: ваш ESP — не смітник. Ставтеся до нього як до production-конфігурації.
Резервуйте його. Тримайте маленьким і нудним. Знайте, що на ньому лежить.

Жарт №1: Двовантажна машина як двоє менеджерів — все добре, доки обидва не «володіють» графіком.

Цікаві факти та трохи історії

Кілька контекстних речей, що роблять сьогоднішні рекомендації менш довільними:

1. UEFI замінив legacy BIOS щоб модернізувати завантаження, увімкнути Secure Boot і позбутися обмежень MBR щодо таблиці розділів.
2. MBR історично обмежував диски до ~2 ТБ і чотирьох primary розділів. GPT це виправив, тому розмітки для dual-boot стали здоровішими з часом.
3. ESP стандартизований: зазвичай FAT32 і призначений для збереження EFI виконуваних файлів для кількох ОС — співіснування це дизайн, а не хаки.
4. Windows Boot Manager став центром тяжіння у багатьох OEM-зборках; виробники часто жорстко налаштовують пріоритети завантаження на його користь.
5. Secure Boot починався як функція безпеки, але став операційною змінною: корисний при консистентності, болісний при змішаних дистрибутивах і кастомних ядрах.
6. GRUB став популярним частково за гнучкість щодо багатьох файлових систем і багато-ОС виявлення; systemd-boot набирає популярності як UEFI-нативний і простіший варіант.
7. BitLocker змінив гру: це не лише шифрування; це ще й «система виявлення змін», що реагує на модифікації шляху завантаження.
8. Fast Startup по суті — легка гібернація: вона лишає NTFS у стані, який Linux не повинен монтувати як RW, тому спільні розділи можуть загадково корумпуватися.

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

Вибір архітектури: один диск, два диски, один ESP, два ESP

Найміцніший варіант: окремі фізичні накопичувачі

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

В такій конфігурації я віддаю перевагу двом ESP (по одному на диск), коли прошивка поведеться дружно і ви хочете максимальної ізоляції.
Якщо прошивка примхлива, можна використовувати один ESP на диску Windows і все одно тримати Linux root цілком окремо.

Чому це переживає оновлення: кожна ОС зберігає свої файли завантаження. Записи NVRAM можуть все ще змінюватися, але базові файли залишаються цілими.

Найпоширеніший варіант: один диск, спільний ESP

Один диск цілком підходить, якщо ви дисципліновані. У вас буде один ESP (FAT32) і окремі розділи для Windows і Linux.
Режим відмови тут не «Linux перезаписав Windows». Це «оновлення Windows піднесло себе на вершину, і ви забули, як вибрати інший запис».

Спільний ESP не є по суті крихким; він стає крихким, якщо ним не управляють. Резервуйте його і уникайте випадкових експериментів із завантажувачами.

GRUB vs systemd-boot: виберіть бюджет складності

• GRUB: найкращий, коли хочете одне меню, що керує всім, підтримку багатьох ядер, chainload Windows і роботу з дивними файловими системами. Більше рухомих частин.
• systemd-boot: простіший, UEFI-нативний. Читає записи з ESP і завантажує EFI stubs. Менше «магічних скриптів», менше сюрпризів.

Моя думка: якщо у вас мейнстрім дистро на сучасному ноутбуці з UEFI, systemd-boot — спокійніше життя.
Якщо потрібна складна багатозавантажувальна детекція й кастомні ланцюги, GRUB все ще — швейцарський ніж.

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

Перед тим як перерозбивати щось, треба знати, що у вас насправді є. Не те, що ви думаєте.
Напівдвовантажні «таємниці» часто виникають через те, що хтось встановив у legacy режимі на UEFI машині, або змішав MBR і GPT як у 2009 році.

Вирішіть ці питання наперед

• Тільки UEFI завантаження (без CSM/legacy)
• GPT-розбиття диска
• BitLocker: увімкнений чи вимкнений, і як керуватимете ключами відновлення
• Secure Boot: увімкнений (переважно), якщо ваш дистро його підтримує; вимкнений, якщо ви використовуєте кастомні ядра і не хочете керувати ключами
• Спільні дані: так чи ні (якщо так, використовуйте окремий data-розділ з чіткими правилами)

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

Плани розмітки, що переживають оновлення

Базова розмітка UEFI/GPT (один диск)

Нудна, стійка до оновлень розмітка:

• ESP: 512 MiB — 1 GiB, FAT32, монтується в Linux як /boot/efi
• MSR: Microsoft Reserved (створюється Windows)
• Windows: NTFS для C:
• Linux root: ext4 або btrfs
• Linux swap: опціонально, якщо використовуєте swapfile; обов’язковий для надійної гібернації
• Спільні дані (опціонально): exFAT або NTFS, але див. правила нижче

Правила для спільного розділу даних (щоб не корумпувати його)

Якщо ви ділите NTFS розділ між Windows і Linux:

• Вимкніть Windows Fast Startup, інакше Linux побачить том як гібридний/забруднений і монтування RW стане небезпечним.
• Ніколи не монтуйте системні томи Windows у RW з Linux, якщо Windows знаходиться в гібернації. Використовуйте окремий розділ shared-data для RW доступу.
• Віддавайте перевагу exFAT для «простого зберігання» (фотографії, інсталятори), якщо не потрібні NTFS ACL. Це простіше для крос-ОС.

Двохдискова розмітка (рекомендовано, якщо можете)

Якщо у вас два SSD:

• Диск 0 (Windows): ESP + MSR + Windows
• Диск 1 (Linux): опціональний ESP (якщо хочете ізоляцію) + Linux root + опціональний swap + опціональний /home

Частина «не ламається під час оновлень» тут походить із ізоляції і можливості встановити пріоритет завантаження в прошивці на потрібний диск.
У гіршому випадку ви вибираєте інший диск з one-time boot menu і продовжуєте роботу.

Порядок встановлення та стратегія завантажувача (мої рекомендації)

Спершу встановіть Windows, потім Linux

Інсталятори Windows припускають, що вони — єдина ОС у світі. Інсталятори Linux загалом поводяться чемніше щодо співіснування.
Тож спочатку встановіть Windows, повністю оновіть її, потім зменшіть її розділ і встановіть Linux.

Виберіть «основний» завантажувач свідомо

У вас є дві адекватні моделі:

• Linux-завантажувач як основний: GRUB/systemd-boot пропонують меню і chainload для Windows.
• Windows Boot Manager як основний: Windows завантажується звично, а Linux обирають через меню прошивки або доданий запис у Windows.

Для більшості людей, які дійсно використовують Linux щодня, перша модель краща. Для корпоративних пристроїв з агресивною політикою Windows друга модель менше викликає проблем.

Secure Boot і BitLocker: вирішіть заздалегідь

Secure Boot може співіснувати з Linux, якщо ваш дистро використовує shim + підписані завантажувачі. BitLocker теж може співіснувати, але він чутливий до змін в ланцюгу завантаження.
Операційне правило: закінчіть налаштування завантажувача, потім увімкніть BitLocker (або призупиніть його під час змін).

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

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

Завдання 1: Підтвердити, що інсталятор завантажився в UEFI режимі

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  esrt  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars

Що це означає: Якщо існує /sys/firmware/efi, ви завантажилися в UEFI режимі. Якщо ні — ви в legacy/CSM режимі.
Рішення: Якщо не UEFI, зупиніться і перезавантажте USB у UEFI режимі. Змішування режимів — це шлях до «працює до перезавантаження».

Завдання 2: Підтвердити, що диск має GPT (не MBR)

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

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  538MB   537MB   fat32        EFI system partition          boot, esp
 2      538MB   672MB   134MB                Microsoft reserved partition  msftres
 3      672MB   300GB   299GB   ntfs         Basic data partition          msftdata
 4      300GB   1000GB  700GB

Що це означає: «Partition Table: gpt» — те, що вам потрібно.
Рішення: Якщо це msdos/MBR і ви хочете сучасне UEFI двовантаження, плануйте конверсію (або перевстановлення). Не запихайте новий Linux на legacy-boot, якщо можете цього уникнути.

Завдання 3: Виявити EFI System Partition (ESP)

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTFLAGS,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTFLAGS MOUNTPOINTS
nvme0n1   931.5G
├─nvme0n1p1 512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b boot,esp  /boot/efi
├─nvme0n1p2 128M        e3c9e316-0b5c-4db8-817d-f92df00215ae
├─nvme0n1p3 299G ntfs   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
└─nvme0n1p4 632G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 /

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

Завдання 4: Переглянути вміст ESP (хто що встановив)

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

Що це означає: Ви бачите артефакти завантаження Windows і Linux, що живуть поруч.
Рішення: Якщо файли Linux відсутні після оновлення, відновіть їх із резервної копії або перевстановіть завантажувач. Якщо файли Microsoft відсутні, Windows recovery їх відновить.

Завдання 5: Перевірити UEFI записи завантаження та порядок

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,0001
Boot0000* Windows Boot Manager  HD(1,GPT,2c2d...,0x800,0x100000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* UEFI: USB Disk  1.00
Boot0003* ubuntu  HD(1,GPT,2c2d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Що це означає: BootOrder вирішує, що буде без взаємодії з користувачем. Оновлення Windows часто піднімає Boot0000 вгору.
Рішення: Якщо Linux не перший і ви хочете, щоб він був першим — змініть BootOrder. Якщо Windows має залишатися першим (корпоративно), прийміть це і користуйтесь одноразовим меню завантаження.

Завдання 6: Встановити запис Linux першим (якщо ви хочете GRUB/systemd-boot основним)

cr0x@server:~$ sudo efibootmgr -o 0003,0000,0001
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001

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

Завдання 7: Виявити, чи Windows у гібернації / Fast Startup «забруднив» NTFS

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
NTFS signature is missing.
FAILED

Що це означає: На невірному розділі ви побачите «NTFS signature missing.» Це корисна помилка: ви вцілили не в той пристрій.
Рішення: Перевірте відображення розділів; не «чиніть» випадкові розділи.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/nvme0n1p3 was processed successfully.

Що це означає: Базові метадані в порядку. Це не доводить, що Windows завершилася коректно, але зменшує підозри.
Рішення: Якщо Linux все ще відмовляється монтувати RW через гібернацію, завантажте Windows, виконайте повне вимкнення і вимкніть Fast Startup.

Завдання 8: Підтвердити розділи Windows і прапорці перед зміною розміру

cr0x@server:~$ sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disklabel type: gpt

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1     2048    1050623    1048576   512M EFI System
/dev/nvme0n1p2  1050624    1312767     262144   128M Microsoft reserved
/dev/nvme0n1p3  1312768  626000000  624687233 298.0G Microsoft basic data
/dev/nvme0n1p4 626000001 1953523711 1327523711 633.5G Linux filesystem

Що це означає: Ви бачите точні межі. Це те, на що посилаєтеся при написанні команд відновлення пізніше.
Рішення: Якщо Windows на p3 і Linux на p4, зберігайте так. Уникайте перемішування розділів, що ускладнює майбутнє змінення розмірів.

Завдання 9: Перевірити стан Secure Boot з Linux

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

Що це означає: Secure Boot увімкнено. Ваш ланцюжок завантаження Linux має бути підписаний відповідно.
Рішення: Якщо плануєте запуск unsigned ядер/модулів, або зареєструйте власні ключі (складніше), або вимкніть Secure Boot. Не робіть напівзаходів.

Завдання 10: Резервне копіювання ESP (це ваша кнопка «не панікуй»)

cr0x@server:~$ sudo mkdir -p /root/esp-backup
cr0x@server:~$ sudo tar -C /boot/efi -czf /root/esp-backup/esp-efi.tgz EFI
cr0x@server:~$ sudo ls -lh /root/esp-backup/esp-efi.tgz
-rw-r--r-- 1 root root 38M Feb  5 10:12 /root/esp-backup/esp-efi.tgz

Що це означає: У вас є знімок вмісту ESP на певний момент часу.
Рішення: Скопіюйте цей архів за межі машини (USB, інший хост). Якщо диск помре, локальні резерви — це мотиваційні плакати.

Завдання 11: Якщо GRUB відсутній — перевстановити його (UEFI режим)

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.

Що це означає: GRUB EFI бінарні файли записані на ESP і, ймовірно, створено/оновлено запис завантаження.
Рішення: Далі відновіть конфіг. Якщо ви на дистро, що віддає перевагу shim — переконайтесь, що shim теж встановлено.

Завдання 12: Перегенерувати меню GRUB (виявити Windows)

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

Що це означає: GRUB виявив Windows Boot Manager і додав його в меню.
Рішення: Якщо Windows не знайшли, зазвичай ESP не змонтовано або os-prober вимкнено в налаштуваннях дистрибутива. Виправте це, замість правки довільних GRUB скриптів.

Завдання 13: Для користувачів systemd-boot — перелічити та встановити записи завантаження

cr0x@server:~$ bootctl status
System:
     Firmware: UEFI 2.70
  Secure Boot: enabled
   Setup Mode: no
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 255.4
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control

Available Boot Loaders on ESP:
          ESP: /boot/efi (vfat)
         File: └─/EFI/systemd/systemd-bootx64.efi

Boot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0005
       Status: active, boot-order

Що це означає: systemd-boot присутній і зареєстрований.
Рішення: Якщо він не в EFI змінних, можливо, потрібно виконати bootctl install або створити запис через efibootmgr залежно від дистро.

Завдання 14: Правильно змонтувати ESP з live USB під час рятування

cr0x@server:~$ sudo mount /dev/nvme0n1p4 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ mount | grep -E '/mnt|efi'
/dev/nvme0n1p4 on /mnt type ext4 (rw,relatime)
/dev/nvme0n1p1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Що це означає: Ви змонтували Linux root і ESP у середовище рятування. Тепер команди перевстановлення завантажувача спрямовуватимуться в потрібне місце.
Рішення: Якщо змонтували неправильний ESP (часта проблема при кількох дисках), ви «виправите» нічого, відчуваючи продуктивність. Перевіряйте ідентифікатори пристроїв.

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

cr0x@server:~$ sudo efibootmgr | sed -n '1,6p'
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu

Що це означає: Наразі ви завантажені через Windows Boot Manager (BootCurrent 0000).
Рішення: Якщо очікували Linux-завантажувач, змініть BootOrder або використайте одноразове меню завантаження, а потім перевірте знову.

Завдання 16: Зробити знімок ESP після оновлень Windows

cr0x@server:~$ sudo sh -c 'cd /boot/efi && find EFI -maxdepth 3 -type f -printf "%p %s\n" | sort | tail -n 8'
EFI/Microsoft/Boot/bootmgfw.efi 1705984
EFI/Microsoft/Boot/bootmgr.efi 1050632
EFI/Microsoft/Boot/memtest.efi 1105920
EFI/ubuntu/grubx64.efi 2867200
EFI/ubuntu/shimx64.efi 1204224
EFI/ubuntu/mmx64.efi 845824
EFI/Boot/bootx64.efi 1204224
EFI/Boot/fbx64.efi 2252800

Що це означає: У вас швидкий огляд «що змінилося». Несподівані додавання як EFI/Boot/bootx64.efi можуть бути нормою (fallback-завантажувачі), але раптові видалення — ні.
Рішення: Якщо файли Linux зникли, відновіть з резервної копії ESP або перевстановіть завантажувач. Якщо ESP заповнюється, розширіть його зараз — не під час інциденту.

Завдання 17: Діагностувати невідповідності UUID диска в Linux fstab

cr0x@server:~$ sudo blkid /dev/nvme0n1p1 /dev/nvme0n1p4
/dev/nvme0n1p1: UUID="3A1B-2C3D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="2c2d..."
/dev/nvme0n1p4: UUID="2b5c0b2b-0b5a-4d7f-9f41-6f2c9a2a1c77" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9a12..."

Що це означає: У вас є істинні ідентифікатори.
Рішення: Якщо ваш /etc/fstab посилається на UUID, якого більше немає (поширено після клонування), виправте його перед перезавантаженням, щоб не опинитися в initramfs.

Завдання 18: Перевірити, чи існує Windows Boot Manager на ESP

cr0x@server:~$ sudo test -f /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi && echo OK || echo MISSING
OK

Що це означає: Windows-завантажувач існує.
Рішення: Якщо він відсутній, використовуйте Windows repair media. Не «позичаєте» випадкові EFI бінарні файли з інтернету; саме так отримують шкідливе ПЗ з чудовою доступністю.

Жарт №2: ESP — це FAT32, що пасує: тут ваші проблеми з завантаженням ростуть у вазі.

Швидкий план діагностики

Коли двовантажна система не завантажується, не починайте перевстановлювати ОС, наче вам платять за кожне завантаження.
Хочете швидко звузити проблему: прошивка та режим завантаження, запис завантаження, вміст ESP, ядро/initramfs або файлова система.

Перше: прошивка і режим завантаження

• Перевірте режим завантаження: Чи UEFI ви? Якщо випадково завантажили legacy запис — все інше вже неважливо.
• Використайте одноразове меню завантаження: Явно оберіть «Windows Boot Manager» проти «ubuntu» або «Linux Boot Manager» і подивіться на поведінку.
• Якщо Secure Boot увімкнено: Зверніть увагу, чи це помилка перевірки підпису в прошивці, чи помилка GRUB/ядра.

Друге: здоров’я і вміст ESP

• З live Linux USB змонтуйте ESP і перелічіть /EFI/Microsoft та вашу Linux директорію (/EFI/ubuntu, /EFI/fedora тощо).
• Якщо ESP відсутній або пошкоджений — побачите помилки монтування або порожні папки. Це не «проблема конфігу GRUB». Це проблема збереження.
• Перевірте вільне місце на ESP: якщо майже повний, оновлення можуть провалюватися дивними способами.

Третє: записи UEFI NVRAM

• efibootmgr -v покаже, що думає прошивка.
• Якщо запис Linux вказує на файл, що зник, відтворіть його, перевстановивши завантажувач або використавши efibootmgr.
• Якщо запис існує, але ніколи не використовується, виправте BootOrder або налаштування прошивки.

Четверте: ядро Linux і кореневий FS

• Якщо GRUB з’являється, але Linux не завантажується — перевірте, чи змінився UUID кореня або чи initramfs не може знайти root-пристрій.
• Якщо попадає в initramfs shell — зазвичай це проблема з найменуванням пристроїв/UUID або відсутні драйвери (рідко на ноутбуках; часто на RAID/HBA конфігураціях).

П’яте: специфічні проблеми Windows

• Якщо Windows падає, а Linux завантажується — не намагайтеся «чинити Windows» зсередини Linux, окрім перевірки, що Windows EFI файл існує.
• Якщо BitLocker просить ключ відновлення після змін завантаження — це очікувана поведінка; отримаєте recovery key і стабілізуйте ланцюжок завантаження.

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

1) «Після оновлення Windows завантажується одразу»

Симптом: Меню GRUB/systemd-boot зникло; завантажується Windows.
Корінь: Windows підняв «Windows Boot Manager» у BootOrder або скинув налаштування прошивки.
Виправлення: З Linux (або live USB) запустіть efibootmgr -v і відновіть BootOrder. Якщо не можете завантажити Linux, використайте одноразове меню прошивки, щоб запустити Linux-запис, а потім зафіксуйте BootOrder.

2) «Linux завантажується, але запис Windows відсутній в GRUB»

Симптом: У меню GRUB лише ядра Linux, немає опції Windows.
Корінь: ESP не змонтовано в /boot/efi під час update-grub, або os-prober вимкнено налаштуваннями дистро.
Виправлення: Змонтуйте ESP, увімкніть os-prober за потреби, перезапустіть update-grub. Перевірте наявність /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi.

3) «Том Windows тільки для читання або не монтується в Linux»

Симптом: Linux відмовляється монтувати RW; в логах згадується «hibernated» або «unsafe state».
Корінь: Windows Fast Startup або гібернація залишили NTFS брудним.
Виправлення: Завантажте Windows, вимкніть Fast Startup, виконайте повне вимкнення. Не змушуйте примусове монтування RW, якщо любите ризик втрати даних.

4) «Запит ключа відновлення BitLocker після встановлення Linux»

Симптом: Windows просить ключ відновлення після змін двовантаження.
Корінь: Змінився ланцюжок завантаження (EFI запис, завантажувач, стан Secure Boot). BitLocker сприймає це як можливе втручання.
Виправлення: Завантажтесь з recovery key один раз, а потім стабілізуйте: тримайте стан Secure Boot постійним, уникайте частих змін завантажувача і пере-запечатайте BitLocker, призупинивши потім відновивши його після фінального налаштування.

5) «GRUB з’являється, але Linux падає в initramfs з ‘cannot find UUID’»

Симптом: Ядро стартує і зупиняється, вимагаючи вручну вказати root-пристрій.
Корінь: UUID кореневого розділу змінився (клон, відновлення) або /etc/fstab посилається на неправильний UUID; іноді GRUB командний рядок вказує неправильний root.
Виправлення: Використайте blkid щоб знайти правильні UUID; оновіть /etc/fstab, перегенеруйте initramfs і перевірте конфігурацію завантажувача.

6) «Secure Boot увімкнено: Linux не завантажується після оновлення ядра»

Симптом: Прошивка або shim повідомляють про помилки перевірки/підпису.
Корінь: Непідписане ядро/модуль, зламана реєстрація shim/MOK або змішування кастомних збірок зі Secure Boot без керування ключами.
Виправлення: Використовуйте підписані дистро-ядра, або зареєструйте свій Machine Owner Key і підписуйте ядра/модулі, або вимкніть Secure Boot (але робіть це свідомо).

7) «ESP закінчився і тепер оновлення падають»

Симптом: Оновлення ядер провалюються, записи завантаження непослідовні, або помилки монтування ESP показують майже 100% використання.
Корінь: Занадто малий ESP (старий OEM дефолт 100–200 MiB) плюс кілька завантажувачів/ядер/shim.
Виправлення: Збільште розмір ESP (акуратно) або очистіть старі артефакти. Правильне рішення зазвичай — змінити розмір до принаймні 512 MiB.

Три міні-історії з корпоративного життя

Міні-історія 1: Інцидент, спричинений неправильною припущенням

Середня компанія розгорнула ноутбуки розробників з Windows для корпоративних інструментів і Linux для збіркових пайплайнів. Стандартна справа.
У документі rollout було: «Встановіть Linux. GRUB автоматично покаже Windows.» Ця фраза зіпсувалася, як молоко.

На партії новіших ноутбуків інсталятор Linux був завантажений у legacy режимі (оскільки USB мав два варіанти завантаження і люди вибирали перший).
Linux встановився нормально. GRUB встановився нормально. Машина навіть завантажувалася — поки не прилетів оновлення прошивки через Windows Update і тихо не відключив CSM.

Наступного ранку: чорний екран і «No bootable device». Windows все ще був на диску. Linux теж був.
Але завантажувачі були встановлені для legacy boot, у той час як прошивка тепер вимагала лише UEFI.

Виправлення не було магією. Вони відбудували ланцюг завантаження: створили/перевірили ESP, перевстановили Linux-завантажувач у UEFI режимі і переконалися, що Windows має правильний UEFI запис.
Справжнє виправлення було культурним: у чеклісті додали «перевірити UEFI режим» як жорстку умову перед інсталяцією, використовуючи точну перевірку /sys/firmware/efi.

Міні-історія 2: Оптимізація, що відгукнулася боком

Інша організація намагалася «оптимізувати» використання диска на тонких SSD. Вони звузили ESP до мінімуму, який бачили в OEM-розмітках.
Також вони консолідували завантажувачі, видаляючи «дублікати» EFI файлів, коли помічали їх.

Все виглядало чисто. Деякий час. Потім оновлення ядра Linux мало оновити shim-файли, а Windows feature update оновив свої компоненти завантаження.
FAT32 не робить тонких операцій. ESP заповнився, записи частково записувалися, і система отримала несумісні артефакти завантаження.

Симптоми були непостійні: деякі пристрої завантажували Linux, але не Windows, інші — навпаки, дехто взагалі падав у shell прошивки.
Команді довелося витратити години, бо кожен ноутбук «виглядав унікальним», тоді як причина була нудно однакова: ESP був занадто малий.

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

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

Безпекова компанія мала двовантажні пристрої для респондентів інцидентів. У них був BitLocker, Secure Boot і Linux для криміналістики.
Звучить як рецепт драм. Але не сталося, бо вони ставилися до конфігурації завантаження як до інфраструктури.

Кожен пристрій мав: резервну копію ESP після провізіонування, невеликий рукописний runbook у пакеті пристрою (так, паперовий) і ключі відновлення, збережені за правилами.
Runbook містив рівно три команди: efibootmgr -v, монтування ESP + перелік і послідовність перевстановлення завантажувача.

Під час циклу оновлення Windows деякі ноутбуки змінили BootOrder і почали завантажувати Windows за замовчуванням.
Користувачі одразу помітили це, бо їхній робочий процес очікував Linux першим. Ніхто не панікував.

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

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

План A: Best-practice dual boot на одному диску (UEFI/GPT)

1. Оновіть BIOS/UEFI прошивку перед інсталяцією.
   Оновлення прошивки після встановлення можуть змінити порядок завантаження або перемикати налаштування. Позбавтеся хаосу заздалегідь.
2. Налаштуйте прошивку: лише UEFI (відключіть CSM), вирішіть Secure Boot увімкнено/вимкнено, встановіть режим SATA (AHCI, якщо не потрібно RAID).
3. Встановіть Windows першою. Нехай вона створить ESP/MSR. Завершіть початкове налаштування та оновлення.
4. Вимкніть Fast Startup у Windows, якщо плануєте доступ до NTFS з Linux.
5. Зменшіть розділ Windows зсередини Windows Disk Management (безпечніше, ніж робити це в Linux для NTFS).
6. Завантажте інсталятор Linux у UEFI режимі і підтвердіть це за допомогою ls /sys/firmware/efi.
7. Встановіть Linux у вільний простір. Змонтуйте існуючий ESP як /boot/efi; не форматуючи його.
8. Оберіть завантажувач: встановіть GRUB або systemd-boot як основний (мій пріоритет: systemd-boot, якщо підтримується чисто).
9. Перезавантажте та перевірте: обидва шляхи завантаження, порядок завантаження в прошивці і що Windows завантажується без BitLocker сюрпризів.
10. Зробіть резервну копію ESP і зберігайте архів поза пристроєм.

План B: Два диски (максимальна життєздатність)

1. Встановіть Windows на Диск 0 з власним ESP.
2. Встановіть Linux на Диск 1, бажано з власним ESP також.
3. Встановіть у прошивці диск за замовчуванням того, яку ОС хочете бачити першою; інший залиште доступним через меню завантаження.
4. Резервуйте обидва ESP; підпишіть їх серійними номерами дисків.

Операційні правила (зробіть це і майбутнє ви буде менш сердитим)

• Тримайте ESP ≥ 512 MiB. Старі OEM 100 MiB ESP — пастка.
• Не використовуйте системний розділ Windows для RW доступу з Linux. Якщо ділите, використовуйте окремий розділ для даних.
• Робіть одну зміну за раз. Завантажувач + Secure Boot + BitLocker одночасно — як втратити причинність.
• Записуйте ваші записи завантаження (скопіюйте вивід efibootmgr -v у нотатку). Коли зламається, вам потрібна «до і після» картина.
• Майте live USB з Linux, що вміє монтувати ваші файлові системи і містить efibootmgr/mokutil.

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

1) Чи варто робити двовантаження, чи краще використовувати VM?

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

2) Чи можуть оновлення Windows видалити GRUB?

Частіше вони змінюють BootOrder на користь Windows Boot Manager. Фактичне видалення трапляється рідше, але можливе, якщо ESP пошкоджено, занадто мале або його «очистили» люди.
Ставтеся до ESP як до критичного спільного стану і робіть резервні копії.

3) Чи безпечно мати один спільний ESP?

Так, якщо він має правильний розмір (512 MiB+), змонтований коректно і не модифікується вручну регулярно.
Спільний ESP — стандартна модель, для якої створений UEFI. Крихкість походить від поганої гігієни, а не від самої ідеї.

4) Чи варто вимикати Secure Boot?

Якщо ви використовуєте стандартні дистро-ядра, тримайте Secure Boot увімкненим. Це реальний контроль безпеки і зазвичай працює.
Якщо плануєте запускати кастомні ядра/модулі і не бажаєте керувати підписами — вимкніть його. Виберіть і притримуйтеся.

5) Як уникнути запитів BitLocker recovery?

Не змінюйте ланцюг завантаження після увімкнення BitLocker, якщо не призупините його спочатку. Стабілізуйте завантажувач, налаштування прошивки і стан Secure Boot, потім вмикайте BitLocker.
Зберігайте ключі відновлення — «не отримати запит» це мета, але не гарантія.

6) GRUB чи systemd-boot: що менше ламається?

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

7) Чи можу я встановити Linux, не чіпаючи Windows bootloader?

Можна зберегти Windows Boot Manager як основний і завантажувати Linux через меню прошивки, або додати Linux як запис у прошивці, не роблячи його «первинним».
Це часто найменш політичний варіант на керованих корпоративних пристроях.

8) Якого розміру має бути Linux розділ?

Для робочої станції розробника не скупіться: 50–100 GiB мінімум для root, якщо ви будуєте контейнери, SDK або ядра.
Якщо використовуєте btrfs snapshots або тримаєте багато ядер — плануйте більше.

9) Яка файлові система для Linux: ext4 чи btrfs?

ext4 — «найменше дивує». btrfs дає снапшоти і простий відкат, що дійсно корисно, коли оновлення йдуть не так.
Якщо обираєте btrfs — вивчіть workflow зі снапшотами/відкатами до того, як пригоди трапляться о 2:00 ночі.

10) Якщо я клоную диск на більший SSD, чи залишиться dual boot працювати?

Іноді. Клонування може змінити ідентифікатори диска, UUID розділів або заплутати записи прошивки.
Плануйте перевірити efibootmgr -v, blkid і відповідність вмісту ESP після клонування.

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

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

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

• Підтвердьте, що ви на UEFI/GPT і знайдіть свій ESP.
• Зробіть резервну копію ESP поза пристроєм.
• Вирішіть, який завантажувач буде основним, і встановіть BootOrder відповідно.
• Вимкніть Fast Startup, якщо ділитеся даними через NTFS.
• Запишіть вивід efibootmgr -v і тримайте під рукою live USB.

Якщо ви зробите ці п’ять речей, більшість інцидентів «оновлення Windows зламало dual boot» перетворяться на п’ятихвилинний ремонт замість вихідних витрат часу.
А ваше майбутнє «я» зможе залишатися сварливим через більш цікаві проблеми.