Встановлення Raspberry Pi OS: правильна робота з SD-картою (і як уникнути корупції)

February 26, 2026 • February 26, 2026 • Читання: 5 хв • Views: 0

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

Ніщо так не принижує впевненого інженера, як Raspberry Pi, який «працював учора», а тепер завантажується в файлову систему тільки для читання і має емоційний діапазон цеглини.
Причина часто не в Linux, не в вашому застосунку і не в фазі місяця. Це ваш робочий процес зі SD-картою: вибір носія, запис, верифікація і щоденна боротьба з відключенням живлення та маленькими шаруватими прошивками контролера.

Це тверезий, орієнтований на експлуатацію підхід до інсталяції Raspberry Pi OS на SD-карту, щоб вона лишалася працездатною. Ми зробимо нудні перевірки, які запобігають відмовам,
поговоримо, чому «швидкі» SD-карти повільно руйнуються, і складемо план діагностики, коли Pi зависає на екранчику з райдугою за п’ять хвилин до демо.

Що насправді викликає пошкодження SD-карти на Pi

SD-карти — це не «маленькі SSD». Це маленькі флеш-пристрої з дуже різними контролерами, непослідовною прошивкою, обмеженими запасними блоками і шаром трансляції, який ви не можете налаштувати.
Коли ви «псували» файлову систему на Pi, самою лиходійкою зазвичай не є файловa система. Вона — посланець. Послання таке: «запис було перервано, або носій збрехав».

Три найпоширеніші механізми корупції

Раптове відключення живлення під час запису метаданих. ext4 витривалий, але він не може віджурнелити те, що ніколи не вийшло з кешу контролера.
Pi із сумнівним блоком живлення або стрибком навантаження фактично практикує хаос-інженеринг без заявки.
Зношування носія + слабкі контролери. Дешеві карти «поступово виходять з ладу» тільки в рекламних текстах. Насправді вони можуть почати повертати I/O помилки,
або мовчки ремапити блоки, поки продуктивність не зруйнується, після чого карта стане лише для читання або взагалі зникне.
Висока ампліфікація записів від «звичайної поведінки Linux». Логи, оновлення пакетів, кеші браузера, swap, телеметрія та бази даних.
Pi за замовчуванням не лагідний; він просто маленький.

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

Жарт №1: SD-карта як підрядник: вона може бути швидкою, дешевою або надійною — виберіть дві, і інколи отримаєте лише одну.

Цікаві факти та трохи історії (що впливає на ваш вибір)

Вам не потрібна ностальгія, щоб запускати Pi, але кілька історичних деталей пояснюють, чому сучасні інсталяції Raspberry Pi OS поводяться саме так.

SD Association запустила SD у 1999 році. Це старіше за багато «cloud-native» архітектур, і екосистема досі несе спадщину обмежень.
Wear leveling залежить від контролера. Дві «однакові» 32 GB карти можуть поводитися по-різному, бо прошивка контролера вирішує, як ремапити і кешувати записи.
Клас швидкості SD був розроблений для послідовних відеозаписів. Це не ваше навантаження. Завантаження Linux — це багато малих випадкових читань плюс спалахи записів метаданих.
Application Performance Classes (A1/A2) з’явилися для випадкового I/O. A1/A2 ближчі до того, що потрібно Pi, але вони не дають гарантій.
Raspberry Pi спочатку покладався на SD через дешевизну й доступність. Платформа виросла з знімної флеш-пам’яті як основного сховища, тому багато проєктів досі це передбачають.
Журналювання файлових систем стало нормою в Linux для певної причини. ext4 журнал зменшує біль від відновлення після краху, але не скасовує поганого живлення або поганого носія.
Сучасні моделі Pi підтримують USB-boot. Це не туманна деталь: це ваше рятівне вікно від крихкості SD, коли ви «потрібно працювати рік».
Дешева флеш-пам’ять часто виходить у режим лише для читання. Це захисна поведінка контролера, коли він більше не може гарантувати записи.

