Посібник з інсталяції Ubuntu 24.04 LTS: Dual‑Boot, Secure Boot та нульова втрата даних

February 18, 2026 • February 18, 2026 • Читання: 9 хв • Views: 0

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

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

Цей посібник — доросла версія: ви проскануєте машину, зменшите ризики, встановите Ubuntu 24.04 LTS поряд із Windows з увімкненим Secure Boot та збережете дані там, де ви їх лишили. Мета — нудна, але гарантована успішна інсталяція.

Основні правила для нульової втрати даних

«Нульова втрата даних» — це не відчуття. Це послідовність перевірених станів:

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

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

Визначте цільову архітектуру перед початком

Більшість сучасних машин повинні працювати в режимі: UEFI firmware + GPT partition table + Secure Boot увімкнений. Якщо ваша система — legacy BIOS/MBR, ви теж можете робити dual-boot, але випадки помилок множаться. Посібник припускає UEFI/GPT, бо саме це слід використовувати у 2026, якщо ви не оживляєте музейний експонат.

Дві речі, яких робити не слід

Не робіть «wipe and reinstall», коли інсталятор пропонує це «дружньо». Він виконує свою роботу. Ваша робота — відмовитися.
Не зменшуйте розділи з Linux першою, якщо залучено Windows. Зменшуйте Windows із середовища Windows. Нехай кожна ОС керує власними метаданими файлової системи.

Короткий жарт #1: Розділяти диск без перевіреного бекапу — як робити операцію, бо ви колись дивилися медичну драму: сміливо, коротко і дивовижно дорого.

Цікаві факти та історичний контекст (бо цей безлад має історію)

UEFI замінив BIOS як основну модель прошивки в 2010‑х, принісши стандартизовані записи завантаження та реальну файлову систему (FAT) для завантажувачів в EFI System Partition (ESP).
GPT став стандартом, бо MBR обмежує корисний простір і має крихкі межі таблиці розділів; GPT зберігає резервні заголовки і підтримує багато розділів без проблем.
Secure Boot з’явився, щоб зменшити ризик bootkit‑поганців. Він перевіряє підписи в ланцюжку завантаження — чудово, поки вам не потрібні драйвери третіх сторін і ви забуваєте, що таке «підписування».
Ubuntu прийняв shim як практичний міст: shim підписаний Microsoft дозволяє завантажуватися на системах із Secure Boot, а далі перевіряє GRUB і ядра ключами Ubuntu.
GRUB2 замінив старий GRUB з більшою функціональністю й більшою кількістю способів вас заплутати. Він гнучкий, але не екстрасенс.
Windows Fast Startup (гібридний режим гібернації) регулярно створював проблеми в dual‑boot, бо залишає файлові системи «не зовсім закритими», і Linux правильно трактує це як небезпечно.
BitLocker став масовим на споживчих пристроях, особливо на ноутбуках з «Modern Standby», і він змінює підхід до зміни розділів і завантаження.
NVMe ускладнив імена: диски з’являються як /dev/nvme0n1 з розділами /dev/nvme0n1p3, що легко неправильно прочитати під час напруженої інсталяції.
Ubuntu LTS‑релізи призначені для тривалого життя; 24.04 LTS — реліз «сидіти на ньому роками», тому правильність інсталяції важливіша за новизну.

Операційно тема проста: ланцюжок завантаження та схема диска — це спільна інфраструктура. Ставтесь до них як до продакшена, а не як до вихідного проекту на вихідних.

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

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

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

Запустіть live USB Ubuntu («Try Ubuntu»). Потім:

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

Що це означає: «UEFI mode» — це те, що вам потрібно для сучасного dual‑boot. Якщо бачите «Legacy BIOS mode», зупиніться і перезавантажте USB, вибравши UEFI‑запис у меню прошивки.

Рішення: Продовжуйте тільки в UEFI режимі, якщо ви навмисно не підтримуєте legacy BIOS.

Завдання 2: Ідентифікуйте всі диски та їх розміри (щоб не знищити чужий диск)

cr0x@server:~$ lsblk -e7 -o NAME,PATH,SIZE,TYPE,MODEL,SERIAL
NAME        PATH             SIZE TYPE MODEL                 SERIAL
nvme0n1     /dev/nvme0n1   953.9G disk Samsung SSD 990 PRO   S6Z2...
nvme0n1p1   /dev/nvme0n1p1   100M part
nvme0n1p2   /dev/nvme0n1p2    16M part
nvme0n1p3   /dev/nvme0n1p3   450G part
nvme0n1p4   /dev/nvme0n1p4   900M part
nvme0n1p5   /dev/nvme0n1p5   503G part

Що це означає: Ви шукаєте внутрішній диск (часто NVMe) і наявні розділи. У багатьох Windows‑встановленнях ви побачите ESP (~100–300MB), MSR (16MB), розділ Windows (великий) і розділ відновлення.

