Відновлення завантажувального пулу ZFS: повернення системи після невдалого оновлення

Практична модель: що насправді означає «завантажувальний пул»

Системи ZFS, що «завантажуються з ZFS», часто мають дві відмінні ролі сховища:
невеликий завантажувальний пул (зазвичай bpool), у якому зберігаються ядро, initramfs та компоненти, дружні до завантажувача; і кореневий пул
(зазвичай rpool), у якому лежить усе інше. Деякі платформи пропускають розділення і завантажуються прямо з кореневого пулу.
Деякі платформи використовують UEFI і зберігають артефакти EFI в FAT ESP, а не в ZFS. Потрібно визначити, в якому ви середовищі.

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

• Завантажувач не знаходить конфіг або не вміє читати ZFS.
• Ядро завантажується, але initramfs не може імпортувати кореневий пул.
• Модулі ZFS не відповідають ядру.
• На одній машині увімкнули функції пулу, а тепер старе середовище не може імпортувати.
• Член зеркала помер, і прошивка/порядок завантаження обирає неправильний диск.

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

Ось ланцюжок простими словами:
firmware → bootloader (GRUB/systemd-boot) → kernel + initramfs → ZFS import → mount root → switch_root → services.
Коли ви розглядаєте це як ланцюжок, перестаєте випадково перевстановлювати GRUB, ніби це свята вода.

Жарт №1: GRUB не злобний; він просто ентузіаст інтерпретаційних повідомлень про помилки.

Швидкий план діагностики (перевірте це насамперед)

По-перше: визначте етап збою

• Зависло до меню GRUB: firmware/ESP/порядок завантаження або відсутній завантажувач.
• Появляється меню GRUB, вибір ядра працює, але потім кидає в оболонку initramfs: проблема з імпортом ZFS або з initramfs/модулями.
• Ядро завантажується, потім panic: часто відсутній кореневий датасет, невірний root= або несумісний модуль ZFS.
• Завантажується в single-user/emergency: пул імпортовано, але точки монтування/датасети/сервіси або ключі шифрування не працюють.

По-друге: нічого не змінюйте, поки не побачите пули

• Завантажте live-середовище, яке має інструменти ZFS, що збігаються (або близькі) з версією на диску.
• Імпортуйте пули спочатку у режимі лише для читання. Якщо імпортується — у вас є варіанти. Якщо ні — треба зрозуміти чому.

По-третє: оберіть стратегію відновлення

• Відкат до відомого робочого boot environment/snapshot, якщо він є. Це найшвидше.
• Виправлення завантажувача, якщо ОС ціла, але запис завантаження пошкоджений.
• Перебудова initramfs, якщо модулі ZFS недоступні на ранньому етапі завантаження.
• Виправлення здоров’я пулу (зношене зеркало, неправильний диск у черзі завантаження), якщо машина завантажується з «неправильного» члена.

По-четверте: збережіть докази

Збережіть останні логи завантаження з поля (якщо доступні) і точні версії ядра + пакетів ZFS.
На системах з кількома boot environments зафіксуйте, який було вибрано. Відновлення простіше, коли можна довести, що змінилося.

Цікаві факти та контекст (бо історія кусає)

1. ZFS створювали з наскрізною цілісністю як першокласною особливістю, тому «тиха корупція» для стеку — питання честі.
2. Розділення «завантажувального пулу» зумовлене обмеженнями завантажувача: історично GRUB мав обмежену підтримку ZFS-функцій, тож спрощення /boot зменшувало проблеми.
3. Флаги функцій були введені, щоб уникнути залежності від номерів версій. Чудова ідея — поки ви не увімкнули функцію й не намагаєтеся імпортувати на старішому rescue-образі.
4. Illumos і BSD довго трактували ZFS як нативний компонент, тоді як Linux часто розглядає його як зовнішній модуль; ця різниця важлива під час initramfs і оновлень ядра.
5. Файл «zpool.cache» став тихою залежністю для багатьох сценаріїв завантаження; якщо він застарілий або відсутній, імпорт може перетворитися на полювання.
6. UEFI змінив режими відмов завантаження: у вас може бути ідеальний пул ZFS, але ви все одно впадете через відсутній запис у EFI System Partition.
7. Boot environments популяризували «оновлюй без страху» в Solaris/illumos; Linux-спільнота знову відкриває для себе переваги через snapshots і клонування датасетів.
8. Проект ZFS on Linux злився в OpenZFS, що зменшило фрагментацію, але не усунуло проблему координації «ядро vs модуль».