Вибір правильної microSD карти (витривалість, A-рейтинг та хиба рекламних слоганів)

Купівля SD-карти схожа на найм на роль відповідальності за надійність, маючи тільки резюме. Вендори скажуть, що вона «швидка», «преміум» і «для ігор».
Жодне з цих слів не означає «витримає базу даних і journald 18 місяців».

На що звертати пріоритетно

Клас витривалості (High/Max Endurance). Це важливо при постійних дрібних записах: логи, метрики, SQLite, оновлення пакетів.
Endurance-карти створені для відеореєстраторів та CCTV: нудні навантаження, безперервні записи, довге час роботи. Це — ваш випадок.
Запас місця по ємності. Більші карти часто поводяться краще, бо більше запасних блоків для wear leveling.
Також ext4 при майже повному кореневому розділі гірше працює і гірше відновлюється.
Репутація постачальника. Підробки поширені. Якщо ціна підозріло низька, вважайте карту брехливою, доки не доведете протилежне.
A1/A2 рейтинг (з реалістичним підходом). A1 — гідна базова опція. A2 може бути швидшим, але деякі хости не використовують повністю його можливості, а деякі карти дивно поводяться під тривалим змішаним I/O.

На що не потрібно орієнтуватися (якщо ви не любите налагодження)

Пікові послідовні MB/s. Ваш Pi завантажується з багатьма маленькими читаннями і робить багато малих записів. «170 MB/s» на коробці — це переважно театральність.
Найменша ціна за ГБ. Ви не будуєте холодний архів. Ви будуєте маленький сервер.
Дуже мала ємність. 8 GB карти все ще існують. Так само як пейджери. Жодне з цього не обіцяє хорошого досвіду.

Правило великого пальця — рекомендації

Для «іграшкових» проєктів: пристойна брендова карта 32–64 GB з A1, куплена у надійного продавця, підходить.
Для «це запускає сервіс»: купуйте endurance, 64–128 GB, і закладайте заміну у бюджет як витратний матеріал (бо так воно і є).
Для «це важливо»: використовуйте USB SSD boot, якщо ваш Pi підтримує. SD-карти — для зручності, а не для витрат на інциденти.

Реальність живлення та вводу/виводу: ваш Pi — це система збереження

Пошкодження SD часто маскується під проблему живлення. Pi не має акумуляторного кешу. Контролер SD може мати внутрішний кеш,
але ви не контролюєте його поведінку по скиданню. Коли напруга просідає, записи перериваються. Іноді ви помічаєте це відразу. Іноді корупція розвивається повільно, як цвіль.

Підводні камені живлення, які виглядають як «дивна поведінка Linux»

Недостатня напруга під навантаженням. USB-пристрої, спалахи Wi‑Fi, піки CPU, модулі камери. Pi може коротко «brown out» без драматичного краху.
Слабкі кабелі. Хороший блок живлення з поганим кабелем — все одно поганий блок живлення.
Зворотне живлення та сумнівні хаби. Якщо ваш USB-хаб робить підозрілі речі, ваше сховище теж робитиме підозрілі речі.

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

Запис Raspberry Pi OS як треба (і верифікація)

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

Думка, що має вагу

Користуйтеся Raspberry Pi Imager, коли вам потрібен найпростіший шлях із здоровим набором параметрів і вбудованою верифікацією.
Використовуйте raw imaging (dd) тільки якщо ви також верифікуєте і завжди правильно ідентифікуєте пристрої навіть на навантаженій робочій станції.
Завжди перевіряйте те, що записали за допомогою контрольних сум або побайтового порівняння. «Записалося успішно» — це не верифікація; це відчуття.

І ще: якщо ви записуєте з Linux і не знаєте, до чого вказує /dev/sdX, зупиніться. Так ви перетворюєте «встановити Raspberry Pi OS» на «чому мій ноутбук більше не завантажується».

