Катастрофа при зміні розміру розділу: скасуйте й завантажтеся знову

Правила взаємодії (щоб не зробити гірше)

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

Зробіть це спочатку

• Припиніть запис. Якщо це VM, зніміть снапшот на рівні гіпервізора зараз. Якщо це фізичний диск, клонувати диск або зробіть його образ, якщо можете.
• Працюйте з Live-середовища. Не завантажуйте зламану ОС і «не сподівайтеся, що вона вилікується». Завантажте rescue ISO, щоб монтувати в режимі лише для читання і думати з тверезою головою.
• Визначте точний цільовий диск. «/dev/sda» — не особистість. Використовуйте серійні номери, WWN і стійкі ідентифікатори.
• Припускайте взаємодію шарів. Таблиці розділів, LVM, mdraid, LUKS, файлові системи, завантажувачі, fstab/initramfs — зміни можуть зачепити будь-який з них.

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

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

Це послідовність «орієнтації за 10 хвилин». Порядок важливий, бо він швидко звужує домени помилок.

По-перше: чи взагалі видно диск і розділи?

• З rescue-середовища: перелічіть блокові пристрої і таблиці розділів.
• Рішення: якщо таблицю розділів неможливо прочитати, спочатку ремонт GPT/MBR.

По-друге: чи знайдемо кореневу файлову систему і чи монтується вона в режимі лише для читання?

• Спробуйте змонтувати ймовірні кореневі розділи в режимі ro.
• Рішення: якщо монтаж не вдається, переключайтеся на ремонт файлової системи і перевірку зсунутих стартів/розмірів.

По-третє: якщо root монтується — чому система не завантажується?

• Перевірте /etc/fstab, UUID, збірку LVM/mdraid і конфігурацію завантажувача.
• Рішення: якщо UUID змінилися, виправляйте посилання й перебудовуйте initramfs/GRUB, а не файлову систему.

По-четверте: невідповідність UEFI vs BIOS?

• Перевірте, чи система завантажується в режимі UEFI і чи існує та змонтований EFI System Partition.
• Рішення: якщо ESP відсутній/пошкоджений/незмонтований — відновіть його і перевстановіть GRUB для EFI.

По-п’яте: переконайтеся, що «resize» не був насправді переміщенням

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

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

• Ліміт MBR у 2 TiB — це не «проблема Linux». Класичний MBR використовує 32-бітні лічильники секторів, що обмежує адресний простір при 512-байтових секторах.
• GPT зберігає дві копії свого заголовка й таблиці розділів: первинну на початку і резервну в кінці диска. Це врятує, коли «початок став дивним».
• UEFI ввів EFI System Partition (ESP) як першокласний елемент. Багато збоїв завантаження після resize фактично пов’язані з тим, що ESP не змонтований.
• GRUB2 став більш модульним, ніж старий GRUB. Така гнучкість — ще одна причина існування підказки «grub rescue>»: він не може знайти свої модулі або конфіг, тож чемно панікує.
• ext4 може рости онлайн у багатьох випадках, але зменшення досі вимагає роботи офлайн. Люди пам’ятають «grow — безпечно» і забувають «shrink — це ножовий бій».
• XFS свідомо не може зменшуватися (за дизайном). Якщо ви «зменшили розділ» під XFS, ви не зменшили XFS; ви просто вирізали під ним підлогу.
• LVM створювався для змін (PV/VG/LV resize), але це не звільняє вас від коректності таблиці розділів. Він просто додає ще один шар, який має бути правильним.
• Linux почав активно використовувати UUID для монтувань, щоб уникнути хитання імен пристроїв. Це чудово — поки resize/регенерація не змінять ідентифікатори і ваше fstab не перетвориться на історичну фантастику.

Цитата наостанок, бо інженерія надійності вчиться одному й тому самому десятиліттями. Репліка відома в контексті John Allspaw: «Інциденти виникають з нормально виконаної роботи в складних системах; звинувачення не виправляє систему.» (парафразована ідея)

Що насправді ламається під час зміни розміру

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

1) Зміни геометрії таблиці розділів

Якщо початок розділу змістився, усе, що було вище нього, зміщується. Файлові системи та LVM зберігають очікування щодо свого місця розташування. Змістивши початок, ви показуєте ОС на неправильний зсув на диску. Іноді дані все ще там; ви просто дивитесь не за тією адресою.

2) Метадані файлової системи більше не відповідають блочному пристрою