Цитата, яка має висіти на кожній стіні on-call:
«Надія — не стратегія.» — генерал Гордон Р. Салліван

Практичні завдання з відновлення (команди, результати, рішення)

Припущення: ви завантажили live-ISO або rescue-середовище з інструментами ZFS (zpool, zfs) та базовими дисковими утилітами.
Замініть імена пулів/датасетів за потреби. Команди нижче призначені для виконання та отримання корисних доказів.

Завдання 1: Ідентифікуйте диски, розділи та що змінилося

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1   1G part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI
├─nvme0n1p2   4G part zfs_member
└─nvme0n1p3 471G part zfs_member
nvme1n1   476.9G disk
├─nvme1n1p1   1G part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI
├─nvme1n1p2   4G part zfs_member
└─nvme1n1p3 471G part zfs_member

Що це означає: ви бачите, чи маєте ESP (vfat) плюс ZFS-члени, і чи є зеркала.
Рішення: якщо ESP є, потрібно враховувати записи UEFI. Якщо ESP відсутній і у вас BIOS, GRUB, ймовірно, живе в області MBR.

Завдання 2: Перевірте, чи видимі пули та чому їх не можна імпортувати

cr0x@server:~$ sudo zpool import
   pool: bpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        bpool        ONLINE
          nvme0n1p2  ONLINE
          nvme1n1p2  ONLINE

   pool: rpool
     id: 9876543210987654321
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool        ONLINE
          mirror-0   ONLINE
            nvme0n1p3  ONLINE
            nvme1n1p3  ONLINE

Що це означає: live-середовище бачить обидва пули; добрий знак. Якщо ви замість цього бачите «cannot import» з повідомленням про feature flags,
ваш rescue-образ OpenZFS, ймовірно, занадто старий.
Рішення: якщо пули відображаються, імпортуйте спочатку лише для читання. Якщо ні — оновіть rescue-середовище або використайте відповідний ISO дистро.

Завдання 3: Імпортуйте пули у режимі лише для читання і без монтування (безпечна перевірка)

cr0x@server:~$ sudo zpool import -N -o readonly=on rpool
cr0x@server:~$ sudo zpool import -N -o readonly=on bpool

Що це означає: пули імпортовано, але датасети не змонтовано; ви зменшуєте ризик випадкових записів.
Рішення: якщо імпорт не вдається з повідомленням «pool is busy», щось автоімпортувало; перевірте zpool status і експортуйте/імпортуйте цілеспрямовано.

Завдання 4: Підтвердіть стан пулу та знайдіть сценарії «завантаження з неправильного диска»

cr0x@server:~$ sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:10:12 with 0 errors on Tue Dec 24 03:10:12 2025
config:

        NAME           STATE     READ WRITE CKSUM
        rpool          ONLINE       0     0     0
          mirror-0     ONLINE       0     0     0
            nvme0n1p3  ONLINE       0     0     0
            nvme1n1p3  ONLINE       0     0     0

errors: No known data errors

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

Завдання 5: Перелічіть датасети і знайдіть критичні для завантаження

cr0x@server:~$ sudo zfs list -o name,mountpoint,canmount,readonly -r rpool | head -n 12
NAME                         MOUNTPOINT  CANMOUNT  READONLY
rpool                        none        off       on
rpool/ROOT                    none        off       on
rpool/ROOT/ubuntu_1           /           noauto    on
rpool/home                    /home       on        on
rpool/var                     /var        on        on
rpool/var/log                 /var/log    on        on

