openSUSE Tumbleweed: інсталяція без «катастрофічних» оновлень

На що ви підписуєтеся (і чому це може бути розумно)

Tumbleweed — це rolling‑реліз. Це означає, що ваша система постійно еволюціонує: kernel, Mesa, systemd, драйвери, весь стек. Ви не «оновлюєтесь з 15.5 на 15.6». Ви рухаєтесь по потоку протестованих знімків.

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

Отже: не встановлюйте Tumbleweed як хобі‑машину, яку можна перевстановити у дощовий вікенд. Встановлюйте його як кінцеву точку, яка має працювати після оновлень, переживати втрату живлення і відновлюватися після помилок майбутнього вас. Добра новина: налаштування openSUSE несподівано добре підходять для такого підходу — якщо ви їх не саботуєте.

Одна керівна ідея, перефразована з думки, часто приписуваної John Allspaw: надійність — це властивість усієї системи, включно з людьми, які її експлуатують.

Ось домовленість, в якій я буду категоричним:

• Використовуйте Btrfs для кореневого розділу з знімками, якщо у вас немає конкретної, програної причини цього не робити.
• Тримайте /home окремо (окремий субтом або окрема файловa система з іншою політикою знімків), якщо вам важливий простий відкат і розумне використання диска.
• Віддавайте перевагу UEFI. Legacy BIOS працює, але UEFI + GRUB2 — це шлях з меншим числом «підводних мін».
• Не «оптимізуйте» безпеку. Якщо ви відключите знімки, бо «мені вони не потрібні», ви незабаром виявите, що були потрібні.

Жарт №1: Rolling‑релізи як закваска для хліба — занедбайте її тиждень, і вона почне мати власну думку.

Факти й історія, що пояснюють характер Tumbleweed

Контекст важливий, бо дистрибутиви — це культура в коді. Кілька конкретних фактів, що визначають, чому Tumbleweed поводиться так, а не інакше:

1. Tumbleweed став офіційним rolling‑релізом у 2015 році, замінивши ранні спільнотні варіанти. Цей крок зміцнив процес релізів.
2. openQA — центральна частина Tumbleweed: автоматизовані інсталяції та системні тести відсікають знімки. Це не магія, але причина, чому руйнування зазвичай «дивакувате крайове», а не «все горить».
3. zypper має надійний розв’язувач залежностей вже роками, і SUSE давно ставить менеджмент пакетів як питання продакшену, а не побічний проект.
4. Інтеграція Snapper + Btrfs — не післядумка. Це частина стандартної історії інсталяції, включно з інтеграцією в завантажувач для відкату.
5. YaST має десятиліття оперативного досвіду. Любіть інтерфейс чи ні — він створений для адміністраторів, які не хочуть правити все вручну о 3‑й ранку.
6. Tumbleweed відстежує «протестовані знімки», а не «усе, що щойно склалося». Це тонка різниця від деяких rolling‑моделей, які штовхають пакети щойно вони зібралися.
7. SELinux тут не головна MAC‑історія; тут переважає AppArmor. Це впливає на сценарії налагодження та «чому це блокується?» моменти.
8. Підхід SUSE з корпоративним корінням видно у нудних речах: налаштування за умовчанням, вибір файлових систем та інструменти оновлення. Нудно — добре, коли ви на чергуванні.

Жоден з цих фактів не гарантує, що ви не натрапите на регресії. Але вони означають, що проєкт вкладає реальні зусилля, щоб «rolling» був сумісним з «робоча машина, на яку ви покладаєтесь».

Проєктні рішення, які запобігають «rolling»‑катастрофам

Btrfs на root — це функція надійності, а не модний тренд

Традиція openSUSE «Btrfs для /, XFS для /home» не випадкова. Коренева файловa система часто змінюється і виграє від знімків і відкату. Домашні каталоги активно змінюються великими персональними даними і не завжди виграють від знімання кожної пакетної транзакції.

Для Tumbleweed практичний ефект величезний: якщо оновлення kernel + драйвери «вбиває» завантаження або GUI, ви можете перезавантажитися в старий знімок і повернутися до роботи. Це не теоретично. Це — у вівторок.