Для ext4 можна отримати систему, яка вважає, що має N блоків, а розділ тепер пропонує N-Δ. Монтажі провалюються, fsck жаліється, або гірше: монтажі проходять і записи потрапляють у порожнечу за новим кінцем.

Для XFS «зменшення під нею» дорівнює ризику корупції. XFS очікує, що блочний пристрій не стане меншим. Коли це відбувається, ви отримуєте помилки вводу/виводу і невдачі відтворення журналу.

3) Шляхи й ідентифікатори завантажувача змінюються

GRUB часто посилається на UUID файлової системи або шукає конкретні розділи. UEFI-записи вказують на EFI-бінарник на ESP. Якщо ESP змістився, був відформатований або не змонтований під час оновлень, система може завантажитися в порожнечу.

4) initramfs не може зібрати ваш стек зберігання

Якщо root знаходиться на LVM, mdraid або LUKS, раннє середовище завантаження має зібрати його. Зміни розміру можуть змінити порядок виявлення пристроїв, заплутати mdadm або інвалідизувати очікування crypttab. Ядро завантажується, а потім кидає вас в initramfs, бо не може знайти /dev/mapper/root.

Рунбук: 14 конкретних завдань з командами, виводами та рішеннями

Ці завдання передбачають Linux rescue-середовище. Команди записані так, ніби ви в консолі з правами root (через sudo або прямий root). Обережно замініть імена пристроїв.

Завдання 1: Перелічити диски і розділи (довіряй, але перевіряй)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,FSUUID,MOUNTPOINTS,MODEL,SERIAL
NAME        SIZE TYPE FSTYPE FSVER FSUUID                                 MOUNTPOINTS MODEL          SERIAL
sda        477G  disk                                                Samsung_SSD     S4X...
├─sda1     512M  part vfat   FAT32 1A2B-3C4D                              /boot/efi
├─sda2       1G  part ext4   1.0   2c1d...                                /boot
└─sda3   475.5G  part LVM2_member      hP0x...                             
  ├─vg0-root 80G lvm  ext4   1.0   9f7a...                                /
  └─vg0-var  50G lvm  xfs          4e2b...                                /var

Що це значить: Ви бачите диск, розділи, їхні файлові системи і чи присутній LVM.

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

Завдання 2: Підтвердити тип таблиці розділів і геометрію

cr0x@server:~$ sudo parted -s /dev/sda print
Model: Samsung SSD (scsi)
Disk /dev/sda: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32              boot, esp
 2      538MB   1612MB  1074MB  ext4
 3      1612MB  512GB   510GB

Що це значить: Межі start/end у зрозумілих одиницях; таблиця — GPT.

Рішення: Якщо ви очікували MBR, а бачите GPT (або навпаки), підтвердьте режим прошивки і як встановлено GRUB. Невідповідності викликають привидні збої при завантаженні.

Завдання 3: Отримати точні стартові сектори (єдині числа, що мають значення)

cr0x@server:~$ sudo sfdisk -d /dev/sda
label: gpt
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1000215214

/dev/sda1 : start=        2048, size=     1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
/dev/sda2 : start=     1050624, size=     2097152, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
/dev/sda3 : start=     3147776, size=  996?..., type=E6D6D379-F507-44C2-A23C-238F2A3DF928

Що це значить: Це справжні зміщення. Якщо під час resize випадково змістився стартовий сектор, цей вивід — ваше доказування.

Рішення: Якщо стартові сектори змінилися від відомо-правильних значень (із нотаток, бекапів, скриншотів, стану автоматизації), припиніть і сплануйте виправлення геометрії. Не запускайте fsck; ви можете фсck-нути неправильний зсув.

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

cr0x@server:~$ sudo sgdisk -v /dev/sda
Verifying disk /dev/sda
Problem: The secondary GPT header is not at the end of the disk.
Problem: The secondary partition table is not at the end of the disk.
No problems found. 0 free sectors (0 bytes) available in 0 segments.

Що це значить: Часте після змін розміру диска або невдалих операцій: резервна GPT не там, де має бути.

Рішення: Якщо sgdisk -v повідомляє про проблеми з розташуванням заголовка/таблиці, плануйте переміщення за допомогою sgdisk -e (обережно). Якщо повідомляє про CRC-помилки — пріоритетом буде відновлення GPT із резервного заголовка.

Завдання 5: Перемістити резервну GPT в кінець диска (відносно безпечний фікс для деяких попереджень)