Рішення: Запишіть шлях до диска (наприклад: /dev/nvme0n1). Якщо є більше одного внутрішнього диска, вирішіть, який з них буде містити Ubuntu.

Завдання 3: Підтвердити тип таблиці розділів (GPT vs MBR)

cr0x@server:~$ sudo parted -l
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  106MB   105MB   fat32        EFI system partition          boot, esp
 2      106MB   123MB   16.8MB               Microsoft reserved partition  msftres
 3      123MB   483GB   483GB   ntfs         Basic data partition          msftdata
 4      483GB   484GB   944MB   ntfs         Basic data partition          hidden, diag
 5      484GB   1024GB  540GB

Що це означає: «Partition Table: gpt» підтверджує, що ви в сучасній епосі. Якщо бачите «msdos», ви на MBR/legacy, і план змінюється.

Рішення: Для dual‑boot із Secure Boot GPT — найпростіший шлях. Якщо з’явився MBR, подумайте про конвертацію (для просунутих) або прийміть складнощі legacy.

Завдання 4: Підтвердити існування EFI System Partition (ESP) і що вона FAT32

cr0x@server:~$ sudo blkid /dev/nvme0n1p1
/dev/nvme0n1p1: UUID="3A1B-2C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="..."

Що це означає: TYPE=vfat і «EFI system partition» — це ваша ESP. Ubuntu її використає; її не слід форматувати під час інсталяції.

Рішення: Залиште ESP. Не створюйте другу ESP, якщо у вас немає конкретної причини (сегрегація по дисках або дуже дивна прошивка від виробника).

Завдання 5: Перевірити, чи Windows у гібернації / ризик Fast Startup (з Linux)

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
FAILED
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

Що це означає: Прапорець -n — це сухий запуск. Якщо він каже unsafe/hibernated, не монтуйте розділ Windows у режимі запису з Linux і не змінюйте його розміри інструментами Linux.

Рішення: Завантажтеся в Windows, вимкніть Fast Startup і зробіть повне завершення роботи.

Завдання 6: Перевірити стан Secure Boot у live середовищі

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

Що це означає: Secure Boot увімкнено. Добре. Ми триматимемо його увімкненим і працюватимемо з цим.

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

Резервні копії, які мають значення (і як їх підтвердити)

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

Файлова резервна копія ваших персональних даних (Documents, проекти, ключі, фото тощо).
Ключі відновлення для Windows BitLocker, якщо він увімкнений.
Засоби відновлення завантаження (Windows recovery USB та ваш Ubuntu installer USB).

Чекліст для Windows (робити в Windows)

З практичної точки зору: найкращий Windows бекап — це той, який ви вже тестували. Якщо ви цього не робили, зробіть швидку відновлювальну перевірку хоча б одного файлу. Також збережіть BitLocker recovery key в місці, не на тому самому пристрої.

Завдання 7: Переконайтеся, що зовнішній диск з резервною копією доступний (з Ubuntu live)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME      SIZE TYPE FSTYPE MOUNTPOINT
nvme0n1 953.9G disk
nvme0n1p1 100M part vfat
nvme0n1p3 450G part ntfs
sda     931.5G disk exfat
sda1    931.5G part exfat  /media/ubuntu/BackupDrive

Що це означає: Ваш зовнішній диск присутній (sda1) і змонтований. Чудово. Якщо він не змонтований, змонтуйте через файловий менеджер або udisksctl mount.

Рішення: Не продовжуйте, поки ціль для бекапу не буде доступна.

Завдання 8: Створіть швидку перевірку цілісності найважливіших файлів

cr0x@server:~$ cd /media/ubuntu/BackupDrive
cr0x@server:~$ sha256sum my-keys.tar my-photos.zip > SHA256SUMS.txt
cr0x@server:~$ cat SHA256SUMS.txt
b1f2...  my-keys.tar
9a8c...  my-photos.zip

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

Рішення: Зберігайте файл контролю цілісності разом з бекапом.

Завдання 9: Зробіть знімок поточної таблиці розділів (дешево, корисно як доказ)

cr0x@server:~$ sudo sgdisk --backup=/media/ubuntu/BackupDrive/nvme0n1-gpt.bin /dev/nvme0n1
cr0x@server:~$ ls -lh /media/ubuntu/BackupDrive/nvme0n1-gpt.bin
-rw-r--r-- 1 root root 17K Feb  5 12:18 /media/ubuntu/BackupDrive/nvme0n1-gpt.bin

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

Рішення: Зберігайте це поза машиною. Воно маленьке й безцінне.

Стратегія розділення для UEFI/GPT dual-boot