Snapper ефективний тільки якщо межі чисті

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

• Часто та автоматично знімайте root (OS + конфіги).
• Тримайте змінні або великі шляхи поза знімками (або на іншій файловій системі/субтомі).
• Контролюйте /var: логи важливі, кеші — ні.

Rolling означає операціоналізувати оновлення

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

Тому: оновлюйте регулярно, читайте вивід розв’язувача і не ставтеся до підказок «vendor change» як до пригодницької гри, написаної мавпою хаосу.

Підготовка: прошивка, диски та мережеві налаштування

Налаштування UEFI, які важливі

Перед тим, як завантажити інсталятор, зайдіть у налаштування прошивки. Так, це дратує. Але це місце, де народжується багато «Linux не працює» звернень.

• UEFI режим: увімкніть його. Якщо ви мусите використовувати legacy BIOS, прийміть, що ви у більш вузькому й дивному світі.
• Secure Boot: Tumbleweed може з цим працювати, але сторонні kernel‑модулі (особливо NVIDIA) додають складнощів. Вирішіть одразу — вам важливіша безпека чи зручність.
• Режим SATA: поставте AHCI, якщо у вас немає причини (та драйверів) використовувати RAID.

Розмітка диска: ваша майбутня стратегія відкату починається тут

Інсталятор може створити гідну стандартну розмітку. Але варто зрозуміти форму системи, яку ви створюєте:

• EFI System Partition (ESP): маленький FAT32 розділ, змонтований у /boot/efi. Тримайте його; не вигадуйте.
• / (root): Btrfs з увімкненими субвінями, які Snapper може коректно знімати.
• /home: XFS (типово) або Btrfs з іншим політикою знімків. При повному шифруванні консистентність важливіша за файлові вподобання.
• Swap: для ноутбуків розгляньте swap як розділ, якщо потрібна надійність гібернації; інакше swapfile зазвичай підходить.

Мережа: NetworkManager чи wicked

На робочих станціях і ноутбуках: NetworkManager. На серверах зі статичною конфігурацією: wicked може бути підходящим. Режим відмов тут передбачуваний: оберіть wicked і очікуйте UX для Wi‑Fi роумінгу та VPN, як у десктопі — це не те, для чого створено wicked.

Чеклісти / покроковий план (з виборами і наслідками)

Крок 0: Визначте, яким буде цей Tumbleweed‑пристрій

• Ноутбук для розробника: Btrfs root + знімки, /home окремо, NetworkManager, агресивне керування живленням, часті оновлення.
• Робоча станція з GPU‑драйверами: те ж саме, але передбачте тертя з драйверами і тестуйте знімки перед важливими презентаціями.
• Домашній сервер / лабораторія: теж знімки, але суворіше ставтесь до етапних оновлень і вікон для перезавантаження.

Крок 1: Встановіть з правильними стандартними файловими системами

У розмітці інсталятора:

• Залиште або створіть ESP (FAT32), змонтований як /boot/efi.
• Встановіть / як Btrfs з увімкненими субвінями (зазвичай так робить guided setup за замовчуванням).
• Розмістіть /home на XFS або окремому Btrfs субвінні з вимкненими або обмеженими знімками.

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

Крок 2: Обирайте десктоп так, як обираєте чергування on‑call

• KDE Plasma: шліфований, функціональний, чудово підходить для досвідчених користувачів, трохи більше рухомих частин.
• GNOME: послідовний, сильна Wayland‑історія, однозначний UX.
• Minimal + ваш вибір: підходить, якщо ви знаєте, що робите, і любите власні дрібні незручності.

Крок 3: Увімкніть знімки і зробіть їх завантажуваними

У openSUSE Snapper і інтеграція з GRUB зазвичай налаштовані. Але «зазвичай» — не SLA. Після інсталяції перевірте це (команди нижче).

Крок 4: Визначте частоту оновлень

• Щоденні/щотижневі оновлення: найкращий досвід, найменші діфы, найменше проблем із розв’язувачем.
• Щомісячні оновлення: очікуйте більших змін і більше рішень про «vendor change».

