Hal-hal yang perlu dipertimbangkan untuk Raspberry Pi yang berjalan jangka panjang

 (dzombak.com)
1 poin oleh GN⁺ 2024-02-18 | 1 komentar | Bagikan ke WhatsApp
  • Untuk menjaga Raspberry Pi tetap berjalan tanpa intervensi selama beberapa minggu hingga beberapa tahun, perlu merancang terlebih dahulu jalur pemulihan otomatis saat terjadi gangguan
  • Panduan ini adalah seri keandalan yang lebih luas sebagai pengganti tulisan lama tentang mengurangi keausan kartu SD, dengan rangkuman cara menangani tiap jenis masalah beserta tip pemantauan
  • Risiko utama terbagi menjadi kegagalan koneksi WiFi, layanan yang berhenti, crash akibat ketidakstabilan perangkat keras·firmware·driver, serta keausan kartu SD atau kapasitas yang penuh
  • Masalah kartu SD dapat dikurangi dengan memilih microSD yang tepat, tidak menggunakan swap, mengurangi penulisan, memakai root filesystem hanya-baca, dan menjalankan fsck bila perlu
  • Menonaktifkan journaling memang dapat mengurangi keausan, tetapi meningkatkan risiko kerusakan filesystem saat crash atau listrik padam sehingga tidak sejalan dengan tujuan stabilitas jangka panjang

Titik kegagalan yang perlu dilihat lebih dulu dalam operasi jangka panjang

  • Untuk menjaga Raspberry Pi tetap online dalam jangka panjang, perlu dipikirkan bagaimana Pi akan pulih pada setiap situasi gangguan, sambil membandingkan manfaat dan risiko dari tiap solusi
  • Penulis menggunakan Raspberry Pi di rumah sebagai pemancar FM berdaya rendah dan monitor energi UPS, antara lain
  • Seri Raspberry Pi Reliability merangkum jenis masalah yang benar-benar dialami serta cara mengatasinya, dan juga mencakup tip pemantauan yang terutama memanfaatkan Uptime Kuma
  • Seri ini ditujukan sebagai panduan yang lebih menyeluruh dibanding tulisan lama tentang mengurangi keausan kartu SD, dan tulisan-tulisan yang ditautkan berperan sebagai pengganti yang telah diperbarui