Ось основне правило: Windows володіє своїми розділами; Ubuntu отримує нові, вирізані з вільного простору. Ваше завдання — безпечно створити цей вільний простір, а потім чітко його призначити.

Про шифрування: оберіть радіус ураження

Ubuntu пропонує повне шифрування диска (LUKS). Це хороший дефолт, якщо ваша модель загроз включає «втрачені ноутбуки» або «зацікавлену особу з викруткою». Воно також змінює процедури відновлення і може ускладнити деякі сценарії ремонту dual‑boot, якщо ви не розумієте, що всередині зашифрованого контейнера.

Якщо ви хочете «нуль несподіванок», оберіть:

Залиште Windows як є (BitLocker залишається увімкненим, якщо він вже є).
Зашифруйте Ubuntu, якщо ви готові вводити пароль на старті і знайомі з процедурами відновлення.

Завдання 10: Виміряйте реальний вільний простір і поточне використання

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  3.1G  2.1M  3.1G   1% /run
/dev/sr0       iso9660 3.7G 3.7G     0 100% /cdrom
/dev/loop0     squashfs 2.4G 2.4G     0 100% /rofs

Що це означає: У live‑середовищі df не показує використання внутрішнього диска, якщо ви його не змонтували. Це нагадування: не гадати. Якщо потрібна інформація по Windows, перевіряйте Disk Management у Windows.

Рішення: Зменшуйте Windows з середовища Windows. Використовуйте Linux‑інструменти головним чином для ідентифікації та валідації.

Скільки місця виділити?

Мій точковий базовий варіант: 60GB для кореня Ubuntu, якщо ви займаєтесь розробкою, контейнерами або тримаєте кілька ядер. Якщо ви легкий користувач — 40GB вистачить. Якщо ви серйозно працюєте з контейнерами, 100–200GB не надто багато; образи контейнерів множаться як зайці навесні.

Короткий жарт #2: Місце на диску — єдиний ресурс, який стає меншим в ту саму мить, як тільки ви перестаєте дивитися.

Secure Boot: тримайте його ввімкненим, розумійте, що змінюється

Secure Boot не є вашим ворогом. Він просто суворий. Стандартний ланцюжок завантаження Ubuntu при увімкненому Secure Boot виглядає приблизно так:

Прошивка перевіряє shim (підписаний).
shim перевіряє GRUB (підписаний).
GRUB завантажує ядро (підписане).
Ядро застосовує правила підписування модулів залежно від політики та конфігурації.

Коли вас попросять про MOK (Machine Owner Key)

Якщо ви встановлюєте драйвери третіх сторін (часто з NVIDIA), Ubuntu може запропонувати зареєструвати ключ через MOK. Це нормально. Ви встановите одноразовий пароль під час інсталяції, а при наступному перезавантаженні побачите синю MOK‑менеджер екран для реєстрації ключа.

Завдання 11: Перевірити доступність інструментів перевірки Secure Boot і їх стан

cr0x@server:~$ sbverify --version
sbverify version 0.9.4
cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: ...

Що це означає: Ви можете переглядати зареєстровані ключі та перевіряти EFI‑бінарні файли за потреби. Зазвичай це не потрібно, але коли щось трапиться о 2‑й ночі, ви будете вдячні за ці інструменти.

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

Коротка парафразована ідея варта запам’ятовування

Парафразована ідея (приписується Gene Kranz): «Будьте жорсткими й компетентними.» В операційній термінології: зберігайте спокій, перевіряйте і не імпровізуйте на критичних шляхах.

Інсталяція: безпечний шлях через інсталятор Ubuntu

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

Крок 1: Зменшіть Windows (робіть це перед інсталяцією Ubuntu)

У Windows:

Вимкніть Fast Startup.
Якщо BitLocker увімкнений, переконайтеся, що ключ відновлення збережено поза машиною. Розгляньте тимчасове призупинення BitLocker перед зміною розмірів, залежно від політики середовища.
Використайте Disk Management, щоб зменшити розділ Windows і залишити незайнятий простір.
Перезавантажте Windows один раз, потім зробіть повне завершення роботи (не «Restart»).

Так, це дратує. Але це правильний шлях.

Крок 2: Завантажте Ubuntu live USB у UEFI режимі

Ви вже перевіряли UEFI режим раніше. Зробіть це ще раз, якщо сумніваєтеся. Люди помиляються; меню прошивки — ще гірше.

Завдання 12: Підтвердити, що існує незайнятий простір (з Ubuntu live)

cr0x@server:~$ sudo parted /dev/nvme0n1 unit GiB print free
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 953GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number  Start  End    Size   File system  Name  Flags
        0.00GiB 0.00GiB 0.00GiB Free Space
 1      0.00GiB 0.10GiB 0.10GiB fat32            boot, esp
 2      0.10GiB 0.12GiB 0.02GiB                  msftres
 3      0.12GiB 450.00GiB 449.88GiB ntfs
 4      450.00GiB 451.00GiB 1.00GiB  ntfs        hidden, diag
        451.00GiB 953.00GiB 502.00GiB Free Space