Оберіть такт, який ви реально зможете підтримувати. Rolling‑реліз не вибачає побажань.

Практичні завдання: команди, очікуваний вивід і що робити далі

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

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

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

Значення: «UEFI» означає, що kernel бачить середовище виконання EFI.

Рішення: Якщо ви очікували UEFI, а бачите «BIOS», виправте режим прошивки тепер — перш ніж заглиблюватися у налагодження GRUB у невірному всесвіті.

Завдання 2: Перевірити поточний kernel і базову платформу

cr0x@server:~$ uname -a
Linux server 6.7.9-1-default #1 SMP PREEMPT_DYNAMIC ... x86_64 GNU/Linux

Значення: Підтверджує версію kernel і його варіант. На Tumbleweed версії kernel рухаються швидко.

Рішення: Якщо ви діагностуєте регресію, зафіксуйте версію kernel. Часто це ключовий фактор.

Завдання 3: Перевірити Btrfs на root і опції монтування

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /
btrfs rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@/.snapshots/1/snapshot

Значення: Root — Btrfs; шлях субвіня показує, що ви в корені, отриманому зі знімка (нормально для openSUSE).

Рішення: Якщо root — ext4, а ви очікували Btrfs зі знімками, вирішіть: перевстановити чи прийняти відсутність відкату. Дорабляти пізніше можна, але це складніше.

Завдання 4: Перелік субвінів Btrfs для підтвердження структури

cr0x@server:~$ sudo btrfs subvolume list /
ID 256 gen 123 top level 5 path @
ID 257 gen 123 top level 5 path @/var
ID 258 gen 124 top level 5 path @/.snapshots
ID 259 gen 123 top level 5 path @/usr/local
ID 260 gen 123 top level 5 path @/tmp

Значення: Показує окремі субвіня. openSUSE використовує це, щоб контролювати, що знімається і як.

Рішення: Якщо бачите все під одним субвіном, Snapper зніматиме занадто багато. Розгляньте перевстановлення з guided partitioning або налаштуйте субвіня до накопичення даних.

Завдання 5: Переконатися, що конфіги Snapper існують і активні

cr0x@server:~$ sudo snapper list-configs
Config | Subvolume
-------+----------------
root   | /
home   | /home

Значення: Snapper налаштований принаймні для root (і можливо для home).

Рішення: Якщо відсутній конфіг root, виправте Snapper перед тим, як довіряти відкату. Без знімків — без парашута.

Завдання 6: Підтвердити автоматичні знімки під час пакетних операцій

cr0x@server:~$ systemctl status snapper-timeline.timer --no-pager
● snapper-timeline.timer - Timeline of Snapper Snapshots
     Loaded: loaded (/usr/lib/systemd/system/snapper-timeline.timer; enabled)
     Active: active (waiting) since ...

Значення: Timeline‑знімки увімкнені (періодичні). Пакетні знімки створюються плагінами zypper; таймери відповідають за утримання за часом.

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

Завдання 7: Переглянути репозиторії та їхні пріоритети

cr0x@server:~$ zypper lr -P
#  | Alias                   | Name               | Enabled | GPG Check | Refresh | Priority
---+-------------------------+--------------------+---------+-----------+---------+---------
1  | repo-oss                | openSUSE OSS       | Yes     | (r ) Yes  | Yes     |   99
2  | repo-non-oss            | openSUSE Non-OSS   | Yes     | (r ) Yes  | Yes     |   99
3  | repo-update             | openSUSE Update    | Yes     | (r ) Yes  | Yes     |   99

Значення: Ви бачите, які репозиторії існують, чи оновлюються вони та який з них перемагає при конфлікті версій.

Рішення: Якщо ви додали сторонні репозиторії, переконайтеся, хто «володіє» пакетами. Випадкові пріоритети — як будувати Franken‑систему.

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

cr0x@server:~$ sudo zypper dup --dry-run
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 12 packages are going to be upgraded:
  kernel-default systemd Mesa-libGL1 ...

Overall download size: 180.5 MiB.

Значення: Показує обсяг змін. Також виявляє vendor‑зміни або видалення до того, як ви підтвердите операцію.