Жорстке перше завантаження: зменшення записів, підвищення виживання

Свіжа інсталяція Raspberry Pi OS завантажується добре майже на всьому. Проблема проявляється через тижні: apt updates, логи, swap, кеші браузера та ентузіастичне логування вашого застосунку.
Жорсткість — це коли ви вирішуєте, чи цей Pi — іграшка, чи пристрій.

Ходи з великим впливом для зменшення записів

Перемістіть тимчасові логи в RAM (або зменште persistence для journald).
Вимкніть swap на SD якщо у вас достатньо RAM, або перемістіть swap на SSD.
Дійте свідомо стосовно баз даних. SQLite підходить, але налаштуйте його і уникайте постійних fsync-штурмів, якщо вони не потрібні.
Зберігайте вільне місце. Намагайтеся мати принаймні 20–30% вільного місця на кореневому розділі для продуктивності і поведінки wear leveling.

Парафразований вислів: «Усе ламається; завдання — спроєктувати так, щоб відмови були життєздатними і відновлення було нудним.» — John Allspaw (парафраз)

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

Це реальні завдання, які ви можете виконати з Linux-робочої станції (для запису) і з Pi (для валідації та діагностики).
Кожне містить, що означає вивід і яке рішення зробити. Остання частина — що відрізняє «команди» від «операцій».

Завдання 1: Коректно ідентифікуйте пристрій SD-карти (робоча станція)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,HOTPLUG,MOUNTPOINTS
NAME      SIZE MODEL            SERIAL        TRAN HOTPLUG MOUNTPOINTS
nvme0n1  953G Samsung SSD 980   S64...        nvme       0 /
sda      931G WDC WD10...       WD-...        usb        0 /media/cr0x/backup
sdb     59.5G USB SD Reader     000000000000 usb        1 /media/cr0x/boot
                                                /media/cr0x/rootfs

Значення: sdb — це знімний SD-рідер (HOTPLUG=1) і в нього змонтовані розділи.
Рішення: Ви відмонтуєте і запишете на /dev/sdb, а не на розділ на кшталт /dev/sdb1, і звісно не на ваш диск ОС.

Завдання 2: Відмонтуйте всі розділи SD перед записом (робоча станція)

cr0x@server:~$ sudo umount /dev/sdb1 /dev/sdb2
umount: /dev/sdb1: not mounted.
umount: /dev/sdb2: not mounted.

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

Завдання 3: Стерти старі підписи таблиці розділів (робоча станція)

cr0x@server:~$ sudo wipefs -a /dev/sdb
/dev/sdb: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdb: 8 bytes were erased at offset 0x00000438 (ext4): 53 ef

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

Завдання 4: Запишіть образ Raspberry Pi OS за допомогою dd і покажіть прогрес (робоча станція)

cr0x@server:~$ sudo dd if=2025-01-15-raspios-bookworm-arm64.img of=/dev/sdb bs=4M conv=fsync status=progress
1610612736 bytes (1.6 GB, 1.5 GiB) copied, 19 s, 84.8 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 53 s, 81.1 MB/s
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 66 s, 81.3 MB/s
1280+0 records in
1280+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 66.1386 s, 81.2 MB/s

Значення: Образ записано; conv=fsync примушує flush наприкінці, що зменшує помилки «вимкнув раніше».
Рішення: Не виймайте карту ще; вам потрібно верифікувати і впевнитися, що ядро устаканилося.

Завдання 5: Примусити ОС скидати кеші диска (робоча станція)

cr0x@server:~$ sync

Значення: Запит на скидання кешів.
Рішення: Після запису завжди виконуйте sync. Це дешево і уникає класичного «я витягнув карту відразу після dd».

Завдання 6: Перечитати таблицю розділів і підтвердити, що розділи з’явилися (робоча станція)

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk /dev/sdb
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb      8:16   1 59.5G  0 disk
├─sdb1   8:17   1  512M  0 part
└─sdb2   8:18   1  5.0G  0 part

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