cr0x@server:~$ sudo sgdisk -e /dev/sda
Relocating backup data structures to the end of the disk
The operation has completed successfully.

Що це значить: Резервні структури GPT переміщено в правильне кінцеве розташування диска.

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

Завдання 6: Пропробуйте підпис файлової системи (ми дивимось не на те?)

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda2 /dev/sda3
/dev/sda1: UUID="1A2B-3C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="..."
/dev/sda2: UUID="2c1d..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="..."
/dev/sda3: TYPE="LVM2_member" PARTUUID="..."

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

Рішення: Якщо root мав би бути ext4, а blkid каже «unknown», не форматуйтесь. Ви тут, щоб відновлювати, а не творити нові катастрофи.

Завдання 7: Зібрати mdraid, якщо є (поширено на серверах)

cr0x@server:~$ sudo mdadm --examine --scan
ARRAY /dev/md0 metadata=1.2 name=server:0 UUID=8b3c...

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

Рішення: Якщо масиви існують — зберіть їх перед роботою з LVM/файловою системою.

cr0x@server:~$ sudo mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.

Рішення: Якщо збірка зазнає невдачі з «device busy» або «wrong uuid», зупиніться й інспектуйте учасників окремо; не форсуйте збірку, якщо не впевнені, які дискi актуальні.

Завдання 8: Активувати LVM (якщо корінь на LV)

cr0x@server:~$ sudo pvscan
  PV /dev/sda3   VG vg0   lvm2 [475.50 GiB / 0    free]
  Total: 1 [475.50 GiB] / in use: 1 [475.50 GiB] / in no VG: 0 [0   ]

cr0x@server:~$ sudo vgscan
  Found volume group "vg0" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active

Що це значить: Метадані LVM читаються і LV активовані.

Рішення: Якщо pvscan не бачить PV, можливо стартовий сектор розділу змістився або PV-мітка була перезаписана. Спочатку розглядайте це як проблему з геометрією/зсувом, а не «LVM зламався».

Завдання 9: Спробуйте змонтувати root в режимі лише для читання (не поспішайте)

cr0x@server:~$ sudo mount -o ro /dev/vg0/root /mnt
cr0x@server:~$ ls /mnt
bin  boot  dev  etc  home  lib  lib64  opt  root  sbin  usr  var

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

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

Завдання 10: Валідувати fstab проти реальних UUID (класичний пост-resize збій)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=9f7a...  /      ext4  defaults  0 1
UUID=2c1d...  /boot  ext4  defaults  0 2
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Що це значить: fstab використовує UUID. Добре. Тепер переконайтеся, що вони збігаються з тим, що видає blkid.

Рішення: Якщо fstab посилається на UUID, яких більше немає, виправте fstab (і перебудуйте initramfs, якщо потрібно). Не «fsck-айте сильніше».

Завдання 11: Перевірити, чого очікує initramfs (root, crypt, md, lvm)

cr0x@server:~$ sudo grep -R "UUID=" -n /mnt/etc/default/grub /mnt/etc/crypttab /mnt/etc/fstab 2>/dev/null
/mnt/etc/fstab:1:UUID=9f7a...  /      ext4  defaults  0 1
/mnt/etc/fstab:2:UUID=2c1d...  /boot  ext4  defaults  0 2

Що це значить: Ви шукаєте конфігураційні місця, що часто ламаються після resize.

Рішення: Якщо crypttab посилається на старий UUID для контейнера LUKS, initramfs не розблокує корінь. Оновіть його і перебудуйте initramfs.

Завдання 12: Chroot правильно (щоб ваші виправлення вплинули на встановлену систему)