Рішення: Якщо розв’язувач пропонує видалення, які ви не розумієте (особливо GPU‑стек, десктоп або мережа), зупиніться та розберіться перед реальним запуском dup.

Завдання 9: Виявити пропозиції про зміну постачальника до їх прийняття

cr0x@server:~$ sudo zypper dup
...
The following package is going to change vendor:
  libfoo  openSUSE -> obs://build.some.repo
Continue? [y/n/v/...? shows all options] (y):

Значення: Третій‑партійний репозиторій прагне замінити бібліотеку або компонент ядра.

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

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

cr0x@server:~$ sudo grep -R "openSUSE snapshots" -n /boot/grub2/grub.cfg | head
1023:menuentry 'openSUSE snapshots' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-snapshots' {

Значення: GRUB налаштований на показ записів для завантаження зі знімків.

Рішення: Якщо відсутні — відкат при завантаженні ускладнюється. Виправте інтеграцію GRUB/Snapper до того, як вона знадобиться, а не під час інциденту.

Завдання 11: Переконатися, що ESP змонтований і не переповнений

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE     FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

cr0x@server:~$ df -h /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  512M  120M  392M  24% /boot/efi

Значення: ESP присутній, змонтований і має вільне місце.

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

Завдання 12: Перевірити ознаки стану диска та підказки планувальника вводу/виводу

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL
nvme0n1    disk  953.9G              Samsung SSD 980
├─nvme0n1p1 part    512M vfat   /boot/efi
├─nvme0n1p2 part      2G swap   [SWAP]
└─nvme0n1p3 part  951.4G btrfs  / /home

Значення: Підтверджує, що й де розташовано. Ви здивуєтеся, як часто «root заповнений» насправді означає «home знаходиться на root».

Рішення: Якщо ви планували окремі файлові системи і їх не бачите — виправте це раніше, поки дані не виросли.

Завдання 13: Аудит тиску пам’яті та використання swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       9.2Gi       4.1Gi       1.1Gi        18Gi        21Gi
Swap:          2.0Gi          0B       2.0Gi

Значення: Ключове число для «чи скоро система почне свапитися?» — це «available».

Рішення: Якщо swap активно використовується під нормальним навантаженням, вузьке місце, ймовірно, у пам’яті (або якийсь процес вийшов з під контролю), а не «Linux повільний».

Завдання 14: Перевірити час завантаження і останні відмови

cr0x@server:~$ systemd-analyze time
Startup finished in 3.112s (kernel) + 8.904s (userspace) = 12.016s
graphical.target reached after 8.701s in userspace.

cr0x@server:~$ systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● ModemManager.service          loaded failed failed Modem Manager

Значення: systemctl --failed показує, що активно зламано. Не ігноруйте відмови — вони часто ранній сигнальний механізм.

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

Завдання 15: Читайте логи як слід

cr0x@server:~$ sudo journalctl -p err -b --no-pager | tail -n 20
Feb 05 09:13:02 server kernel: nouveau 0000:01:00.0: firmware: failed to load nouveau/...
Feb 05 09:13:05 server systemd[1]: Failed to start Modem Manager.

Значення: Помилки з поточного завантаження, відфільтровані по «err». Це швидкий спосіб побачити реальні причини симптомів.

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

Оновлення як у SRE: zypper dup без драм

Оновлення в Tumbleweed — це не zypper up. Підтримувана ментальна модель — це дистрибуційне оновлення: zypper dup. Саме так ви залишаєтеся у відповідності з тестованим набором знімків.

Процедура, яка тримає вас в безпеці

1. Оновіть метадані репозиторіїв (і переконайтеся, що ви їм довіряєте).
2. Зробіть dry‑run, щоб зрозуміти обсяг змін.
3. Оновлюйте уважно, а не на автопілоті.
4. Перезавантажуйте після зміни критичних компонентів (kernel, systemd, Mesa, glibc). Так, навіть на робочій станції.

Конкретні команди: оновити, переглянути, оновити

cr0x@server:~$ sudo zypper refresh
Repository 'openSUSE OSS' is up to date.
Repository 'openSUSE Non-OSS' is up to date.
Repository 'openSUSE Update' is up to date.