Завдання 7: Верифікувати образ шляхом побайтового порівняння (робоча станція)

cr0x@server:~$ sudo cmp -n 5368709120 2025-01-15-raspios-bookworm-arm64.img /dev/sdb

Значення: Відсутність виводу означає, що перші 5,368,709,120 байтів збігаються точно (розмір образу).
Рішення: Якщо cmp виявить відмінності, не завантажуйте Pi і «подивимось що станеться». Перезапишіть, спробуйте інший рідер і підозрівайте карту.

Завдання 8: На першому завантаженні підтвердити події недовантаження (Pi)

cr0x@server:~$ vcgencmd get_throttled
throttled=0x0

Значення: 0x0 вказує, що з моменту завантаження немає прапорів троттлінгу/недовантаження.
Рішення: Якщо бачите ненуль (поширене: 0x50000 варіанти), виправте живлення перед тим, як звинувачувати файлову систему. Замініть PSU/кабель, зменшіть периферію або використайте підсилений хаб.

Завдання 9: Перевірити журнали ядра на I/O помилки SD (Pi)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mmc|I/O error|ext4|buffer I/O|blk_update_request' | tail -n 30
[Mon Feb  5 10:14:28 2026] mmc0: new high speed SDHC card at address aaaa
[Mon Feb  5 10:14:29 2026] mmcblk0: mmc0:aaaa SU64G 59.5 GiB
[Mon Feb  5 10:14:30 2026] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: none.

Значення: Нормальне виявлення і монтування.
Рішення: Якщо бачите повторювані I/O error або mmc0: Timeout waiting for hardware interrupt, вважайте карту підозрілою і плануйте міграцію.

Завдання 10: Підтвердити кореневу файлову систему та параметри монтування (Pi)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/mmcblk0p2 / ext4 rw,relatime

Значення: Корінь на mmcblk0p2, ext4, змонтовано для читання-запису.
Рішення: Якщо воно ro, ви в режимі контролю шкоди: перевірте fs помилки, живлення і стан SD перед перезапуском сервісів, що пишуть.

Завдання 11: Перевірити стан файлової системи і останні помилки (Pi)

cr0x@server:~$ sudo tune2fs -l /dev/mmcblk0p2 | egrep -i 'Filesystem state|Errors behavior|Last error|Last mount time|Last checked'
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Mon Feb  5 10:14:30 2026
Last checked:             Mon Feb  5 10:10:02 2026

Значення: ext4 вважає файлову систему чистою.
Рішення: Якщо стан не clean, заплануйте контрольний fsck з режиму обслуговування (або з іншої системи), а не «надіятися, що journaling усе вирішить».

Завдання 12: Виміряти продуктивність SD швидким тестом випадкових читань (Pi)

cr0x@server:~$ sudo apt-get update -y
Hit:1 http://deb.debian.org/debian bookworm InRelease
Reading package lists... Done
cr0x@server:~$ sudo apt-get install -y fio
Reading package lists... Done
The following NEW packages will be installed:
  fio
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
cr0x@server:~$ fio --name=randread --filename=/tmp/fio.test --size=256M --rw=randread --bs=4k --iodepth=16 --numjobs=1 --direct=1 --runtime=30 --time_based
randread: (groupid=0, jobs=1): err= 0: pid=2123: Mon Feb  5 10:23:01 2026
  read: IOPS=1450, BW=5664KiB/s (5800kB/s)(166MiB/30001msec)

Значення: ~1450 IOPS для 4k випадкових читань — непогано для багатьох карт; деякі будуть значно гірші.
Рішення: Якщо бачите двозначні IOPS або крихітну пропускну здатність, очікуйте повільних завантажень і тайм-аутів під навантаженням. Замініть карту або перейдіть на SSD.