cr0x@server:~$ sudo mount --bind /dev  /mnt/dev
cr0x@server:~$ sudo mount --bind /proc /mnt/proc
cr0x@server:~$ sudo mount --bind /sys  /mnt/sys
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | head
/dev/mapper/vg0-root on / type ext4 (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

Що це значить: Ви тепер працюєте в контексті встановленої ОС.

Рішення: Якщо root змонтований у chroot в режимі ro і потрібно редагувати файли — перемонтуйте його в rw лише коли впевнені у цілісності файлової системи.

Завдання 13: Перебудувати initramfs (бо він кешує реальність зберігання)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-31-generic

Що це значить: Раннє завантажувальне зображення згенеровано з поточними UUID/модулями.

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

Завдання 14: Перевстановити GRUB і згенерувати конфіг (шляхи для BIOS і UEFI)

cr0x@server:~$ grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
Found initrd image: /boot/initrd.img-6.8.0-31-generic
done

Що це значить: Для BIOS-систем GRUB встановлюється в MBR/зону вбудовування диска. Потім конфіг знову згенеровано.

Рішення: Якщо ви насправді в UEFI, grub-install /dev/sda — не те рішення. Ви встановлюєте в ESP і переконайтеся, що вона змонтована в /boot/efi. Перед діями перевірте режим завантаження.

Стратегії «відкотити» які працюють у реальному житті

Ви не можете по-справжньому «відкотити» зміни розділу як git-коміт. Проте можна відновити геометрію і посилання метаданих до очікуваного стану системи. Часто цього достатньо, щоб система завантажилася.

Стратегія A: Відновити правильний стартовий сектор розділу (основна)

Якщо старт розділу змістився, ваша файловa система/LVM, ймовірно, ціла, але зсунуто. Виправлення — повернути стартовий сектор точно на місце. «Достатньо близько» тут не працює. На один сектор у бік — і все ще неправильно, просто з більшою впевненістю.

Як це робиться залежить від того, який інструмент це змінив. На практиці ви використовуєте parted або sfdisk, щоб відтворити запис розділу зі старим стартом і розміром, що принаймні покриває старий кінець файлової системи. Ви не форматували. Ви не створюєте нову файлову систему. Ви лише коригуєте запис таблиці.

Якщо ви не знаєте старого стартового сектора, перевірте:

• Старі тікети/зміни (іноді хтось вставляв вивід sfdisk -d).
• Моніторингові інвентарі або знімки CMDB.
• Бекапи /etc, які можуть містити логи інсталятора або скрипти розмітки.
• Резервний заголовок GPT (якщо первинний було зіпсовано) і інструменти відновлення.

Стратегія B: Виправити дрейф UUID (fstab/crypttab/grub)

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

Поширені кроки:

• Оновіть /etc/fstab, щоб відповідати blkid.
• Для зашифрованих коренів: оновіть /etc/crypttab, потім перебудуйте initramfs.
• Для mdraid: переконайтеся, що /etc/mdadm/mdadm.conf правильний, потім перебудуйте initramfs.
• Перегенеруйте конфіг GRUB, щоб він знайшов правильний корінь.

Стратегія C: Відновлення метаданих GPT (коли таблиця «valid-ish», але несумісна)

Резервний заголовок GPT часто рятує. Якщо sgdisk -v повідомляє про CRC mismatch або корупцію заголовка, часто можна відновити з резервного заголовка або перемістити його в новий кінець диска після розширення віртуального диска.

Працює добре, коли дані розділів цілі, а лише бухгалтерія GPT помилкова.

Стратегія D: Ремонт файлової системи (тільки після виправлення геометрії)

Якщо ви змінювали файлову систему і живлення впало під час операції, або ви неправильно встановили межі розділу — можливо, знадобиться fsck (ext4) або xfs_repair (XFS). Робіть це після підтвердження, що ви вказуєте на правильний зсув на диску і блочний пристрій має очікуваний розмір.

Ще один короткий жарт, бо ви його заслужили: Ніщо не пришвидшує «швидке розширення», як менеджер, що питає ETA.

Ремонт завантажувача: BIOS/MBR, UEFI і звичні пастки

Збої завантаження після змін розмітки часто — це проблеми завантажувача, замасковані під проблеми з диском. Трюк — відокремити «ядро не може знайти root» від «прошивка не може знайти завантажувач».

Знайте свій режим завантаження

З rescue-середовища перевірте, чи ISO завантажене в режимі UEFI. Якщо live середовище запущене в BIOS-режимі, а встановлена ОС очікує UEFI, ви все одно можете монтувати і виправляти — але будьте обережні з тим, куди встановлюєте GRUB.

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

Що це значить: Якщо виводить UEFI, то поточне середовище підтримує EFI-змінні і ви можете керувати NVRAM-записами.

Рішення: Якщо потрібно ремонтувати UEFI-завантаження — завантажте rescue ISO в UEFI-режимі. Інакше ви «успішно» перевстановите GRUB у місце, яке прошивка ніколи не використовує.

Перевірте EFI System Partition (ESP)

ESP має бути FAT32, зазвичай 100–512MB (іноді більша), з прапорцем esp. Якщо вона відсутня, зміщена або не змонтована в /boot/efi під час оновлень GRUB, ваш UEFI-запис може вказувати на файл, якого вже немає.

cr0x@server:~$ sudo lsblk -f | grep -E "vfat|/boot/efi"
sda1 vfat   FAT32 1A2B-3C4D                             /mnt/boot/efi

Рішення: Якщо ESP не змонтована — змонтуйте її і перезапустіть GRUB install/генерацію конфігу в chroot.

Шаблон перевстановлення GRUB для UEFI (всередині chroot)

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
Installing for x86_64-efi platform.
Installation finished. No error reported.

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
done

Що це значить: EFI-бінарник записано на ESP і конфіг GRUB згенеровано.

Рішення: Якщо прошивка все ще не завантажує — інспектуйте NVRAM-записи і розгляньте fallback-шлях \EFI\BOOT\BOOTX64.EFI залежно від політики платформи.

Шаблон перевстановлення GRUB для BIOS (всередині chroot)

Для BIOS-інсталяцій GRUB потребує простору для вбудовування (зазвичай у проміжку після MBR) або BIOS-boot розділу на GPT-дисках. Операції зі зміни розміру можуть випадково видалити цей проміжок або неправильно позначити BIOS boot розділ.

cr0x@server:~$ sudo parted -s /dev/sda print | grep -i "bios"
Partition Table: gpt

Рішення: Якщо це GPT+BIOS, переконайтеся, що у вас є маленький BIOS boot розділ (зазвичай 1–2MB) з прапорцем bios_grub. Без нього установка GRUB може «вдатися», але не завантажитися.

Ремонт і перевірка файлових систем (ext4, XFS)

ext4: перевірити, потім ремонтувати

ext4 пробачливий, але не плутайте «пробачливий» з «невразливим». Якщо кінець розділу встановлено меншим, ніж файловa система, ext4 може монтуватися в ro, відмовлятися монтуватися або показувати помилки відтворення журналу.

cr0x@server:~$ sudo e2fsck -f -n /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
/dev/vg0/root: clean, 412345/5242880 files, 8123456/20971520 blocks

Що це значить: -n — сухий запуск. «clean» — це те, чого ви хочете побачити.

Рішення: Якщо сухий запуск показує лише дрібні проблеми — плануйте реальний ремонт з -y у вікні технічного обслуговування. Якщо показує «bad magic number», швидше за все ви вказали не той пристрій/зсув.

cr0x@server:~$ sudo e2fsck -f -y /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg0/root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vg0/root: 412346/5242880 files, 8123460/20971520 blocks

Рішення: Якщо fsck модифікував файлову систему — запустіть його повторно, поки не повідомить, що все чисто. Потім змонтуйте в ro і перевірте ключові шляхи (/etc, /boot, дані додатків).

XFS: реалії ремонту

XFS може рости; він не зменшується. Якщо ви зменшили базовий блочний пристрій, ви могли обрізати живу метадані. Іноді можна відремонтувати; іноді потрібно відновлювати з бекапу.

cr0x@server:~$ sudo xfs_repair -n /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
Phase 3 - for each AG...
No modify flag set, skipping filesystem flush and exiting.

Що це значить: Режим сухого запуску; він повідомить, чи спробує ремонт щось змінити.

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

LVM, RAID і шифрування: багатошаровий кейк болю

Сучасні системи складають абстракції, бо це робить життя кращим у 99% випадків. Під час відновлення ви платите 1% податку з відсотками. Ключ — відбудувати стек знизу вгору: диск → розділ → mdraid → LUKS → LVM → файлова система.

Якщо ви змінили розділ, що містить LVM PV

Кращий випадок: розділ зріс, PV ні — тоді потрібно лише pvresize. Гірший випадок: розділ зменшили або змістили і мітка PV не там, де LVM очікує.

cr0x@server:~$ sudo pvs -o+pv_used,pv_size,vg_name
  PV         VG  Fmt  Attr PSize    PUsed    VG
  /dev/sda3  vg0 lvm2 a--  <475.50g 130.00g  vg0

Що це значить: LVM бачить PV і його розмір. Якщо розмір PV менший за розділ і ви планували його збільшити — це нормальний пост-resize крок.

Рішення: Якщо PV видимий і ви тільки що розширили розділ — виконайте pvresize /dev/sda3. Якщо PV не видно — не створюйте новий PV. Це перезапише метадані.

cr0x@server:~$ sudo pvresize /dev/sda3
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Якщо mdraid не збирається після зміни розміру

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

cr0x@server:~$ sudo cat /proc/mdstat
Personalities : [raid1]
md0 : inactive sdb1[1] sda1[0]
      976630336 blocks super 1.2

unused devices: <none>

Що це значить: Масив неактивний. Це не «гаразд». Це «root ось-ось зникне».

Рішення: Перевірте кожного учасника з mdadm --examine, порівняйте лічильники подій і переконайтеся, що розміри розділів узгоджені перед примусовою збіркою.

Якщо задіяний LUKS

Якщо корінь зашифровано, initramfs повинен його розблокувати. Resize може не вплинути на сам LUKS, але може змінити UUID або шлях пристрою, що вказаний у crypttab, або відображення розділу.

cr0x@server:~$ sudo cryptsetup luksDump /dev/sda3 | head
LUKS header information for /dev/sda3
Version:        2
UUID:           7c0b...

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

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

1) Симптом: підказка «grub rescue>» після перезавантаження