Значення: Метадані актуальні. Якщо refresh не вдається — ви, можливо, налагоджуєте мережу або проблеми з mirror‑ами, а не пакети.

cr0x@server:~$ sudo zypper dup --details
...
Overall download size: 480.2 MiB. After the operation, additional 52.0 MiB will be used.

Значення: «After the operation» — це ваш ранній сигнал про зміну дискового використання для малого root.

Рішення: Якщо root має < 5–10 GiB вільного місця і ви тягнете великі оновлення — очистіть знімки і кеші перш ніж починати. Не чекайте «дисковий простір закінчився» посеред транзакції.

Коли розв’язувач пропонує видалення

Видалення не завжди погане. Вони автоматично підозрілі.

• Якщо він хоче видалити мета‑пакет десктопа — ви матимете поганий день.
• Якщо він видаляє застарілу бібліотеку, якою ви не користуєтесь — добре.
• Якщо він хоче видалити ваш GPU‑стек — зупиніться і з’ясуйте причину.

Жарт №2: розв’язувач залежностей як адвокат — якщо ви не читаєте дрібний шрифт, він із задоволенням дозволить вам підписати відмову від десктопа.

Знімки, відкат і як їх не знищити

Зрозумійте, що саме робить відкат

Відкат в openSUSE з Btrfs/Snapper зазвичай означає: завантажитися в старіший знімок кореневої файлової системи. Це потужно, бо повертає системні бінарні файли і конфіги в попередній стан. Але це не машина часу для всього.

Речі, які можуть не відкотитися чисто, якщо це не передбачено:

• Дані в /home, якщо вони на окремій файловій системі або виключені зі знімків.
• Бази даних або сервіси зі станом у /var, якщо ви їх знімаєте, але не керуєте консистентністю.
• Прошивка, збережена поза коренем файлової системи, залежно від апаратного забезпечення.

Як безпечно використовувати знімки в операціях

Для робочої станції ось план:

1. Запустіть zypper dup.
2. Швидко перезавантажтеся, якщо змінилися kernel/graphics/systemd.
3. Якщо завантаження не вдається або графіка зламана — перезавантажтеся в попередній знімок через GRUB.
4. З працюючого знімка оцініть: зачекати новий знімок, відрегулювати репозиторії або зафіксувати/заморозити драйвери.

Не накопичуйте знімки назавжди

Знімки коштують місця. На Btrfs — ця вартість інкрементальна, поки раптом не виявиться великою. Великі зміни, VM‑образи, контейнери й хаотичний кеш браузера можуть вибухнути дельти знімків.

cr0x@server:~$ sudo snapper list | tail
  90  | single |       |         | root | 2026-02-01 09:00:01 |      | number cleanup
  91  | pre    |  5123 | zypp(zypper) | root | 2026-02-03 18:41:22 |      | zypp pre
  92  | post   |  5123 | zypp(zypper) | root | 2026-02-03 18:45:10 |      | zypp post

Значення: Ви бачите timeline («single») і пакетні («pre/post») знімки.

Рішення: Якщо у вас сотні знімків — політика зберігання надто щедра для вашого диска. Налаштуйте cleanup у Snapper, не видаляйте знімки хаотично.

cr0x@server:~$ sudo btrfs filesystem df /
Data, single: total=120.00GiB, used=92.15GiB
Metadata, DUP: total=8.00GiB, used=6.90GiB
System, DUP: total=32.00MiB, used=16.00MiB

Значення: Btrfs повідомляє про розподілені та використані чанки. «Used» — реальне споживання; «total» — виділені області.

Рішення: Якщо Metadata майже заповнений, ви можете отримати ENOSPC при значній кількості «вільного» Data. Класичний сюрприз Btrfs — вирішуйте його, звільнивши місце та виконавши balance за потреби, а не панічним перевстановленням.

Швидкий план діагностики: що перевірити спочатку/другим/третім

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

Спочатку: Чи завантажується очікуване середовище?

• Режим завантаження: UEFI чи BIOS? (Завдання 1)
• Версія kernel: змінилася недавно? (Завдання 2)
• Чи завершилося останнє оновлення? Перевірте історію zypper і запущені сервіси.