Що це означає: Блок «Free Space» в кінці — це місце для Ubuntu. Якщо ви не бачите вільного простору, ви не зменшили Windows або дивитесь на неправильний диск.

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

Крок 3: Виберіть «Manual partitioning» (або еквівалент) в інсталяторі

Якщо інсталятор пропонує «Install alongside Windows», це може спрацювати. Але він також може помилитися, особливо на системах з кількома дисками, розділами від виробника, RAID‑режимами або BitLocker. Якщо ви хочете «нульову втрату даних», візьміть ручний контроль.

Ручне розділення: що створити

Не форматувати ESP. Задайте для неї точку монтування /boot/efi.
Створіть ext4 розділ у вільному просторі для /.
Опціонально: створіть ext4 розділ для /home.
Swap: використовуйте swapfile (за замовчуванням), якщо не плануєте гібернацію.

Завдання 13: Подвійна перевірка, що ви не форматуюєте неправильний розділ (перевірка розуму)

cr0x@server:~$ sudo lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32       3A1B-2C4D
├─nvme0n1p2
├─nvme0n1p3 ntfs               1C2D3E4F5A6B7C8D
├─nvme0n1p4 ntfs               9E8D7C6B5A4F3E2D
└─nvme0n1p5

Що це означає: Ви бачите, які розділи вже мають файлові системи. Вільний простір ще не буде показаний як розділ. Якщо ви бачите ext4 розділ, якого не чекали — зупиніться і розберіться.

Рішення: Форматуйте тільки ті нові розділи, які ви створили для Ubuntu. Ніколи не форматувати NTFS‑розділ, який вам потрібний. Ніколи не форматувати ESP.

Ціль встановлення завантажувача

На UEFI системах «ціль завантажувача» має бути диск, що містить ESP (зазвичай той самий диск, що й Windows). Якщо ви ставите Ubuntu на другий диск, робіть це свідомо: деякі прошивки завжди завантажують з першого диска.

Встановлення оновлень та драйверів третіх сторін (обережно)

Якщо у вас NVIDIA, інсталятор може запропонувати драйвери третіх сторін. Їх брати можна, але очікуйте MOK‑реєстрацію при увімкненому Secure Boot.

Після інсталяції: перевірка шляхів завантаження, драйверів, оновлень

Ви не «закінчили», коли з’явився робочий стіл. Ви закінчили, коли:

Ubuntu надійно завантажується з Secure Boot увімкненим.
Windows все ще завантажується.
Ви можете коротко пояснити, як система завантажується.

Завдання 14: Підтвердити стан Secure Boot в інстальованому Ubuntu

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

Що це означає: Ви пройшли весь шлях у Secure Boot режимі.

Рішення: Якщо Secure Boot несподівано вимкнено — перевірте налаштування прошивки. Не думайте, що Ubuntu «вимкнув» його. Перемикання прошивки може скидати налаштування після оновлень або подій CMOS.

Завдання 15: Підтвердити EFI записи завантаження (Ubuntu та Windows)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Що це означає: Прошивка знає про обидва завантажувачі. Ubuntu використовує shim (shimx64.efi), що очікувано при Secure Boot.

Рішення: Якщо запис «Windows Boot Manager» відсутній — не панікуйте. Його можна відновити, але спочатку перевірте вміст ESP.

Завдання 16: Оглянути вміст ESP (підтвердити, що нічого не перезаписано)

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo ls -R /mnt/esp/EFI | head -n 50
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Microsoft:
Boot

/mnt/esp/EFI/ubuntu:
grubx64.efi
mmx64.efi
shimx64.efi

Що це означає: ESP містить директорії обох вендорів. Так має виглядати «поряд з Windows».

Рішення: Якщо директорія Microsoft відсутня — ви, ймовірно, форматували ESP або писали на неправильний диск. Відновлення можливе, але тепер це інцидент‑response.

Завдання 17: Підтвердити, що GRUB бачить Windows (і виправити, якщо потрібно)

cr0x@server:~$ sudo grep -R "menuentry 'Windows" -n /boot/grub/grub.cfg | head
1234:menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1C2D3E4F5A6B7C8D' {

Що це означає: Windows присутній у конфігурації GRUB. Якщо його там немає, можливо, os-prober відключено або Windows приховано через стан гібернації.

Рішення: Якщо Windows не виявляється — спочатку переконайтеся, що Windows повністю вимкнений і не в гібернації; потім виконайте update-grub.

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

Що це означає: GRUB може chainload‑ити Windows. Це найпростіша схема dual‑boot.

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