Корінь проблеми: GRUB не може знайти свої модулі/конфіг через зміну ID розділів, переміщення /boot або зміни UUID файлової системи.

Виправлення: Завантажте rescue ISO, змонтуйте root і boot/ESP, chroot, виконайте grub-install (відповідно до BIOS/UEFI), update-grub, перебудуйте initramfs якщо стек зберігання змінився.

2) Симптом: падіння в initramfs з «cannot find UUID=…»

Корінь проблеми: fstab/crypttab/initramfs очікує старий UUID, або пристрій не зібраний (mdraid/LVM не активовано) на ранньому етапі завантаження.

Виправлення: У rescue порівняйте вивід blkid з /etc/fstab і /etc/crypttab. Оновіть і виконайте update-initramfs -u -k all.

3) Симптом: файлова система монтується, але /var або /home відсутні

Корінь проблеми: Логічні томи існують, але не активовані, або записи fstab змінилися і точки монтування мовчки не змонтувались.

Виправлення: vgchange -ay, перевірте LVs з lvs, подивіться journalctl після завантаження або змонтуйте вручну, щоб побачити реальну помилку.

4) Симптом: ext4 «bad magic number» під час fsck

Корінь проблеми: Ви запускаєте fsck на неправильному пристрої (не той розділ, неправильний зсув через переміщений старт) або суперблок пошкоджено.