cr0x@server:~$ sudo tail -n 30 /var/log/zypp/history
2026-02-03 18:41:22|install|kernel-default|6.7.9-1.1|x86_64|repo-oss|...
2026-02-03 18:45:10|remove |kernel-default|6.7.8-1.1|x86_64|@System|...

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

По‑друге: Що є вузьким місцем — CPU, пам’ять, диск чи мережа?

• Навантаження CPU: високий load при низькому IO wait вказує на навантаження CPU.
• Тиск пам’яті: використання swap і низьке «available» вказує на брак пам’яті.
• Тиск диска: ENOSPC і заповнена метадані Btrfs створюють ілюзію «все повільно».
• Мережа/DNS: відмови при оновленні репозиторіїв і «інтернет повільний» часто означають проблеми з DNS.

cr0x@server:~$ uptime
 09:22:11 up 3 days,  1:02,  2 users,  load average: 0.42, 0.55, 0.60

Рішення: Load average < 1 на багатоядерній системі зазвичай не ваша проблема. Шукайте далі.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 4200000 120000 18000000  0    0    12    28  410  900  3  1 95  1  0

Значення: wa — IO wait; si/so — свопінг. Високе wa вказує на проблему зі зберіганням; високе so — на тиск пам’яті.

Рішення: Якщо wa високе — перевірте диск і файлову систему. Якщо активний swap — припиніть звинувачувати GPU.

По‑третє: Один сервіс голосно відвалився?

cr0x@server:~$ systemctl --failed
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
● display-manager.service loaded failed failed X Display Manager

Рішення: Провалений display manager після оновлення кричить «проблема з графічним стеком». Відкатніться або переключіться на відомо‑робоче поєднання kernel/driver перш ніж редагувати купу конфігів.

Далі: Підтвердьте графічний стек (типова біль для робочих станцій)

cr0x@server:~$ loginctl show-session "$(loginctl | awk 'NR==2{print $1}')" -p Type
Type=wayland

Значення: Wayland чи X11 впливає на поведінку драйверів і кроки налагодження.

Рішення: Якщо у вас NVIDIA і Wayland став глючити після оновлення — протестуйте X11 (або попередній знімок), щоб бісектувати, чи проблема в композитору/драйвері/kernel.

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

1) «Після оновлення завантаження — чорний екран»

Симптом: Система завантажується, але дисплей‑менеджер не з’являється; можливо, миготливий курсор.

Причина: Невідповідність kernel/драйвера (часто NVIDIA), пошкоджений initramfs або відмова дисплей‑менеджера через зміни в графічному стеці.

Виправлення: Завантажтеся в старіший знімок через GRUB. Підтвердьте systemctl --failed і journalctl -p err -b. Якщо це NVIDIA — вирівняйте пакети драйверів з працюючим kernel і розгляньте відкладення оновлень, поки репозиторій драйверів не наздожене.

2) «zypper dup хоче видалити половину мого десктопа»

Симптом: Розв’язувач пропонує видалити патерни Plasma/GNOME або ключові бібліотеки.

Причина: Сторонні репозиторії з конфліктними пакетами, зміни постачальника або часткові оновлення від перемішування up і dup з часом.

Виправлення: Зупиніться. Перевірте репозиторії (zypper lr -P). Віддавайте перевагу офіційним репозиторіям. Якщо потрібні сторонні — мінімізуйте їх і розумійте зміни постачальника. Виконуйте zypper dup --dry-run, поки план не стане зрозумілим.

3) «Мій диск «повний», але df показує місце»

Симптом: Записи не вдаються, встановлення пакетів падає, але df -h показує вільне місце.

Причина: Вичерпання метаданих Btrfs або проблеми з алокацією чанків.

Виправлення: Перевірте btrfs filesystem df / і btrfs filesystem usage /. Звільніть простір, обрізавши знімки і кеші; за потреби зробіть balance, якщо знаєте, що робите. Не запускайте випадкові «btrfs magic» команди опів на дві.

4) «Відкат не виправив дані програми»