Завдання 18: Перевірити стан ядра і драйверів (особливо на ноутбуках)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ ubuntu-drivers devices | sed -n '1,120p'
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd000025A2sv00001028sd00000B42bc03sc00i00
vendor   : NVIDIA Corporation
model    : AD104M [GeForce RTX ...]
driver   : nvidia-driver-550 - distro non-free recommended
driver   : xserver-xorg-video-nouveau - distro free builtin

Що це означає: Ви бачите рекомендовані драйвери. На системах з Secure Boot встановлення пропрієтарних драйверів може викликати MOK‑реєстрацію.

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

Завдання 19: Перевірити RAID/RST режим, який може приховувати диски від Linux

cr0x@server:~$ sudo lspci -nn | grep -i -E "sata|raid|nvme"
00:17.0 SATA controller [0106]: Intel Corporation Device [8086:7ae2]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

Що це означає: Це не дає визначеності щодо режиму прошивки, але допомагає помітити системи, де може бути Intel RST/RAID. Якщо Linux не бачить ваш Windows‑диск, режим зберігання у прошивці — головний підозрюваний.

Рішення: Якщо внутрішній диск зникає під Linux, перевірте прошивку на RST/RAID vs AHCI і дійте обережно (особливо якщо Windows встановлено).

Завдання 20: Перевірити точки монтування і fstab (щоб уникнути майбутніх сюрпризів при завантаженні)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS / /boot/efi
/dev/nvme0n1p6 / ext4 rw,relatime,errors=remount-ro
/dev/nvme0n1p1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
cr0x@server:~$ sudo cat /etc/fstab
UUID=... / ext4 errors=remount-ro 0 1
UUID=3A1B-2C4D /boot/efi vfat umask=0077 0 1

Що це означає: Ubuntu монтує ESP за UUID. Це добре. Імена пристроїв можуть змінюватися; UUID‑и — стабільні.

Рішення: Якщо /boot/efi не змонтовано, оновлення GRUB можуть записуватися не туди і майбутні оновлення ядра можуть творити «цікавинки». Виправте це зараз.

Три бізнес-історії (щоб ви їх не повторили)

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

Середня компанія розгорнула ноутбуки з Ubuntu у режимі dual‑boot для розробників: Windows для корпоративних додатків, Ubuntu для інструментів збірки. Команда іміджів припустила, що «диск завжди /dev/nvme0n1», бо так було на перших моделях. Потім закупівля зробила своє і прислала партію з двома внутрішніми дисками: невеликий NVMe для ОС і більший SATA SSD для даних.

Автоматизаційний скрипт розбив перший диск, який він побачив, встановив Ubuntu і оновив EFI‑записи. На моделях з двома дисками «перший диск» виявився неоднорідним. Деякі машини отримали GRUB на одному диску, ESP на іншому, а запис Windows Boot Manager вказував у нікуди.

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

Виправлення було нудне й трохи принизливе: припинити покладатися на порядки дисків, ідентифікувати диски за моделлю/серійником та цілеспрямовано писати саме на диск із ESP. Також додали preflight‑крок: дампити lsblk і efibootmgr у логи перед змінами. Наступний реліз мав близько нульового рівня відмов, що є прийнятним числом для «ми торкалися завантаження».

Урок: Імена дисків не є ідентичностями. Ставтесь до них як до тимчасових інтерфейсів і використовуйте стабільні ідентифікатори.

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

Інша організація намагалася «оптимізувати» час інсталяції, відключаючи Secure Boot в прошивці під час провізії. Ідея була уникнути MOK‑підказок, пришвидшити встановлення драйверів і потім знову увімкнути Secure Boot наприкінці. У лабораторії це працювало. У продакшені це принесло тиху катастрофу.

На деяких версіях прошивки перемикання Secure Boot скидало частини порядку завантаження або викликало «fallback» поведінку. Деякі пристрої повторно вмикали Secure Boot, але відмовлялися завантажувати раніше встановлені неподписані або інакше підписані компоненти без повторної реєстрації. Інші змінювали порядок завантаження так, що Windows знову став домінувати, і служба підтримки отримала тікети типу «Ubuntu зник».

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

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

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

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

Фінансова фірма мала політику: перед будь‑яким розгортанням ОС техніки повинні захопити (1) резерв GPT, (2) фото меню прошивки з показаним режимом завантаження, і (3) копію списку EFI директорій з ESP після інсталяції. Усі скаржилися, що це бюрократія. Усі помилялися.

Одного дня ноутбук повернувся з ремонту вендора з заміненою материнською платою. Диск залишився, але NVRAM записи завантаження зникли — ні «ubuntu», ні «Windows Boot Manager». Машина завантажувалася в прошивку і дивилася на користувача, ніби ніколи не бачила ОС.