Що це означає: ви бачите кореневий датасет (зазвичай під rpool/ROOT/*) і чи встановлені властивості mount.
Рішення: визначте призначений boot environment датасет. Якщо їх декілька, ви можете відкотитися, обравши інший.

Завдання 6: Визначте активний boot environment (або який має бути активним)

cr0x@server:~$ sudo zpool get -H bootfs rpool
rpool  bootfs  rpool/ROOT/ubuntu_1  local

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

Завдання 7: Змонтуйте систему контрольовано (для ремонту)

cr0x@server:~$ sudo mkdir -p /mnt
cr0x@server:~$ sudo zfs set readonly=off rpool/ROOT/ubuntu_1
cr0x@server:~$ sudo zfs mount rpool/ROOT/ubuntu_1
cr0x@server:~$ sudo mount --rbind /dev /mnt/dev
cr0x@server:~$ sudo mount --rbind /proc /mnt/proc
cr0x@server:~$ sudo mount --rbind /sys /mnt/sys
cr0x@server:~$ mount | head -n 5
rpool/ROOT/ubuntu_1 on / type zfs (rw,relatime,xattr,noacl)
udev on /mnt/dev type devtmpfs (rw,nosuid,relatime,size=16343656k,nr_inodes=4085914,mode=755)
proc on /mnt/proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /mnt/sys type sysfs (rw,nosuid,nodev,noexec,relatime)

Що це означає: ви змонтували root і прив’язали псевдо-файлові системи ядра, щоб chroot ремонти працювали.
Рішення: якщо кореневий датасет змонтовано, але ключові шляхи порожні, ви могли змонтувати невірний датасет (поширено при наявності кількох boot environments).

Завдання 8: Перевірте узгодженість ядра та модуля ZFS (класична помилка після оновлення)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'uname -r; dpkg -l | egrep "zfs|linux-image" | head'
5.15.0-92-generic
ii  linux-image-5.15.0-92-generic   5.15.0-92.102  amd64  Signed kernel image generic
ii  zfsutils-linux                  2.1.5-1ubuntu6 amd64  command-line tools to manage ZFS filesystems
ii  zfs-dkms                        2.1.5-1ubuntu6 amd64  OpenZFS kernel modules for Linux

Що це означає: ви підтверджуєте, яке ядро очікується і чи встановлено DKMS ZFS.
Рішення: якщо ядро оновилось, але модулі ZFS не зібрались (або були видалені), initramfs не зможе імпортувати пул. Перебудуйте модулі/initramfs.

Завдання 9: Перебудуйте initramfs і переконайтесь, що ZFS-hooks на місці

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'update-initramfs -u -k all'
update-initramfs: Generating /boot/initrd.img-5.15.0-92-generic
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_12.bin for module i915

Що це означає: генерація initramfs пройшла; попередження про firmware зазвичай не стосується завантаження ZFS.
Рішення: якщо ви бачите помилки про zfs-hooks або відсутній zpool, відновіть стан пакетів (встановіть zfs-initramfs, де застосовно).

Завдання 10: Перевірте, що командний рядок ядра вказує на правильний кореневий датасет

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grep -R "root=ZFS=" -n /boot/grub/grub.cfg | head -n 3'
/boot/grub/grub.cfg:126:        linux   /ROOT/ubuntu_1/@/boot/vmlinuz-5.15.0-92-generic root=ZFS=rpool/ROOT/ubuntu_1 ro quiet

Що це означає: GRUB налаштовано змонтувати очікуваний ZFS-датасет як root.
Рішення: якщо він вказує на датасет, якого більше не існує (перейменовано, відкотили, клоновано), згенеруйте конфіг GRUB знову і встановіть bootfs відповідно.

Завдання 11: Перегенеруйте конфіг GRUB і перевстановіть завантажувач (BIOS випадок)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-mkconfig -o /boot/grub/grub.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-92-generic
Found initrd image: /boot/initrd.img-5.15.0-92-generic
done
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-install /dev/nvme0n1'
Installing for i386-pc platform.
Installation finished. No error reported.

Що це означає: конфіг включає ядра; GRUB встановлено на диск. На зеркальних системах повторіть для іншого диска.
Рішення: якщо ви насправді UEFI, не робіть BIOS-інсталяцій. Замість цього змонтуйте ESP і використайте шлях для UEFI, описаний нижче.

Завдання 12: Відновіть UEFI артефакти та записи (UEFI випадок)

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck'
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'efibootmgr -v | head -n 5'
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu  HD(1,GPT,2b3c...,0x800,0x32000)/File(\EFI\ubuntu\grubx64.efi)

Що це означає: GRUB встановлено в ESP і запис завантаження існує.
Рішення: на зеркальних системах також змонтуйте і заповніть ESP другого диска. Порядок завантаження прошивки може змінюватися несподівано після збоїв.

Завдання 13: Перевірте вміст /boot на очікуваному пулі/датасеті

cr0x@server:~$ sudo zfs list -o name,mountpoint -r bpool
NAME            MOUNTPOINT
bpool           /boot
bpool/BOOT      /boot
bpool/BOOT/ubuntu_1 /boot
cr0x@server:~$ sudo ls -lh /mnt/boot | head
total 192M
-rw-r--r-- 1 root root  26M Dec 24 03:02 initrd.img-5.15.0-92-generic
-rw------- 1 root root  12M Dec 24 03:02 System.map-5.15.0-92-generic
-rw------- 1 root root 8.3M Dec 24 03:02 vmlinuz-5.15.0-92-generic

Що це означає: підтверджує, чи /boot змонтовано на ZFS і чи є очікуване ядро/initrd.
Рішення: якщо /boot порожній або не змонтований, ви ремонтуєте неправильну файлову систему. Змонтуйте датасети bpool правильно і повторіть build initramfs/GRUB.

Завдання 14: Підтвердіть поведінку імпорту ZFS на ранньому етапі завантаження (cachefile і hostid)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'ls -l /etc/hostid; zpool get -H cachefile rpool'
-rw-r--r-- 1 root root 4 Dec 22 10:10 /etc/hostid
rpool  cachefile  /etc/zfs/zpool.cache  local

Що це означає: hostid існує (допомагає запобігти випадковим імпортам на чужому хості) і cachefile встановлено.
Рішення: якщо cachefile — «-» або вказує в нікуди, встановіть його і відтворіть з відомого доброго імпорту, щоб полегшити життя initramfs.

Завдання 15: Виправте зламаний zpool.cache (поширено після chroot або клонування образу)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'zpool set cachefile=/etc/zfs/zpool.cache rpool; zpool set cachefile=/etc/zfs/zpool.cache bpool; ls -l /etc/zfs/zpool.cache'
-rw-r--r-- 1 root root 2430 Dec 26 18:02 /etc/zfs/zpool.cache

Що це означає: cachefile існує і містить шляхи пристроїв/GUID для імпорту.
Рішення: відтворіть initramfs після зміни, щоб раннє завантаження бачило оновлений кеш.

Завдання 16: Перевірте несумісність флагів функцій (чому rescue ISO не може імпортувати)

cr0x@server:~$ sudo zpool import -o readonly=on rpool
cannot import 'rpool': unsupported feature(s)
  Pool 'rpool' uses the following feature(s) not supported by this system:
    com.delphix:spacemap_histogram
    org.openzfs:project_quota

Що це означає: ZFS у rescue-середовищі занадто старий, щоб зрозуміти увімкнені функції пулу.
Рішення: зупиніться. Не «форсуйте» імпорт. Завантажте новіший rescue-образ або встановіть новий OpenZFS у live-середовище.

Завдання 17: Якщо GRUB переходить у rescue mode, знайдіть /boot і завантажте normal

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd1) (hd1,gpt1) (hd1,gpt2) (hd1,gpt3)
cr0x@server:~$ ls (hd0,gpt2)/
@/ BOOT/ grub/
cr0x@server:~$ set prefix=(hd0,gpt2)/grub
cr0x@server:~$ insmod normal
cr0x@server:~$ normal

Що це означає: ви вручну вказали GRUB правильну файлову систему і завантажили модуль normal, щоб дістатися меню.
Рішення: після завантаження (або chroot) перевстановіть GRUB належним чином; ручний порятунок — одноразовий парашут, а не стиль життя.

Завдання 18: Відкотіть зламане оновлення за допомогою snapshots (якщо вони є)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -r rpool/ROOT/ubuntu_1 | tail -n 3
rpool/ROOT/ubuntu_1@pre-upgrade-2025-12-24  Tue Dec 24 02:55 2025
rpool/ROOT/ubuntu_1@post-upgrade-2025-12-24 Tue Dec 24 03:05 2025
cr0x@server:~$ sudo zfs rollback -r rpool/ROOT/ubuntu_1@pre-upgrade-2025-12-24

Що це означає: ви повернули стан файлової системи до відомої точки. Це часто найшвидший вихід із поганого набору пакетів.
Рішення: після відкату перебудуйте initramfs/GRUB, щоб артефакти завантаження відповідали відновленому стану, потім перезавантажтеся.

Жарт №2: Якщо ваш план відновлення — «перезавантажити ще раз», вітаю — ви реалізували chaos engineering без паперів.

Три корпоративні історії з передової

Інцидент №1: Відмова через неправильне припущення

Середня компанія мала флот Linux-хостів з зеркальними NVMe і ZFS root. Команда нещодавно стандартизувала UEFI.
Їхня модель: «Зеркалені диски — значить і завантаження зеркалене». Вони були наполовину праві, а це найнебезпечніша форма правоти.

Рутинне оновлення включало перевстановлення GRUB і підняття ядра. Зміна спрацювала на стейджингу і на більшості продакшн-нодів.
Один вузол перезавантажився і впав прямо в firmware. Немає меню GRUB. Диск не знайдено. On-call припустив проблеми з імпортом ZFS.
Вони годину марно билися в уявних сценаріях initramfs, хоча машина взагалі не доходила до initramfs.

Справжня проблема: під час циклу оновлення була змонтована лише одна ESP, тож тільки на один диск були записані оновлені EFI-артефакти.
У вузла був попередній тихий глюк NVMe, і прошивка поміняла порядок завантаження на інший диск — у якого ESP був застарілий.
Зеркальні дані ZFS не мали значення; прошивка не може завантажити те, чого там немає.

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

Інцидент №2: Оптимізація, що відплатилася

Інша організація хотіла швидше завантаження і менше складності. Хтось запропонував: «Навіщо тримати окремий boot pool?
Покладемо /boot у кореневий пул і увімкнемо нові ZFS-функції скрізь. Один пул правитиме усім.»
Це продавали як спрощення. Насправді вийшла зв’язка.

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

Вони зрештою відновилися, знайшовши новіше live-середовище і імпортувавши у режимі лише для читання. Але час відновлення виріс.
Постінцидентний аналіз не був про звинувачення; він був про припущення.
«Ми завжди матимемо новий rescue-образ» виявився казкою, яка не переживає довгі вихідні.

Після цього вони відновили шаблон розділення boot pool і почали ставитися до увімкнення feature flags як до зміни в продакшні,
що вимагає явного плану сумісності. Іноді «старі обмеження» існують тому, що світ складний, а не тому, що люди ліниві.

Інцидент №3: Скучна практика, що врятувала день

Команда фінансових сервісів тримала ZFS root з суворим контролем змін. Вони постійно робили одну непопулярну річ:
перед будь-яким вікном оновлення створювали snapshots кореневого датасету і фіксували призначений bootfs у тікеті.
Ніяких героїчних вчинків. Просто дисципліна.

Оновлення призвело до невідповідності між ядром і модулями ZFS. Вузол перезавантажився в initramfs і відмовився імпортувати корінь.
On-call не почав перевстановлювати випадкові пакети. Вони імпортували пули лише для читання з rescue-середовища,
перевірили наявність snapshots і відкотилися до pre-upgrade snapshot.

Потім вони перебудували initramfs і GRUB, перезавантажилися, і система повернулась на старіше, відоме робоче ядро.
Інцидент був коротким і зовсім нецікавим — саме те, що потрібно, коли йдеться про гроші.

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

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

1) Симптом: prompt GRUB або «grub rescue>» після оновлення

Коренева причина: GRUB не може знайти свій prefix/модулі або нумерація дисків/розділів змінилася.

Виправлення: З rescue знайдіть розділ з /boot/grub, встановіть prefix, завантажте normal, запустіть один раз, потім перевстановіть GRUB правильно на всі завантажувальні диски.

2) Симптом: Ядро завантажується, потім падає в initramfs з «cannot import rpool»

Коренева причина: initramfs не містить модулів/інструментів ZFS, зламаний zpool.cache або невірний вказаний кореневий датасет.

Виправлення: Chroot, встановіть/перевірте інтеграцію ZFS у initramfs, перебудуйте initramfs, переконайтесь, що root=ZFS=... вказує на реальний датасет, перегенеруйте GRUB.

3) Симптом: Live ISO не може імпортувати пул, скаржиться на unsupported features

Коренева причина: OpenZFS у rescue-середовищі старший за набір функцій пулу.

Виправлення: Використайте новіший rescue-образ або встановіть нові пакети ZFS у live-середовище. Не форсуйте імпорт, що ризикує корупцією.

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

Коренева причина: ESP/GRUB встановлено лише на одному диску; прошивка змінює порядок завантаження на інший.

Виправлення: Встановіть завантажувач на обидва диска і тримайте ESP синхронізованими; перевіряйте записи UEFI і fallback-шляхи.

5) Симптом: ZFS імпортується в rescue, але система пізніше падає з помилками монтування

Коренева причина: невірні властивості датасету (mountpoint, canmount), або bootfs вказує на неправильний датасет/клон.

Виправлення: Перевірте zfs get mountpoint,canmount, виправте вибір датасету, встановіть bootfs, потім оновіть конфіг завантаження.

6) Симптом: Panic з згадуванням символів ZFS або помилками завантаження модулів

Коренева причина: оновлення ядра без відповідної збірки/встановлення модуля ZFS (помилка DKMS, часткове оновлення пакетів).

Виправлення: Завантажте старіше ядро з GRUB, якщо доступне; інакше chroot, перевстановіть zfs-dkms/zfsutils, перебудуйте модулі і initramfs.

7) Симптом: Пул імпортується, але одразу експортується або відмовляє через «hostid mismatch»

Коренева причина: клонований образ повторно використав hostid, або /etc/hostid змінився несподівано.

Виправлення: Перевірте /etc/hostid в інстальованій системі, виправте за потреби і перебудуйте initramfs, щоб раннє завантаження використовувало правильну ідентичність.

8) Симптом: «No such device» для vmlinuz/initrd у GRUB

Коренева причина: /boot не було змонтовано під час оновлення; initramfs і ядра записані в інше місце, або невідповідність bpool.

Виправлення: Змонтуйте bpool правильно, повторіть update-initramfs і grub-mkconfig; перевірте наявність файлів у /boot.

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

Чекліст відновлення (робіть у цьому порядку, зупиняйтесь, коли система завантажиться)

1. Визначте режим завантаження: UEFI з ESP або BIOS. Використайте lsblk для виявлення vfat ESP розділів.
2. Підтвердіть етап збою: перед GRUB, у GRUB, в initramfs або пізніше.
3. Завантажте сумісне rescue-середовище з ZFS-інструментами, близькими до набору функцій вашого пулу.
4. Запустіть zpool import і прочитайте помилку. Не діяти навмання.
5. Імпортуйте пули у режимі лише для читання з -N для безпечної інспекції.
6. Перевірте zpool status на наявність деградацій і відсутніх членів.
7. Знайдіть кореневий датасет і bootfs (zfs list, zpool get bootfs).
8. Змонтуйте root і зробіть chroot (bind /dev, /proc, /sys).
9. Перебудуйте initramfs і переконайтесь, що компоненти ZFS включено.
10. Перегенеруйте конфіг GRUB, щоб root=ZFS=... відповідало реальності.
11. Перевстановіть завантажувач в потрібну ціль:
    • BIOS: grub-install /dev/disk для кожного завантажувального диска.
    • UEFI: змонтуйте ESP, grub-install --target=x86_64-efi ..., перевірте efibootmgr.
12. Перезавантажте один раз і спостерігайте. Якщо не вдається, зафіксуйте точне повідомлення і повертайтеся до моделі ланцюжка збою.

Чекліст запобігання (майбутній ви заслуговує приємностей)

• Створюйте перед-оновлювальний snapshot кореневого датасету і використовуйте зрозумілу конвенцію імен у 3:00 ночі.
• Перевіряйте успішність збірок DKMS/модулів перед плановим перезавантаженням.
• Тримайте хоча б одне відоме добре старіше ядро в GRUB.
• На зеркальних завантаженнях встановлюйте/оновлюйте EFI-артефакти або GRUB на обох дисках, а не лише на „тому, який змонтований сьогодні”.
• Зберігайте rescue-ISO (або netboot) яке може імпортувати ваші пул-функції. Оновляйте його при зміні флагів.
• Документуйте схему пулу: які розділи належать bpool/rpool, де ESP живе і очікуваний bootfs.

FAQ

1) Чи завжди мені потрібен окремий boot pool (bpool)?

Ні, але це прагматичний захід. Окремий boot pool може тримати /boot на наборі функцій ZFS, які завантажувачі добре підтримують.
Якщо ваша платформа охайно завантажується з кореневого пулу і ви жорстко контролюєте увімкнення функцій, один пул може працювати.
Якщо ви хочете надійні шляхи порятунку, розділення зазвичай варте незначної складності.

2) Чому імпортувати пули спочатку лише для читання?

Тому що паніка змушує людей виконувати руйнівні команди. Імпорт лише для читання дозволяє перевірити датасети, snapshots і стан без внесення змін.
Після розуміння проблеми перемонтуйте в режимі читання-запису для цільових виправлень.

3) Моє rescue ISO не може імпортувати через unsupported features. Можу я «force»?

Не робіть цього. Unsupported features означають, що програмне забезпечення буквально не розуміє частин формату на диску.
Ваше рішення — використовувати новіші OpenZFS-інструменти, а не ризикувати пулом.

4) Якщо GRUB показує меню — чи означає це, що завантажувач в порядку?

Це означає, що GRUB принаймні виконується. У вас все ще можуть бути биті шляхи до ядра/initrd, невірний root=ZFS=,
або відсутня історія модулів ZFS, що проявиться пізніше в initramfs.

5) Як дізнатися, який датасет має завантажуватися?

Перевірте zpool get bootfs rpool. Потім підтвердіть існування датасету через zfs list.
Якщо ви використовуєте кілька boot environments, призначений зазвичай відображається й у записах GRUB.

6) Яка найпоширеніша поломка через «погане оновлення» на ZFS root?

Невідповідність між ядром і модулем ZFS. Ядро оновлюється, DKMS тихо провалюється, і initramfs завантажується без здатності імпортувати ZFS.
Виправлення зазвичай: chroot, відновлення пакетів, перебудова initramfs, перегенерація GRUB.

7) Чи потрібно експортувати пули перед перезавантаженням з rescue?

Ідеально — так: zpool export rpool і zpool export bpool після завершення, щоб наступне завантаження імпортувало чисто.
Якщо ви використовували import лише для читання і відразу перезавантажуєте, це також хороша гігієна, особливо в складних сесіях порятунку.

8) Чи можна відновити, відкотившись до snapshots навіть якщо завантаження зламане?

Часто так, бо rollback можна виконати з rescue після імпорту пулу. Важливо відкотити правильний кореневий датасет
і потім забезпечити, щоб артефакти завантаження (initramfs/GRUB/EFI) відповідали відновленому стану.

9) Чому зеркальний ZFS не гарантує зеркальне завантаження?

ZFS зеркалює ваші дані ZFS. Прошивка завантажується з ESP/MBR/локацій завантажувача, які можуть не бути зеркалені, якщо ви цього не налаштували.
Розглядайте «резервність завантаження» як окрему інженерну вимогу.

10) Чи варто увімкнути нові ZFS feature flags на завантажувальному пулі?

Будьте обережні. Завантажувальні пули існують для завантаження, а не для експериментів. Увімкнюйте функції в кореневому пулі, коли вони дійсно потрібні,
і тільки після перевірки, що завантажувачі і rescue-інструменти зможуть працювати.

Висновок: що зробити наступного разу (до 2:00)

Відновлення завантажувального пулу ZFS — це не чорна магія. Це послідовність: визначити етап збою, безпечно імпортувати, підтвердити призначений boot датасет,
а потім виправити саме те, що зламано — завантажувач, initramfs або узгодження пакетів.

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

• Запишіть схему пулу (bpool/rpool, ESPs, відображення дисків) і зберігайте її в runbook.
• Автоматизуйте перед-оновлювальні snapshots і зробіть rollback першокласним варіантом.
• Переконайтесь, що артефакти завантаження встановлюються на кожен завантажувальний диск, а не лише на той, який ОС випадково змонтувала.
• Тримайте відоме добре rescue-середовище, яке може імпортувати ваші pool-функції — і оновлюйте його при зміні флагів.
• Протестуйте шлях «поганого оновлення» на некритичному хості: навмисно зламайте, обережно відновіть і засічіть час.

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