Завдання 13: Перевірити агресивне логування та постійні записy journald (Pi)

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.

Значення: Journald зайняв півгігабайта.
Рішення: На SD обмежте це. Якщо Pi — кіоск або сенсор, вам навряд чи потрібні необмежені постійні логи.

Завдання 14: Обмежити збереження journald щоб зменшити знос SD (Pi)

cr0x@server:~$ sudo sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=64M/' /etc/systemd/journald.conf
cr0x@server:~$ sudo systemctl restart systemd-journald
cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.

Значення: Логи тепер обмежені 64 MB.
Рішення: Якщо потрібне довше збереження — вивозьте логи кудись ще. SD не ваша SIEM.

Завдання 15: Підтвердити використання swap і вимкнути swap на SD якщо доречно (Pi)

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/var/swap file  512M   0B   -2
cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.2Gi       5.8Gi        92Mi       0.9Gi       6.3Gi
Swap:          512Mi          0B       512Mi

Значення: Swap існує, але не використовується; у вас достатньо RAM.
Рішення: Вимкніть його, щоб уникнути зносу і стрибків латентності. Якщо у вас мало пам’яті — перенесіть swap на SSD або усвідомлено прийміть компроміс.

Завдання 16: Вимкнути swap (Pi)

cr0x@server:~$ sudo dphys-swapfile swapoff
swapon: /var/swap: swapoff failed: Invalid argument
cr0x@server:~$ sudo swapoff -a
cr0x@server:~$ sudo systemctl disable --now dphys-swapfile
Removed "/etc/systemd/system/multi-user.target.wants/dphys-swapfile.service".

Значення: Swap вимкнено і сервіс відключено.
Рішення: Слідкуйте за пам’яттю. Якщо з’являться OOM kills — ви прийняли неправильне рішення для цього навантаження; знову ввімкніть swap на кращому носії.

Завдання 17: Побачити файлову систему, що перемонтована в режимі лише для читання (Pi)

cr0x@server:~$ dmesg -T | tail -n 20
[Mon Feb  5 11:02:41 2026] EXT4-fs error (device mmcblk0p2): ext4_journal_check_start:83: Detected aborted journal
[Mon Feb  5 11:02:41 2026] EXT4-fs (mmcblk0p2): Remounting filesystem read-only

Значення: ext4 виявив проблеми з журналом і захистився, перемонтувавши файлову систему лише для читання.
Рішення: Зупиніть сервіси, що активно пишуть, захопіть логи і плануйте контрольний fsck або відновлення. Продовження роботи перетворить «відновлюване» на «нез’ясоване».

Жарт №2: SD-карта не «випала випадково». Вона прочитала вашу ціль по аптайму і вирішила вжити насильство.

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

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

По-перше: живлення і недовантаження (найшвидше для перевірки, найпоширеніше)

Запустіть vcgencmd get_throttled. Якщо не нуль — виправте живлення перш ніж робити щось інше.
Перевірте dmesg -T | grep -i voltage на попередження про недовантаження (не завжди присутні на всіх збірках).
Рішення: поміняйте PSU і кабель перш ніж міняти SD карти. Проблеми з живленням можуть пошкодити навіть нову карту за декілька годин.

По-друге: помилки сховища (I/O таймаути, перемонтування, режим only-read)

Запустіть dmesg -T | egrep -i 'mmc|I/O error|timeout|ext4'.
Запустіть findmnt -no OPTIONS /, щоб побачити, чи ви ro.
Рішення: якщо бачите mmc таймаути або ext4 aborts — припиніть трактувати це як «програмну» проблему. Плануйте реімідж або міграцію.

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

Міряйте за допомогою fio (випадкове читання/запис, невеликий датасет).
Перевірте найбільших «писаків»: sudo iotop (якщо встановлено), або використайте sudo journalctl --disk-usage та логи застосунків.
Рішення: якщо випадковий I/O жахливо повільний — замініть карту або перейдіть на SSD; ви не зможете відтюнити контролер у кращу сторону.