Технік витягнув з тікету збережений список ESP, підтвердив, що \EFI\Microsoft\Boot\bootmgfw.efi і \EFI\ubuntu\shimx64.efi мали існувати, потім змонтував ESP з live USB і перевірив директорії. Добре — дані не зникли; зникли покажчики.

Вони відтворили записи завантаження з efibootmgr і використали опцію прошивки «UEFI file» як запасний варіант. Ніякого перепартування. Жодної перевстановки. Нуль втрат даних. Тікет швидко закрили — це найкраща похвала в операціях.

Урок: Фіксуйте стан до і після змін. Коли прошивка забуває, вам не потрібні героїчні вчинки — вам потрібні докази.

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

Коли dual‑boot ламається, люди метушаться: перевстановлюють GRUB, перемикають BIOS, лають місяць. Не робіть так. Робіть це в порядку, щоб швидко знайти вузьке місце.

1) Чи це проблема режиму завантаження (UEFI vs legacy)?

З live USB: перевірте /sys/firmware/efi.
Якщо інстальована ОС була в UEFI, а ви завантажили recovery USB в legacy режимі, ви будете мучитися.

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

Рішення: Узгодьте режим завантаження інструментів із інстальованою системою.

2) Чи вказує прошивка на правильний EFI бінарник?

Використайте efibootmgr -v в Ubuntu.
Якщо Ubuntu не завантажується, використайте меню прошивки, щоб вибрати Windows Boot Manager або UEFI файл.

cr0x@server:~$ sudo efibootmgr -v | sed -n '1,20p'
BootCurrent: 0003
BootOrder: 0003,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Рішення: Якщо записи відсутні — відтворіть їх. Якщо записи є, але не працюють — огляньте ESP і підписи.

3) Чи ESP ціла і змонтована?

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

cr0x@server:~$ sudo mount | grep -E "/boot/efi|/mnt/esp" || echo "ESP not mounted"
ESP not mounted

Рішення: Змонтуйте її, перевірте директорії, потім відновіть записи завантаження.

4) Чи Windows «dirty» (в гібернації) і блокує виявлення?

Windows Fast Startup може змусити Linux відмовитися монтувати NTFS, і також може перешкоджати виявленню os-prober. Якщо Windows «dirty», виправте це спочатку.

5) Чи Secure Boot блокує драйвер/модуль?

Коли після інсталяції не працює графіка або Wi‑Fi, Secure Boot може запроваджувати правила підпису модулів. Це не причина вимикати Secure Boot; це привід встановити підписані драйвери або коректно зареєструвати MOK.

cr0x@server:~$ dmesg | grep -i -E "secure boot|lockdown|module verification" | tail -n 20
[    0.000000] secureboot: Secure boot enabled
[   12.345678] Lockdown: Loading of unsigned module is restricted; see man kernel_lockdown.7

Рішення: Якщо вам потрібен цей модуль — встановіть його через пакети Ubuntu, що підтримують Secure Boot, і зареєструйте MOK при підказці.

6) Лише потім: ремонт GRUB

GRUB часто звинувачують, і іноді він винен. Але спочатку виправте питання режиму завантаження/ESP/NVRAM. Інакше ви просто перевстановите GRUB у той самий зламаний контекст.

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

1) Симптом: розділ Windows монтується лише для читання або не монтується

Корінна причина: Windows була в гібернації або Fast Startup залишив NTFS «dirty».

Вирішення: Завантажтеся в Windows, вимкніть Fast Startup, зробіть повне завершення роботи. Потім повторіть виявлення.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

2) Симптом: інсталятор не показує опцію «Install alongside Windows»

Корінна причина: Windows використовує BitLocker і/або увімкнений Fast Startup, або нестандартна схема дисків (dynamic disks, RAID режим).

Вирішення: Використовуйте ручне розділення; переконайтеся, що є вільний простір; підтвердьте UEFI режим; уникайте dynamic disk.

3) Симптом: після інсталяції машина завантажується прямо в Windows

Корінна причина: Порядок завантаження прошивки все ще віддає перевагу Windows Boot Manager, або запис ubuntu не створено.

Вирішення: Встановіть порядок завантаження у прошивці або з Ubuntu:

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0000
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu
cr0x@server:~$ sudo efibootmgr -o 0003,0000

Рішення: Якщо прошивка постійно повертає зміни, перевірте політики вендора або оновлення прошивки.

4) Симптом: після інсталяції машина завантажується в прошивку з повідомленням «No bootable device»

Корінна причина: Записи завантаження відсутні (NVRAM скинутий), ESP не знайдено або ESP пошкоджено.

Вирішення: З live USB змонтуйте ESP і перевірте наявність EFI‑бінарників. Відтворіть записи з efibootmgr. Якщо бінарники відсутні, можливо, доведеться перевстановити GRUB/shim в ESP.