Виправлення: Підтвердіть з blkid і стартові сектора розділів. Якщо геометрія правильна — спробуйте альтернативні суперблоки (mke2fs -n для переліку). Якщо геометрія неправильна — виправте таблицю розділів спочатку.

5) Симптом: помилки відтворення журналу XFS після зміни розміру

Корінь проблеми: Базовий блочний пристрій зменшився або був обрізаний; XFS бачить невідповідність геометрії.

Виправлення: Розширте розділ/LV назад до попереднього розміру, якщо можливо, а потім запустіть xfs_repair. Якщо було справжнє обрізання, плануйте відновлення з бекапу.

6) Симптом: система завантажується, але kernel panic при монтуванні root

Корінь проблеми: initramfs не має потрібних драйверів/модулів для стеку зберігання, або неправильний параметр root= в GRUB.

Виправлення: Chroot і перебудуйте initramfs; регенеруйте конфіг GRUB; переконайтеся, що потрібні модулі включені.

7) Симптом: «no bootable device» на екрані прошивки

Корінь проблеми: UEFI NVRAM вказує на відсутній EFI-бінарник; ESP пошкоджено; або BIOS-завантажувальний сектор перезаписано.

Виправлення: Змонтуйте ESP, перевстановіть GRUB EFI-ціль, переконайтеся, що /boot/efi правильний; за потреби створіть fallback EFI-путь. Для BIOS — перевстановіть GRUB на правильний диск.

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

Чек-лист A: Обмежити зону ураження

1. Зробіть снапшот на рівні гіпервізора/шару зберігання, якщо віртуалізовано.
2. Якщо фізично — розгляньте можливість знімку диска перед записами ремонтів.
3. Завантажте rescue ISO в тому ж режимі завантаження (UEFI vs BIOS), що й встановлена система.
4. Визначте правильний диск за моделлю/серійним номером, а не лише за /dev/sdX.

Чек-лист B: Тріаж до правильного домену помилки

1. Запустіть lsblk і parted print, щоб побачити, чи існують розділи і чи виглядають вони правдоподібно.
2. Запустіть sfdisk -d, щоб зафіксувати стартові сектори; порівняйте з відомими-правильними, якщо є.
3. Запустіть blkid, щоб підтвердити наявність підписів файлових систем на очікуваних розділах.
4. Зберіть mdraid (mdadm --assemble --scan) і активуйте LVM (vgchange -ay) якщо потрібно.
5. Спробуйте змонтувати root в режимі ro.