По-четверте: цілісність файлової системи (тільки після перевірки живлення і апаратної частини)

Перевірте стан ext4 за допомогою tune2fs -l.
Якщо треба ремонтувати: робіть це офлайн або з режиму відновлення коли можливо, а не коли система напівзапущена.
Рішення: якщо корупція повторюється — перебудуйте систему і усуньте первинну проблему (живлення, носій, навантаження на запис). Повторні fsck — це не стратегія.

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

1) Симптом: «Файлова система лише для читання» після перезавантаження

Корінна причина: журнал ext4 був перерваний через I/O помилки або раптове відключення живлення; ядро перемонтувало корінь в ro щоб уникнути подальшої шкоди.
Виправлення: Перегляньте dmesg на помилки ext4/mmc; виправте живлення; запустіть fsck в оффлайн-режимі; замініть SD карту, якщо є I/O помилки.

2) Симптом: Pi інколи завантажується, інколи зависає

Корінна причина: поганий контакт SD, підроблена карта або граничне живлення, що викликає таймінгові помилки під час ініціалізації SD.
Виправлення: Спробуйте іншу карту і відомий робочий рідер; зменшіть периферію; використайте офіційний PSU/кабель; перевірте прапори недовантаження.

3) Симптом: «Kernel panic» або «VFS: unable to mount root fs»

Корінна причина: пошкоджений кореневий розділ, невірний образ (наприклад 32-bit vs 64-bit — нині рідше), або помилки читання SD.
Виправлення: Перезапишіть і верифікуйте через cmp; перевірте sha256sum якщо маєте відому хеш-суму; замініть карту, якщо верифікація не проходить.

4) Симптом: apt оновлення повільні й інколи падають

Корінна причина: погана продуктивність випадкових записів; SD карта стає вузьким місцем для dpkg і fsync-інтенсивних операцій.
Виправлення: Використайте кращу карту з A1/A2 або endurance; перенесіть root на SSD якщо це сервісний пристрій; зменшіть фонові записи.

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

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

6) Симптом: Продуктивність погіршується тижнями, потім починаються помилки

Корінна причина: wear leveling вичерпав запасні блоки; контролер бореться, викликаючи сплески латентності і остаточні відмови.
Виправлення: Проактивно замініть карту; тримайте більше вільного місця; переходьте на endurance-носій; переносіть інтенсивні записи на SSD.

7) Симптом: Пошкодження бази даних (SQLite тощо) після відключень

Корінна причина: відключення живлення під час транзакцій; іноді посиленo конкурентне fsync поводження або агресивне кешування в контролері.
Виправлення: Виправте живлення; використайте UPS або supercap HAT за потреби; налаштуйте стійкість БД усвідомлено; розгляньте переміщення БД на SSD.

8) Симптом: «Немає місця на диску», хоча ви думаєте, що місце є

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

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

Контрольний список A: Робочий процес надійної інсталяції SD-карти (робоча станція)

Вставте SD-рідер; запустіть lsblk; ідентифікуйте знімний пристрій за розміром і HOTPLUG.
Відмонтуйте розділи: sudo umount /dev/sdX*.
Опційно якщо були неполадки: sudo wipefs -a /dev/sdX.
Запис:
- Бажано: Raspberry Pi Imager з увімкненою верифікацією.
- Вручну: sudo dd if=image.img of=/dev/sdX bs=4M conv=fsync status=progress.
Скидання: sync.
Верифікація: sudo cmp -n $(stat -c%s image.img) image.img /dev/sdX (або обчислити хеші якщо є відомий референс).
Безпечно виймете і потім дістаньте карту.

Контрольний список B: Жорсткість першого завантаження (Pi)