5) Симптом: Ubuntu завантажується, але немає Wi‑Fi

Корінна причина: Відсутній пакет прошивки, або Secure Boot заблокував out‑of‑tree модуль, або пристрій не підтримується.

Вирішення: Визначте пристрій, встановіть потрібну прошивку, перевірте dmesg.

cr0x@server:~$ lspci -nn | grep -i network
02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) [8086:2725]
cr0x@server:~$ dmesg | grep -i firmware | tail -n 20
[    8.123456] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-*.ucode failed with error -2

Рішення: Встановіть відсутній пакет прошивки через apt (потребує мережі; використайте Ethernet або USB tethering, якщо потрібно).

6) Симптом: чорний екран після встановлення драйвера NVIDIA з Secure Boot увімкненим

Корінна причина: MOK‑реєстрація не завершена, або модуль не пройшов перевірку підпису.

Вирішення: Перезавантажтеся і зареєструйте MOK при підказці. Якщо пропустили — перевстановіть пакет драйвера і повторіть MOK‑потік, або тимчасово завантажтеся з відкритим драйвером, щоб відновити систему.

7) Симптом: меню GRUB не показує Windows

Корінна причина: os-prober не запускається, Windows у гібернації або файли завантаження Windows не на очікуваному ESP.

Вирішення: Переконайтеся, що Windows повністю вимкнений, потім виконайте update-grub. Перевірте, що ESP містить директорію Microsoft.

8) Симптом: BitLocker просить ключ відновлення після встановлення Ubuntu

Корінна причина: Конфігурація завантаження змінилася (очікувано), і BitLocker вимагає перевірки.

Вирішення: Введіть ключ відновлення, потім у Windows розгляньте «suspend and resume BitLocker», щоб він знову запечатав стан завантаження. Не вимикайте BitLocker назавжди, якщо політика не дозволяє і ви не розумієте ризик.

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

План A: Стандартний single‑disk Windows + Ubuntu dual‑boot (рекомендовано)

У Windows: Зробіть бекап критичних файлів на зовнішній диск. Збережіть BitLocker recovery key поза пристроєм.
У Windows: Вимкніть Fast Startup. Повне завершення роботи.
У Windows: Зменшіть розділ Windows, залишивши незайнятий простір.
Завантажте Ubuntu USB (UEFI): Перевірте UEFI режим (/sys/firmware/efi існує).
З live Ubuntu: Збережіть вивід lsblk і parted -l (скриншоти або збережений текст).
З live Ubuntu: Зробіть бекап GPT (sgdisk --backup) на зовнішній диск.
Інсталятор: Використовуйте ручне розділення. Оберіть ESP, змонтуйте в /boot/efi, не форматуючи.
Інсталятор: Створіть ext4 для / у вільному просторі. Опціонально /home.
Інсталятор: Тримайте Secure Boot увімкненим. Якщо запитують, задайте MOK‑пароль (запишіть тимчасово).
Перший перезавантаження: Завершіть MOK‑реєстрацію, якщо просить.
В Ubuntu: Виконайте efibootmgr -v, підтвердіть записи для Windows і ubuntu.
В Ubuntu: Виконайте update-grub і підтвердіть виявлення Windows.
Тест завантаження: Завантажте Windows з GRUB і з меню прошивки. Переконайтеся, що BitLocker працює як очікується.

План B: Ubuntu на другому диску, Windows на першому (працює, але треба бути уважним)

Підтвердіть, який диск містить ESP. Зазвичай диск Windows.
Вирішіть, чи розміщувати EFI файли Ubuntu на існуючому ESP, чи створити другу ESP на диску Ubuntu. Віддавайте перевагу одній ESP, якщо немає причин інакше.
Встановлюйте Ubuntu з ручним розділенням, явно вибираючи правильний диск/ESP.
Перевірте порядок завантаження прошивки і переконайтеся, що обидва записи залишаються після перезавантажень і оновлень.

План C: Якщо щось пішло не так, не «пробуйте» сліпо

Завантажте live Ubuntu USB в UEFI режимі.
Ідентифікуйте диски (lsblk), знайдіть ESP (blkid), змонтуйте її, перелікуйте /EFI.
Перевірте NVRAM записи (efibootmgr -v).
Лише потім ремонтуйте: відтворюйте записи або перевстановлюйте GRUB в ESP.

Завдання 21: Відтворити відсутній запис Windows Boot Manager (якщо файл існує)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0003
BootOrder: 0004,0003,0000
Boot0004* Windows Boot Manager

Що це означає: Ви створили новий NVRAM запис, що вказує на Microsoft EFI бінарник на розділі 1 (ESP).

Рішення: Якщо не вдається, перевірте номер розділу ESP і шлях; зворотні слеші важливі в EFI‑шляхах.