Чек-лист C: Відновлення ланцюга завантаження (шлях «монтується, але не завантажується»)

1. Змонтуйте root в /mnt.
2. Змонтуйте /boot і /boot/efi, якщо це окремі розділи.
3. Перевірте UUID в /mnt/etc/fstab і /mnt/etc/crypttab, чи співпадають вони з blkid.
4. Bind-монтуйте /dev, /proc, /sys, потім chroot.
5. Перебудуйте initramfs.
6. Перевстановіть GRUB відповідно до режиму завантаження; регенеруйте конфіг GRUB.
7. Вийдіть з chroot, відмонтуйте, перезавантажтеся.

Чек-лист D: Ремонт файлової системи (шлях «не монтується»)

1. Підтвердіть правильні стартові сектори розділу перед fsck/xfs_repair.
2. Для ext4: спочатку e2fsck -f -n; потім реальний ремонт за потреби.
3. Для XFS: xfs_repair -n спочатку; ніколи не намагайтесь «зменшити назад». Спочатку збільшіть базовий пристрій, якщо є невідповідність геометрії.
4. Після ремонту: змонтуйте в ro, перевірте критичні дані, потім переходьте до відновлення завантаження.

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

Інцидент через хибне припущення: «це просто /dev/sda»

Середня SaaS-компанія мала стандартний плейбук: коли диск кореня вузла підтискав, розширити віртуальний диск, виконати зростання розділу, потім розширити файлову систему. Рутинно. Поки не стало не рутинно.

Інженер по on-call діяв за м’язовою пам’яттю і виконав resize проти /dev/sda. У тому кластері гіпервізора порядок udev не був стабільний: диск ОС був /dev/sdb, а /dev/sda — диск даних для логів. Операція «працювала». Вона навіть виводила переконливі повідомлення. Ніхто не любить ці повідомлення більше, ніж той, хто щойно змінив не той диск.

Перезавантаження було катастрофою в тонкому вигляді. Вузол завантажився, але логовий том виявився неузгодженим; файлова система змонтувалася з помилками; додаток стартував; потім впав під навантаженням запису. Алерти збивали з пантелику: здавалося, що проблема в релізі додатка. Насправді це була геометрія зберігання.

Відновлення зайняло більше часу, ніж потрібно, бо команда ганялася за симптомами не в тій площині. Коли хтось порівняв lsblk -o MODEL,SERIAL з мапою дисків VM — все стало на свої місця: вони змінили не той пристрій, і імена пристроїв були ненадійними ідентифікаторами.

Виправили нудно: від’єднали неправильно змінений диск, зробили снапшот, відремонтували геометрію розділів за відомо-правильними стартовими секторами з інвентарю попереднього дня, потім провели fsck. Диск ОС потім правильно розширили, використовуючи стабільні шляхи /dev/disk/by-id у скриптах.

Оптимізація, що відкинула назад: зменшили «вільне місце», щоб зекономити

Команда підприємства захотіла скоротити витрати в хмарі. Хтось помітив, що фліт билд-серверів має 200GB диски, а використовують тільки 40GB. Легке рішення: зменшити томи, зекономити. План схвалили, бо це виглядало як прибирання, а не операція.

Підступ був у XFS на /var, де лежали кеші билдiв і шари контейнерів. Скрипт зменшив розділ спочатку, планувавши потім зменшити файлову систему. Останнього кроку для XFS не існує. Скрипт цього не знав; він просто вмів викликати parted і «потім зробити щось з файловою системою».

Більшість серверів не впали відразу. Вони почали давати збої пізніше, під навантаженням, коли XFS намагався алокувати блоки поряд з колишнім кінцем пристрою. Це спричинило помилки I/O, проблеми журналу і врешті вузли, що завантажувалися в emergency mode, бо systemd не міг змонтувати /var. Інциденти підходили як повільна теча — найгірший тип течі для уваги організації.

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

Урок: зменшення — це не інверсія зростання. Ані операційно, ані математично, ані емоційно.

Нудна, але правильна практика, що врятувала день: знімати карту розділів перед будь-якими змінами

Команда фінансових послуг мала нудкучу вимогу перед змінами: перед будь-якими роботами з диском/розділом знімати sfdisk -d і зберігати його з записом про зміну. Інженери скаржилися. Це виглядало як бюрократія, що вдає із себе інженерію.