Підтвердіть стан живлення: vcgencmd get_throttled.
Перевірте помилки сховища: dmesg -T | egrep -i 'mmc|I/O error|ext4'.
Оновіть пакети (так, зробіть це): sudo apt-get update та sudo apt-get upgrade. Потім перезавантажте.
Обмежте journald: встановіть SystemMaxUse=64M (або подібне), якщо постійні логи не критичні.
Прийміть рішення щодо swap: якщо є RAM — вимкніть swap на SD; якщо ні — залиште або перенесіть на SSD.
Тримайте запас: не експлуатуйте кореневий розділ на 95% і не дивуйтеся, коли він гірше працює.

Контрольний список C: Операційна позиція для «ці Pi не повинні впадати»

Оберіть endurance-носій або перейдіть на SSD boot.
Купіть дві однакові карти; тримайте одну як протестовану запасну з образом, який можна швидко замінити.
Реалізуйте бекапи (навіть простий rsync критичних даних на інший хост).
Моніторьте прапори недовантаження і події перемонтованих файлових систем.
Плануйте заміну: ставтеся до SD як до витратного матеріалу з життєвим циклом.

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

Міні-історія 1: Інцидент через хибне припущення

Команда розгорнула флот Raspberry Pi як edge-колектори для екологічних сенсорів. ПЗ було стабільним: скромне використання CPU, маленький локальний буфер
і періодичні завантаження на сервер. Пілот з п’ятьма пристроями працював тижнями.

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

Хибне припущення було тонким: «Якщо Pi завантажується, значить живлення в порядку». Вони використовували товарні USB-блоки живлення і довгі кабелі в корпусах.
При нормальному навантаженні Pi був у порядку. Але під час передавання через стільниковий модем (і у холодну погоду) напруга трохи падала, достатньо, щоб перервати записи.
ext4 іноді маскував це; іноді воно перемонтовано в read-only.

Виправлення було простим: офіційні PSU, коротші кабелі і базова перевірка в сценарії провізіонування, що логувала vcgencmd get_throttled і не давала «зеленого» статусу при прапорі.
SD карти перестали «виходити з ладу». ПЗ перестало звинувачуватися в електротехніці.

Урок: розглядайте живлення як частину підсистеми збереження. Воно таке й є.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша група використовувала Pi як кіоскові кінці. Вони хотіли швидше завантаження і менший «знос диска», тож хтось запропонував монтувати root з агресивними опціями:
довші інтервали commit, зменшену бар’єрність і кілька інших налаштувань з форумного поста, написаного у впевненому тоні людини, яка ніколи не носила пейджер.

Кіоски дійсно стали завантажуватися швидше. Вони стали більш чутливими. Команда оголосила перемогу і розгорнула зміни масово.
Потім стався перший стрибок живлення. Частина кіосків завантажилася з неконсистентним станом застосунку, а кілька з некоректними файловими системами, що потребували ручного втручання.
«Але ми ж зменшили записи», — казали вони. Так. І ви також зменшили довговічність.

Постмортем був незручний, але продуктивний. Оптимізація не була злочинною; вона була неправильно застосована.
Налаштування ext4 для продуктивності шляхом ослаблення гарантій скидання — це компроміс. Якщо живлення також нестабільне, ви просто обміняли цілісність на швидкість, не купивши іншу частину угоди (стабільне живлення).

Вони відкотили найризикованіші опції монтування, перемістили великі кеші, що створювали write-amplification, в tmpfs і витратили час на покращення якості живлення.
Час завантаження трохи зріс; кількість інцидентів впала драматично.

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

Невелика платформа команда підтримувала кілька Raspberry Pi для лабораторної автоматизації: тестові стенди, hardware-in-the-loop, і кілька мережевих пробників.
Нічого розкішного, але люди залежали від них. У команди була одна політика, що виглядала майже смішно старомодно: кожен Pi мав відому «золоту» SD-карту,
і кожна зміна ОС фіксувалася в короткому скрипті провізіонування.

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

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

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

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