Завдання 22: Відтворити відсутній запис Ubuntu (шлях shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi'
Boot0005* ubuntu

Що це означає: Ви відтворили запис Ubuntu для Secure Boot.

Рішення: Поставте його першим у порядку завантаження, якщо бажаєте.

Завдання 23: Встановити порядок завантаження явно (бо «доброта» прошивки — проблема)

cr0x@server:~$ sudo efibootmgr -o 0005,0004
BootOrder: 0005,0004

Що це означає: Прошивка спробує Ubuntu першою, потім Windows.

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

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

1) Чи варто вимикати Secure Boot для Ubuntu 24.04?

Ні, за замовчуванням не варто. Ubuntu добре підтримує Secure Boot. Вимикайте його лише якщо у вас є конкретна перешкода, яку ви розумієте (зазвичай вузький випадок з модулем ядра).

2) Чи перезапише Ubuntu Windows?

Тільки якщо ви дасте на це наказ. Небезпечна опція — «Erase disk and install Ubuntu». Використовуйте ручне розділення і ніколи не форматувати Windows‑розділи або ESP.

3) Чи потрібний окремий /home розділ?

Не обов’язково. Це корисно, якщо ви часто перевстановлюєте Ubuntu і хочете ізолювати користувацькі дані. Якщо ви не дисципліновані щодо бекапів, окремий /home не врятує вас від власної недбалості.

4) Чи потрібен swap розділ?

Ні. Ubuntu може використовувати swapfile. Якщо ви плануєте гібернацію Linux, сплануйте обсяг swap і протестуйте гібернацію. Інакше swapfile простіший і загалом підходить.

5) Чому BitLocker просить ключ після встановлення Ubuntu?

Тому що конфігурація завантаження змінилася і BitLocker виконує свою роботу: він виявив нове середовище завантаження. Введіть recovery key, потім у Windows розгляньте «suspend and resume BitLocker», щоб він заново підписав стан завантаження. Не губіть цей ключ.

6) Інсталятор не бачить внутрішнього диска. Що робити?

Звична причина на деяких ноутбуках: режим зберігання в прошивці встановлено на Intel RST/RAID. Linux може не бачити диск інакше. Переключення на AHCI може допомогти, але робіть це обережно, щоб не зламати завантаження Windows. Якщо ви не знаєте процедуру — зупиніться і сплануйте зміну.

7) GRUB не показує Windows, але Windows завантажується через меню прошивки. Це погано?

Не катастрофа. Це означає, що GRUB не виявив Windows або не налаштований показувати її. Виправте гібернацію/Fast Startup, потім виконайте update-grub. Можна також користуватися вибором прошивки — але це менш зручно.

8) Чи можна мати спільний розділ для даних між Windows і Ubuntu?

Так, зазвичай через NTFS або exFAT. NTFS добре підходить для спільного сховища, якщо ви гарантуєте повне вимкнення Windows (без Fast Startup/гібернації). Для надійності уникайте зберігання даних, що залежать від Linux‑права доступу, на NTFS.

9) Краще обрати «install alongside Windows» чи ручне розділення?

Якщо ви хочете максимальної гарантії успіху на різних OEM‑макетах — обирайте ручне розділення. Опція alongside може спрацювати, але це автоматизаційний ярлик; ризики ви несете самі.

10) Якщо я зіпсував завантажувач, чи втрачені мої дані?

Зазвичай ні. Проблеми із завантаженням часто пов’язані з NVRAM записами або вмістом ESP. Ваші файли, як правило, залишаються недоторканими. Найбільша небезпека — панічні дії і перепартування. Зупиніться, змонтуйте ESP, огляньте, потім ремонтуйте записи завантаження.

Висновок: наступні кроки після чистого завантаження

Якщо ви можете завантажувати Ubuntu і Windows надійно з увімкненим Secure Boot, ви вже зробили найскладніше: повернули ланцюжок завантаження в нудний, передбачуваний стан. Тримайте його таким.

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

Оновіть Ubuntu і перезавантажте один раз, щоб підтвердити, що оновлення ядра не ламають Secure Boot‑потік.
Перевірте бекапи: перевірте контрольну суму з вашого бекап‑диска і відновіть один файл як тест.
Документуйте вашу схему: збережіть вивід lsblk, parted -l та efibootmgr -v у безпечному місці.
Визначте за замовчуванням ОС: встановіть порядок завантаження у прошивці відповідно, і тримайте іншу ОС доступною через GRUB або меню прошивки.
Тримайте Windows Fast Startup вимкненим, якщо ви регулярно доступаєтеся до розділів Windows з Linux.

Ось і все. Ніякої містики. Просто дисципліновані зміни, перевірені стани і тихе задоволення від системи, яка завантажується однаково двічі.