Penanganan per jenis masalah dan pilihan yang perlu dihindari

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-18
Komentar Hacker News

  • Sebagai gantinya, saya mulai membeli Lenovo mini PC; ukurannya 18 cm x 18 cm x 3 cm, jadi masih sangat kecil
    Sekarang bisa didapat dengan sangat murah, dan sudah dilengkapi casing serta pendinginan yang layak: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    Saya memakai satu tepat di sebelah saya, konfigurasinya i5-8500T, RAM 32 GB, dan 2 SSD; dengan auto-tuning powertop, konsumsi daya idle-nya saat ini 5 W: https://wiki.archlinux.org/title/powertop

    • Tidak ada GPIO, I2C, SPI. Kalau sekadar mencari server yang kecil dan ringan, ini cocok, tetapi Raspberry Pi juga populer karena fitur I/O yang jarang ada di perangkat konsumen/kantoran
      Memang bisa menambahkan koneksi serial ke mikrokontroler, tetapi solusi seperti itu jadi kurang rapi
    • Tahun lalu saya memindahkan pemutar media Kodi dari RasPi 4 ke N3350 mini PC, dan tidak menyesal
      Belakangan NAS (N5105) dan mesin layanan (3215U) juga saya pindahkan ke mini PC bekas dan Chromebook yang sudah di-unlock, yang saya dapat dari eBay atau pasar loak. Murah, konsumsi dayanya tetap rendah, sementara performa komputasinya benar-benar beda level dibanding Pi
    • Saya juga memakai pendekatan yang sama, tetapi dengan Dell 7060
      Di Australia ada ribuan unit bekas lease yang dilepas. Chip 8500T atau 8700T sangat bagus, secara resmi bisa menjalankan Windows 11, dan memiliki transcoding hardware bawaan, jadi cocok untuk server Plex
      Salah satu milik saya sudah saya-upgrade dengan 2 SSD 2 TB dan RAM 64 GB, dan berjalan 24/7 tanpa masalah
    • Saya juga begitu. Setelah membeli Dell refurbished, urusannya jauh lebih tidak merepotkan
      Kartu SD mungkin sumber masalah terbesar, dan kalau biaya memasang sesuatu seperti SSD ke RPi ikut dihitung, itu tidak lagi hemat biaya
    • Dibandingkan hardware ARM, kelebihan lainnya adalah bisa menjalankan hampir semua distribusi Linux

  • Saran pertama seharusnya bukan menyalakan mode journaling pada filesystem
    Saran pertama seharusnya adalah me-mount filesystem sebagai read-only, me-mount /var di memori, dan mengirim semua log bukan ke RPi, melainkan ke node yang layak dengan UPS dan NUT. Jika filesystem read-only atau berupa area sementara, pemadaman listrik pada dasarnya tidak berbahaya
    Untuk satu RPi mungkin berlebihan, tetapi penulis mengatakan ia memakai beberapa unit di berbagai tempat di rumah
    Selain itu, bagus juga memakai partisi sistem A/B dan melakukan upgrade dengan menulis ulang seluruh partisi lalu mengganti partisi aktif. Dengan begitu, meski versi baru punya bug fatal, selalu ada satu partisi sistem yang masih normal dan pemulihan jadi mudah
    Dengan cara seperti ini, saya sudah memakai banyak PC kecil/single-board untuk berbagai peran selama lebih dari 20 tahun tanpa masalah

    • Penulis menautkan saran konfigurasi read-only beberapa baris di bawahnya
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • Selain /var, tempat seperti /tmp juga harus memakai tmpfs. Itu akan sangat memperpanjang umur kartu SD
    • Kalau memakai partisi sistem A/B dan melakukan upgrade dengan menulis ulang seluruh partisi, saya penasaran seperti apa prosedur upgrade-nya
      Bagaimana image disk baru dibuat, dan apakah upgrade dilakukan dengan login ke tiap perangkat, atau ada otomatisasinya?
    • Kalau filesystem di-mount read-only, bagaimana melakukan update sistem atau menginstal software baru?
    • Kalau memakai sesuatu seperti Docker, saat /var di-mount di memori, kapasitas memori perangkat bisa terlampaui
      Mungkin perlu memindahkan /var/lib/docker ke storage tambahan

  • Pada 2011, saya pernah membuat produk komersial yang berjalan di komputer plug generasi awal dari Global Scale Technologies
    Hanya terjual sekitar 20 unit, tetapi semuanya dikembalikan karena masalah kerusakan kartu SD, dan kami harus buru-buru mengubah root filesystem menjadi read-only. Sejak itu saya jadi menyukai pendekatan ini
    Produk komersial awal itu adalah produk keamanan rumah dengan sedikit fitur otomasi rumah; pada 2021 dirilis sebagai open source dengan nama baru, dan sekarang berjalan di komputer single-board keluarga Jetson: https://github.com/hcfman/sbts-install
    Sekarang juga menyertakan model YOLO canggih sebagai trigger. Karena ditujukan sebagai produk mandiri, produk itu mendukung HTTPS, dan ada GUI yang membungkus seluruh pekerjaan terkait sertifikat. Fitur ini tetap ada di versi open source, sehingga mudah memakai sertifikat self-signed untuk panggilan REST antarperangkat
    Selain itu, kami mempertahankan dan memperluas pendekatan overlayFS memori multipartisi, dan dalam proses instalasi sistem sbts-base dipasang terlebih dahulu agar orang lain dapat menggunakannya sebagai sistem dasar mereka sendiri

    • Saya punya pengalaman serupa. Saat memodifikasi PC Pentium 2 seharga 5 dolar menjadi workstation fanless dan senyap, saya mengganti HDD dengan kartu CF
      Seiring waktu, setiap kali ada penulisan ke disk, sistem mulai berhenti 1–2 detik, dan itu cukup menyiksa

  • Kepada orang yang ingin melakukan hal seperti ini, saya ingin menyarankan lebih dulu untuk melihat apakah pekerjaan yang dibutuhkan bisa ditangani dengan papan kecil seperti ESP32
    Konsumsi dayanya jauh lebih rendah, harganya hanya beberapa dolar, dan cukup untuk banyak penggunaan. Jika lebih menyukai sisi Python, banyak papan mendukung MicroPython maupun CircuitPython
    Ini layak dilihat karena bisa mengurangi biaya pembelian awal dan biaya listrik yang terus berjalan

    • Saya paham sanggahan yang mengkhawatirkan biaya waktu dan kompleksitas pemrograman embedded, tetapi bagi pengguna hobi, menurut saya ini setidaknya rekomendasi yang sangat layak dipertimbangkan
      Proyek-proyek yang saya selesaikan dengan mikrokontroler terbukti lebih stabil dalam skala puluhan tahun dibanding proyek berbasis Pi, dan kekhawatiran lupa mengubah pengaturan SSH bawaan lalu menjadi bagian dari botnet juga lebih kecil. Seingat saya default-nya dulu pi:raspberry
      Selain MicroPython, dukungan no_std Rust untuk ESP32C3 juga makin membaik setiap bulan. Bagi orang yang membuat proyek otomasi rumah kecil untuk bersenang-senang, batasan tambahan justru bisa membuatnya lebih menarik dan memuaskan
      Namun bagi orang yang sudah terbiasa dengan Linux, Pi umumnya jauh lebih mudah, dan menurut pengalaman saya biayanya setidaknya sekitar 10 kali lebih mahal. Konfigurasi tambahan seperti boot dari SSD, boot jaringan, filesystem root read-only, pengaturan watchdog untuk mendapatkan stabilitas yang setara, serta konsumsi daya yang lebih tinggi—terutama daya Pi 5—juga perlu dimasukkan dalam keputusan
    • Bisakah menjalankan server media di ESP32? Tidak bisa
      Bisakah menjalankan server pengelola kata sandi di ESP32? Tidak bisa. Pi-hole? Tidak. Kontroler Unifi? Tidak
      Rekomendasi seperti ini tampaknya membayangkan orang memakai Pi untuk hal-hal seperti pengendali pintu garasi, tetapi secara refleks mengusulkan ESP32 sebagai pengganti Pi tidak terlalu membantu
    • ESP32 dan papan terkait memang cukup keren, tetapi membutuhkan pola pikir yang benar-benar berbeda
      Saat ada sesuatu yang tidak beres, kita tidak bisa menyambungkan HDMI dan keyboard lalu melakukan debugging spontan di lingkungan Linux mainline yang punya semua utilitas umum
    • Tagihan listrik Pi Zero sekitar 1 dolar per tahun
    • Dalam konfigurasi yang belakangan sedikit lebih kompleks, saya memakai satu Pi Zero dan beberapa ESP8266/32 yang saling berkomunikasi lewat HTTP dan Wi-Fi
      Saya pertama kali memakai MicroPython alih-alih Arduino dan benar-benar menyukainya; yang mengejutkan, ini sangat stabil. Dulu proyek jangka panjang sering rusak karena status daya Wi-Fi, tetapi sejauh ini dalam struktur MicroPython tidak ada masalah

  • Pernyataan bahwa “pada akhirnya sebagian besar berupa skrip yang secara berkala memeriksa apakah koneksi Wi-Fi baik-baik saja, dan jika tidak, me-restart antarmuka Wi-Fi atau seluruh Pi” bukanlah hack, melainkan praktik terbaik
    Sama seperti server penting di pusat data harus memiliki koneksi out-of-band seperti IPMI atau soket RPDU yang bisa dikendalikan jarak jauh, server penting di lokasi terpencil yang sulit diakses harus memiliki skrip watchdog
    Tentu perlu disesuaikan dengan penggunaan, dengan mempertimbangkan dampak reboot dan downtime sebelum reboot, dan setidaknya bisa mencatat peristiwa abnormal agar dapat diselidiki kemudian
    Saat menerapkan RPi jarak jauh, hal pertama yang saya lakukan adalah membuat skrip watchdog Bash sederhana. Itu bukan hanya untuk masalah Wi-Fi, tetapi untuk puluhan situasi yang bisa rusak dan bisa diperbaiki dengan reboot

    • Di sebagian besar distro saat ini, peran watchdog seperti ini dijalankan oleh init/PID 1, yaitu systemd
      Jika kita tidak bisa percaya init untuk mengelola service, saya jadi bertanya-tanya dari mana jaminan bahwa sistem akan menyediakan service itu berasal
      Kita bisa saja membuatnya lagi dengan skrip, tetapi tahap itu sudah kita lewati. Saya banyak menyebut systemd, tetapi bukan bermaksud memihak; ada juga alternatif
      Sebagian besar service tidak memanfaatkan lingkungan tempat mereka berada dengan benar. Sepertinya mereka mengharapkan kustomisasi per situs, misalnya server web menyatakan bahwa ia membutuhkan mount tertentu
      Direktif yang sering terlewat adalah PartOf=. Ini bisa mengikat restart suatu service atau resource dengan yang lain
      Lebih sederhananya, NetworkManager tampaknya menyediakan cara untuk mengustomisasi pemeriksaan Wi-Fi/portal. Mungkin tidak perlu mengambil langkah yang sepenuhnya ekstrem
    • Mirip dengan itu, saya memantau router Wi-Fi dan modem kabel dengan ESP8266. Jika terjadi masalah, perangkat di-reboot
      Untuk router, ia mencoba tersambung ke SSID yang sesuai dan mengirim ping ke router; jika salah satunya gagal, ia beralih ke router lain. Saya menyiapkan dua router yang sama dengan konfigurasi identik, dan dayanya disambungkan ke kontak NO/NC pada relay SPDT, sehingga jika satu gagal, cukup mengubah status relay untuk beralih ke yang lain
      Jika router hidup, watchdog memuat halaman status modem kabel dan mengirim ping ke salah satu dari tiga IP di jaringan ISP yang tampaknya merupakan CMTS atau perangkat di sekitarnya, untuk memastikan fasilitas HFC masih hidup. Karena jika gangguannya tidak bisa diselesaikan dengan reboot, saya tidak ingin melakukan reboot sia-sia
      Sayangnya saya belum menemukan cara untuk menyiapkan dua modem kabel dengan MAC yang sama lalu beralih di antara keduanya, dan ISP juga tidak mengizinkan dua modem pada akun yang sama, jadi jika modem kabel gagal, yang bisa dilakukan hanya reboot dan berharap berhasil
      Saya juga menambahkan rak baterai yang bisa menjalankan router dan modem lebih dari 30 jam saat listrik padam, dan sejak dibuat pada Mei 2020, sistem ini hampir terus online. Kodenya buruk sekali, tetapi dalam praktiknya bekerja dengan sangat tangguh
    • Sepenuhnya setuju. Timer watchdog wajib ada pada mikrokontroler dan komputer yang menjalankan perangkat lunak “selamanya”
      Ada hal-hal yang bisa terjadi meski kode dan desain sudah sempurna, dan timer watchdog akan memutus loop tak berujung lalu melakukan reset. Ada juga hal seperti pesawat ruang angkasa yang membalik bit atau penurunan tegangan sesaat, dan pada Raspberry Pi kita juga harus mengkhawatirkan kerusakan kartu SD
      Sejauh yang saya tahu, Raspberry Pi memiliki timer watchdog perangkat keras bawaan. Arduino pasti memilikinya
    • Ini praktik terbaik sekaligus hack. Seharusnya tidak perlu, tetapi karena bug memang ada, jadinya diperlukan

  • Selama hampir 10 tahun, kami telah menjalankan ribuan Pi di lingkungan produksi, dan sekarang mulai beralih ke x86
    Performa Pi terhadap harganya tidak seperti dulu lagi. Saya mempresentasikan pengalaman ini di State of Open Con baru-baru ini: https://youtu.be/vX-qK9mxKZI

    • Sebagai sesama CEO signage digital berbasis Raspberry Pi, saya terkejut presentasi itu tidak menyebut dukungan secure boot yang tersedia sejak Pi 4
      Layanan kami sendiri belum menggunakannya, tetapi dari dokumentasinya terlihat cukup solid dan bisa melindungi data di disk/SD
      Kami masih cukup puas dengan Pi, dan perpindahan ke API yang lebih terbuka seperti Mesa/DRM/KMS/FFmpeg juga terlihat sangat menjanjikan karena baru sekarang mulai benar-benar layak dipakai
      Karena penggunaan utamanya masih digital signage, daya pemrosesan mentah tidak terlalu penting. Decoding video, yang merupakan bagian besar dari biaya, tentu saja diakselerasi, dan kompatibilitas mundur yang dimungkinkan di Pi sangat bagus. Masih ada pelanggan yang terus menjalankan Pi1B+ hampir 10 tahun lamanya dan memakai rilis OS terbaru yang kami sediakan
    • Pola penggunaan perlu diperhitungkan. Jika banyak berada dalam kondisi idle, menurut saya ARM lebih baik daripada x86
      Umur pakai juga perlu dilihat, dan di sana pun sepertinya ARM akan bertahan lebih lama daripada x86. Dari sisi modularitas juga ARM lebih baik daripada x86, karena lebih murah menempatkan banyak perangkat kecil
      Namun untuk skalabilitas, yakni kelayakan bisnis dalam ekonomi saat ini, x86 lebih baik daripada ARM
      Selain itu, semua grafik seharusnya berbasis per watt. Bahwa performa meningkat saat beralih dari 2 ke 4 bukanlah berita baru; yang penting adalah apakah performa per watt meningkat
      Jika dilihat begitu, terlihat bahwa peningkatan performa per watt Raspberry Pi 5 tidak sebesar yang diharapkan. Rasanya kita telah mencapai puncak permanen dalam sejarah manusia
      Terakhir, pada titik ini satu-satunya harapan untuk kemajuan bukan dari sisi performa, melainkan dari sisi keterbukaan, adalah JH7110, tetapi dukungan 3D-nya tertinggal
    • Saya penasaran apakah ini untuk menggerakkan display, atau untuk peralatan operasional yang memakai GPIO seperti peralatan perakitan produksi
    • Saya penasaran apa tepatnya yang dimaksud dengan beralih ke x86

  • Saya tidak melakukan satu pun hal seperti itu, tetapi beberapa Pi tetap berjalan tanpa masalah selama bertahun-tahun sampai diganti dengan model baru
    Gateway HomeKit/Zigbee dan data logger saya sekarang memakai Pi 4. Pada akhirnya, sepertinya kuncinya adalah kartu SD yang bagus dan catu daya yang stabil

    • Setuju. Saya juga menjalankan beberapa Pi, dan saat rusak penyebabnya adalah kartu SD yang bermasalah
      Menurut saya pibenchmark adalah sumber informasi yang bagus: https://pibenchmarks.com/
      Kartu SD sebaiknya benar-benar dibandingkan sebelum membeli
    • Menurut saya ukuran sampel lebih besar pengaruhnya terhadap pengalaman
      Jika mengoperasikan perangkat dalam jumlah cukup banyak, semua hal yang bisa salah akan salah, dan mode kegagalan baru yang bahkan tidak pernah terpikirkan juga akan muncul
    • Raspbian OS lama sekitar 2016 dan sebelumnya mengaktifkan pencatatan waktu akses, sehingga setiap kali file dibaca, terjadi penulisan
      Mungkin itulah alasan mengapa setelah itu ada banyak laporan kartu yang rusak
    • Saya juga mirip. Saya menjalankan beberapa Pi3 sebagai server Cups selama bertahun-tahun, dan uptime hanya reset saat listrik padam. Pemadaman listrik pun sangat jarang
      Selain memasang Raspbian di kartu micro SD, mengatur Cups, dan menghubungkan USB ke printer, tidak ada lagi yang saya lakukan. Satu unit lain mengelola printer jaringan. Setelah itu saya biarkan saja
    • Sangat tidak konsisten. Beberapa terus-menerus bermasalah, sementara yang lain baik-baik saja dalam waktu lama. Tidak terlihat pola yang jelas
      Sekarang sebagian besar sudah saya ganti ke SSD. Kalau tidak, rasanya terlalu seperti melempar dadu

  • Saya terkejut pembahasan kartu SD bukan yang pertama, dan lebih terkejut lagi karena tulisan itu tidak menyarankan boot dari USB
    Saya menyalakan satu Pi hampir 24/7 selama bertahun-tahun, dan menurut saya alasan tidak ada masalah adalah 1) Alpine dikonfigurasi agar hampir tidak menyentuh disk, 2) tidak ada kartu SD yang bisa rusak. Saya tidak tahu mengapa USB lebih stabil, tetapi secara pengalaman memang begitu

    • Konfigurasi Raspberry Argon saya dengan SSD terpasang juga stabil
      Satu-satunya alasan gagal adalah saat listrik padam. Baterai yang bisa bertahan 10 menit sepertinya sudah sepenuhnya cukup
    • Saya penasaran bagaimana cara mengonfigurasi Alpine agar hampir tidak menyentuh disk
      Misalnya, apakah maksudnya sesuatu seperti https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
    • Saya punya banyak kartu Pi yang berjalan tanpa masalah lewat SD. Namun ada satu yang tiba-tiba kartu SD-nya menjadi sangat panas, dan itu Pi baru yang sedang saya atur
      Saya mencabut kartunya, lalu memakai kartu itu dan Pi berikutnya dengan USB SSD. Agak menakutkan. Namun seperti disebutkan sebelumnya, ada juga Pi yang menjalankan server Cups lewat micro SD selama bertahun-tahun tanpa masalah
    • Sepenuhnya setuju. Semua kerusakan RPi saya disebabkan oleh kartu SD
      Dua RPi saya sama-sama boot dan berjalan dari USB, dan sudah bertahun-tahun berjalan baik
    • Saya juga sama. Saya boot dari SSD lewat M.2 HAT, dan bekerja dengan sangat baik

  • Sejak 2017 saya menjalankan dua Pi dengan kartu SD yang sama hampir terus-menerus. Pemadaman listrik mungkin terjadi sekitar 2–3 kali
    Yang satu adalah server DNS/print, yang satu lagi Kodi, dan medianya ada di NFS eksternal. Satu-satunya yang saya lakukan hanyalah mematikan semua log, dan belum pernah ada masalah
    Keduanya memakai kartu SanDisk 2GB. Saya samar-samar ingat dulu berpikir naif seperti “kapasitas kecil → kepadatan bit rendah → keandalan lebih baik”

    • Saya sudah memakai log2ram(github/azlux/log2ram) dan puas dengan hasilnya
      Ia me-mount disk RAM di /var, lalu hanya sesekali menyalin log dari disk RAM ke kartu SD. Berkat itu, semua log tetap bisa dilihat tanpa menghajar kartu SD terlalu keras
    • Saya menjalankan Kodi di Pi 1 dengan kartu SD asli yang sama selama hampir 10 tahun
      Sebagian besar waktunya menyala, tetapi kadang saya tanpa sengaja mematikan catu daya USB yang tersambung. Itu catu daya kecil 5-port yang usianya juga hampir sama, dan dalam konfigurasi saya tombol dayanya terlalu mudah terpencet
    • Ada satu RPi yang berjalan tanpa henti dengan kartu SD yang sama sejak 2014, menyediakan situs web cuaca
      Pada dasarnya semua log dan halaman web di-mount ke tmpfs, sementara DB ada di kartu SD dan ditulis setiap 5 menit
    • Saya masih punya Pi pertama saya. Mungkin Pi 1B
      Sudah melewati beberapa instalasi, tetapi sekarang menjadi server DNS cadangan. Dari filesystem-nya terlihat bahwa sejak 2018 dipakai sebagai Pi-hole, dan selain beberapa kali reboot serta saat pindahan, praktis berjalan 24/7
      Tidak ada yang ditulis ke SD; semuanya dikirim ke RAM di /dev/shm. Jika Pi-hole sesekali mati, tinggal ambil ulang daftarnya, dan toh memang diunduh setiap hari
    • Saya juga begitu. Saya punya dua Raspberry Pi 3, dan sejak 2019 menjalankan Pi-hole untuk pemblokiran iklan
      Belakangan juga mulai dipakai sebagai DNS lokal dan node Tailscale. Pernah beberapa bulan tanpa reboot, dan uptime terpanjang sekitar 11 bulan. Sangat tangguh. Menyambungkannya ke UPS jelas membantu

  • Ada yang mengatakan “menjaga Raspberry Pi tetap online tanpa intervensi selama berminggu-minggu, berbulan-bulan, atau bertahun-tahun itu sampai taraf tertentu adalah seni”, tetapi saya mem-boot kernel NetBSD dengan filesystem bawaan
    Misalnya memakai kernel INSTALL atau kernel kustom. Setelah boot, kartu SD boleh dilepas, dan secara opsional melakukan chroot ke storage yang tersambung
    Dengan cara ini ia berjalan selama berminggu-minggu, berbulan-bulan, atau bertahun-tahun. Saya belum pernah mengalami masalah yang disebut penulis blog
    Satu-satunya masalah yang saya temukan adalah di sisi konektor daya saat memakai casing. Misalnya jika memakai kabel pengganti, sambungannya bisa lemah. Mungkin sudah lebih baik di Pi terbaru
    Namun bisa dibilang sebagian besar komputer juga serupa. Kabel dan konektor biasanya komponen yang lemah dan murah. Jika listrik terputus karena pergerakan, Pi akan reboot otomatis