1) Користуватися Raspberry Pi Imager чи dd?

Використовуйте Raspberry Pi Imager, якщо не маєте протипоказань. Він робить найпростіший шлях з розумними налаштуваннями і може верифікувати запис.
Використовуйте dd, коли вам потрібна автоматизація і ви дисципліновані щодо верифікації і вибору пристрою.

2) Яка файловa система у Raspberry Pi OS, і чи варто її змінювати?

Зазвичай ext4 для root, FAT32 для boot. ext4 — добрий і перевірений варіант. Зміна файлової системи не врятує від поганого живлення або поганого носія,
і часто додає складності без вимірного виграшу на SD.

3) Чи A2 завжди кращий за A1 для Raspberry Pi?

Не завжди. A2 карти можуть вимагати фіч хоста, щоб показати найкращу продуктивність, і деякі комбінації дивно працюють під змішаним I/O.
A1 endurance карти частіше — «нудний і добрий» вибір. Якщо вам важливо, бенчмаркуйте на вашій фактичній моделі Pi.

4) Як дізнатися, що моя SD карта підробна?

Червоні прапори: неконсистентне повідомлення про ємність, невдачі верифікації/порівняння після запису, випадкові I/O помилки на ранньому етапі життя і продуктивність значно нижча за очікування.
Найнадійніша міра — купувати у надійних джерел і верифікувати записані образи за допомогою cmp.

5) Чому мій Pi раптом перемонтовує корінь в режимі лише для читання?

Тому що ядро помітило помилки, що роблять подальші записи ризикованими: перерваний журнал ext4, I/O помилки або таймаути.
Сприймайте це як симптом проблеми з носієм або нестабільним живленням, а не як «настрій Linux».

6) Чи можна просто запускати fsck і далі працювати?

Можна, інколи. Але якщо корупція повторюється, fsck — це лікування синця при тому, що ви продовжуєте бити в те саме місце.
Виправте живлення, зменшіть навантаження на запис і змініть карту, якщо з’являються I/O помилки.

7) Який один найкращий спосіб уникнути корупції SD?

Забезпечте стабільне живлення і уникайте непотрібних записів. Якщо бажаєте одну «прокачку» — перейдіть на USB SSD boot на підтримуваних моделях Pi.
Це змінює весь профіль надійності.

8) Чи варто відключати журналювання, щоб зменшити записи?

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

9) Скільки вільного місця слід тримати на SD?

Тримайте щонайменше 20–30% вільного місця на корені для довготривалої працездатності і продуктивності. При майже повному заповненні файлові системи поводяться погано,
а wear leveling флеша виграє від вільного простору.

10) Моє навантаження «легке». Чи потрібні все одно endurance карти?

Якщо «легке» означає безголовий датчик, що записує один маленький файл раз на годину — мабуть, ні.
Якщо «легке» означає «воно запускає Linux з логами, оновленнями та базою даних», то так — endurance окупить себе.

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

Якщо ви хочете, щоб SD-based Raspberry Pi поводився як пристрій, виконайте наступне по порядку:

Купіть адекватний носій: endurance microSD, 64–128 GB, у надійного постачальника. Ваш час дорожчий за різницю в ціні.
Запишіть і верифікуйте: користуйтеся Raspberry Pi Imager з верифікацією, або dd + cmp. Без винятків.
Виправте живлення: офіційний PSU і якісний кабель; підтвердіть, що vcgencmd get_throttled залишається чистим під навантаженням.
Зменшіть записи: обмежте journald, вимкніть swap на SD якщо можливо, тримайте вільне місце і не запускайте балакучі сервіси, які не потрібні.
Підготуйтеся до відмов: майте протестовану запасну карту (golden image) і процедуру відновлення, що не потребує натхнення.

Зробіть це, і SD-карти перестануть бути містичними. Вони стануть тим, чим завжди були: витратним компонентом у системі, якою ви свідомо керуєте.