Потім VM бази даних продакшену отримала розширення диску і зростання розділу. Юніор інженер використав GUI-інструмент, який випадково зсунув стартовий сектор LVM-розділу. Це була одна помилка, але вона зсунулась PV-офсет. Після перезавантаження LVM не знайшов VG. База була вниз.

Замість гадання on-call витягнув попередній sfdisk -d з тікета, порівняв з поточною геометрією і відтворив запис розділу з оригінальним стартовим сектором. LVM миттєво впізнав PV, VG активувався і root змонтувався ніби нічого не сталося.

Решта ремонту була рутинною: перебудували initramfs, щоби раннє завантаження знало, як зібрати стек; переставили GRUB на всяк випадок; перезавантажилися. Загальний простій міряли в «люди були роздратовані», а не в «скликали керівництво».

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

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

1) Чи можу я «відкотити» зміну розділу?

Не однією кнопкою. Часто можна відновити попередню геометрію розділу (особливо стартовий сектор) і виправити дрейф метаданих/посилань. Для багатьох інцидентів це практичний еквівалент Undo.

2) Чи варто запускати fsck негайно?

Ні. Спочатку підтвердьте, що ви таргетуєте правильний пристрій з правильним зсувом. Якщо старт розділу змістився, fsck у кращому випадку зазнає невдачі, а в гіршому — зробить ще гірше.

3) Чому він завантажувався до перезавантаження, а потім впав?

Бо запущене ядро мало старі мапи в пам’яті і працювало з уже відкритими блоковими пристроями. Перезавантаження змушує систему заново виявляти світ по метаданих на диску — там і сталося пошкодження реальності.

4) Якщо blkid показує правильні UUID, чому не монтується?

Наявність UUID не гарантує консистентність файлової системи. Суперблок може бути читаємим, але журнал або алокаційні метадані — неконсистентні. Змонтуйте в ro; подивіться dmesg на помилки I/O; використайте відповідний інструмент ремонту.

5) Як швидко визначити UEFI чи BIOS?

В Linux: перевірте, чи існує /sys/firmware/efi. Також шукайте ESP (vfat, прапорець esp). Підготуйте свій ремонт GRUB відповідно до режиму.

6) Мій root на LVM. Що ремонтувати спочатку: розділи чи LVM?

Спочатку розділи. LVM-метадані знаходяться за фіксованими зсувами всередині PV. Якщо запис розділу вказує на інший стартовий сектор, LVM шукатиме не там і скаже, що PV відсутній.

7) Чи безпечний sgdisk -e?

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

8) Чому має значення зміна розміру ESP?

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

9) Що робити, якщо я зменшив розділ менше за дані?

Якщо ви обрізали живі дані файлової системи, повного відновлення може не бути. Найкраще — негайно розширити розділ/LV назад до попереднього розміру (якщо можливо) і потім ремонтувати. Якщо дані за новим кінцем зникли — відновлюйте з бекапу.

10) Як запобігти цьому наступного разу?

Фіксуйте карти розділів перед змінами, використовуйте стабільні ідентифікатори (/dev/disk/by-id) у скриптах і рунбуках, репетируйте на клонax і розділяйте «розширити диск» від «змінити старт розділу» з явними запобіжниками в інструментах.

Висновок: кроки, що запобігають повторенню

Якщо ви тут, бо resize вбив завантаження, ваша задача — зупинити кровотечу, відновити геометрію або посилання і повернути змонтований root. Найшвидший шлях рідко «відремонтувати все». Це «відремонтувати той шар, що бреше».

Зробіть наступне після повернення онлайн:

• Збережіть пост-фактум правду: збережіть в записі інциденту виводи lsblk, sfdisk -d, blkid і деталі режиму завантаження.
• Автоматизуйте передзміни снапшоти: снапшот VM або снапшот на рівні сховища перед операціями з розділами. Зробіть це політикою, а не героїкою.
• Стандартизуйте ідентифікацію пристроїв: віддавайте перевагу /dev/disk/by-id в скриптах і рунбуках.
• Забороніть випадкове зменшення: розглядайте операції shrink як проєкти міграції, а не як «прибирання». Особливо з XFS.
• Тестуйте перезавантаження: після будь-якої зміни зберігання/завантаження заплануйте контрольоване перезавантаження, поки у вас ще є контекст і час.

Розділи не страшні. Небезпечні — неплановані записи. Тримайте руки спокійними, зсуви точними, а ремонти нудними.