Симптом: Ви відкотилися, але проєктна папка/конфіг у home все ще «ламана».

Причина: /home не є частиною кореневих знімків (так задумано), або релевантні дані живуть поза знімками.

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

5) «Мережа після сну іноді не повертається»

Симптом: Wi‑Fi нестабільно перепідключається; VPN не працює, поки не перезавантажитеся.

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

Виправлення: Використовуйте NetworkManager на ноутбуках. Перевірте логи NetworkManager і повідомлення kernel про Wi‑Fi драйвер. Якщо регрес — завантажтеся в попередній kernel або знімок і зачекайте на виправлений знімок.

6) «Secure Boot зламав мій сторонній kernel‑модуль»

Симптом: Після увімкнення Secure Boot модулі NVIDIA/VirtualBox не завантажуються.

Причина: Потрібен підпис модулів. Непідписані модулі не завантажаться під Secure Boot без MOK‑реєстрації/підпису.

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

Три корпоративні історії (ви впізнаєте цих людей)

Інцидент №1: Аварія через хибне припущення

Середня інженерна організація впровадила Tumbleweed на робочих станціях розробників, бо важливий був апаратний саппорт: нові ноутбуки, нові GPU, купа зовнішніх дисплеїв. Пілот пройшов добре. Потім вони масштабували швидко, бо пілотна команда була голосною й переконливою — завжди небезпечна комбінація.

Вони припустили, що відкат означає «усе повернеться назад». Тому дозволили командам тримати масивні проєктні дерева в /home на окремій файловій системі і сказали всім: «Якщо оновлення зламає — просто відкотіться». Це правда для ОС. Не правда для стану в домашніх директоріях.

Інцидент: оновлення змінило компонент тулчейну, і кілька команд перебудували кеші та проміжні артефакти локально. Коли виявили регресію, вони відкотили ОС. Кеші в /home залишилися «новими». Деякі збірки стали використовувати старі бінарі з новими кешами, породжуючи дивні, перемежовані помилки.

Це не був один великий вибух. Набагато гірше: низькорівнева неконсистентність. Інженери втратили дні на пошук фантомних багів.

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

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

Інша компанія стандартизувала Btrfs root з знімками — добре. Потім хтось помітив зростання використання диска на 256 GB ноутбуках і вирішив «оптимізувати зберігання». План: агресивно відключити timeline‑знімки, зменшити кількість zypp‑знімків і виключити більше шляхів зі знімків. На папері це зменшило churn.

Кілька місяців все виглядало добре. Менше знімків. Більше вільного місця. Всім подобалася дисципліна — замість «hoarder‑ів знімків».

Потім з’явився графічний регрес, що вразив конкретну модель ноутбука. Правильна відповідь була б: завантажити останній відомо‑добрий знімок і продовжити роботу, поки фікс не з’явиться. Але на тих системах практично не залишилося знімків — лише кілька недавніх транзакцій, і вікно утримання вже видалило робочий стан.

Результат: екстрені перевстановлення, ручне фіксування пакетів і багато «чому відкат нас не врятував?» на зустрічах, де ніхто не хотів визнавати відповідь.

Кінцеве виправлення було нудним і дещо принизливим: відновили розумний retention знімків, винесли великі не‑OS дані з кореневого знімання і впровадили моніторинг диска, щоб налаштовувати retention на основі реального використання, а не відчуттів. Оптимізація безпеки — просто технічний борг із презентабельною постурою.

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

Регульована організація запускала Tumbleweed для невеликого флоту інженерських десктопів — так, справді. Вони зробили це, бо потрібні були сучасні kernel для специфічних апаратних інтерфейсів і бо їхні інженери не хотіли застарілих тулчейнів. Команда комплаєнсу погодилася за однієї умови: оновлення мають бути поетапними і відкотними.

Тож операційна команда зробила непрестижне, але практичне: створили простий ритм. Щотижня невелика група канарейок оновлювалася першою. Вони перезавантажувалися. Запускали короткий тестовий скрипт, що перевіряв VPN, smartcard‑автентифікацію і кілька внутрішніх додатків. Лише потім оновлювався решта флоту.

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

Оскільки регресію виявили до широкого розгортання, організація уникла ранкового хаосу, коли б половина інженерів не змогла авторизуватися. Ніяких геройств, жодної ночі у «war room». Просто невеликий gate і відкат, який вони відрепетирували.

Практика була неефектною. Саме тому вона працювала.

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

1) Чи варто використовувати Tumbleweed для продакшен‑сервера?

Можна, але потрібно дисципліновано: контрольовані репозиторії, поетапні оновлення, вікна обслуговування і план відкату. Якщо вам потрібен «встановив і забув» — оберіть стабільну гілку.

2) Чому всі кажуть «використовуйте zypper dup» замість «zypper up»?

dup вирівнює вашу систему з поточним дистрибуційним знімком, коректно обробляє зміну постачальника і трансіції. up підходить у деяких випадках, але для Tumbleweed це неправильний дефолт, бо він може залишити систему частково оновленою з часом.

3) Чи справді потрібно перезавантажуватися після оновлень?

Якщо змінили kernel, systemd, Mesa або критичні бібліотеки — так. Можна «тимчасово» працювати далі, але ви матимете несумісність між старими процесами і новими файлами. Саме так народжуються баги, що «ламаються через два дні».

4) Btrfs лякає. Чи підходить ext4?

Технічно ext4 підходить. Операційно ви відмовляєтесь від першокласного відкату і простого відновлення після невдалих оновлень. Для Tumbleweed Btrfs root — прагматичний вибір.

5) А як щодо /home на Btrfs проти XFS?

XFS стабільний для великих домашніх директорій і уникає churn‑у знімків. Btrfs для /home теж робочий варіант, якщо ви налаштуєте політику знімків і не будете випадково знімати терабайти VM‑образів кожного разу при встановленні шрифта.

6) Як дізнатися, до якого знімка відкотитися?

Вибирайте знімок прямо перед транзакцією, що ввела проблему (часто це пара zypp pre/post). Користуйтеся датою і описом у snapper list, потім завантажуйтесь через GRUB зі знімків.

7) Чи варто включати Secure Boot на Tumbleweed?

Для багатьох ноутбуків — так, якщо вам важлива модель загроз. Якщо ви покладаєтеся на сторонні kernel‑модулі, плануйте підпис модулів або прийміть додаткові труднощі. Не вмикайте його абияк і не дивуйтеся, коли непідписані модулі не завантажуються.

8) NetworkManager чи wicked?

NetworkManager для ноутбуків і десктопів. wicked для серверів, де потрібна стабільна декларативна конфігурація і вам не потрібен десктопний UX роумінгу Wi‑Fi.

9) Як не перетворити систему на репо‑безлад?

Тримайте сторонні репозиторії мінімальними й усвідомленими. Уникайте змішування кількох репозиторіїв, що замінюють базові компоненти. Якщо вам потрібен один спеціальний пакет, подумайте, чи не краще встановити його окремо, замість підключення репозиторію, який замінює бібліотеки.

10) Яка найкорисніша команда для налагодження на Tumbleweed?

journalctl -p err -b. Якщо у вас є час тільки на одну річ — читайте помилки поточного завантаження і припиніть гадати.

Наступні кроки, які варто реально зробити

Встановити Tumbleweed — легка частина. Тримати його стабільним — це рутина: коротка, відтворювана і трохи нудна. І це головне.

Негайні кроки (сьогодні)

• Перевірте UEFI завантаження, монтування ESP і структуру Btrfs субвінів (Завдання 1, 4, 11).
• Переконайтеся, що Snapper налаштований і таймери увімкнені (Завдання 5, 6).
• Запустіть zypper dup --dry-run і звикніть читати план (Завдання 8).
• Навчіться завантажувати знімок через GRUB до того, як він стане вам потрібен.

Операційні кроки (цю тиждень)

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

Tumbleweed не гарантує життя без драм. Але встановлений із правильною розміткою файлової системи, знімками і адекватною процедурою оновлень, він — один з рідкісних rolling‑релізів, який може бути і сучасним, і надійним. Вам не потрібна удача. Вам потрібні запобіжники і смирення, щоб їх підтримувати.