장기간 운영되는 Raspberry Pi를 위한 고려사항

• Raspberry Pi를 몇 주에서 몇 년까지 무개입 상태로 유지하려면 장애가 났을 때 자동으로 회복할 경로를 미리 설계해야 함
• 가이드는 기존 SD 카드 마모 줄이기 글을 대체하는 더 넓은 신뢰성 시리즈로, 문제 유형별 대응과 모니터링 팁을 함께 묶음
• 주요 위험은 WiFi 연결 실패, 서비스 중단, 하드웨어·펌웨어·드라이버 불안정으로 인한 크래시, SD 카드 마모 또는 용량 초과로 나뉨
• SD 카드 문제는 적절한 microSD 선택, swap 미사용, 쓰기 감소, 읽기 전용 루트 파일시스템, 필요 시 fsck 실행으로 완화할 수 있음
• journaling 비활성화는 마모를 줄일 수 있어도 크래시나 정전 때 파일시스템 손상 위험을 높이므로 장기 안정성 목표와 맞지 않음

---

장기 운영에서 먼저 봐야 할 실패 지점

• Raspberry Pi를 장기간 온라인으로 유지하려면 각 장애 상황에서 Pi가 어떻게 복구할지 따져봐야 하며, 해결책의 이점과 위험도 함께 비교해야 함
• 저자는 집 안에서 Raspberry Pi를 저전력 FM 송신기와 UPS 에너지 모니터 등으로 사용 중임
• Raspberry Pi Reliability 시리즈는 직접 겪은 문제 유형과 해결 방식을 정리하며, 주로 Uptime Kuma를 활용한 모니터링 팁도 포함함
• 이 시리즈는 기존의 SD 카드 마모 줄이기 글보다 포괄적인 가이드를 목표로 하며, 링크된 글들이 업데이트된 대체물 역할을 함

문제 유형별 대응과 피해야 할 선택

• WiFi 연결 실패는 장기 운영에서 먼저 고려해야 할 장애 유형임
• 소프트웨어 서비스 중단은 별도의 복구 전략이 필요한 영역임
• 하드웨어·펌웨어·드라이버 불안정은 크래시로 이어질 수 있음
• SD 카드는 마모되거나 완전히 가득 찰 수 있어 운영 방식에 영향을 줌
  • 올바른 microSD 카드 선택부터 시작함
  • SD 카드를 swap으로 사용하지 않음
  • SD 카드 쓰기 줄이기, 특히 로그 쓰기 감소와 루트 파일시스템 읽기 전용화를 검토할 수 있음
  • 읽기 전용 루트 파일시스템을 쓰지 않는다면 파일시스템을 자주 검사해야 함
• 불필요한 서비스 비활성화는 소프트웨어 안정성과 SD 카드 마모 완화에 모두 도움이 됨
• 침습적인 개입을 적용하기 전에는 위험과 이점을 먼저 비교해야 함
• 장애가 실제로 발생했을 때 원인 파악에는 원격 로깅이 유용함
• Stack Exchange의 한 글은 Pi 파일시스템의 journaling 비활성화를 제안하지만, 크래시나 정전 때 파일시스템 손상 가능성을 높이므로 피해야 함

[GN⁺]

Hacker News 의견들

• 대신 Lenovo mini PC를 사기 시작했는데, 18cm x 18cm x 3cm라 여전히 아주 작음
  요즘은 아주 싸게 구할 수 있고, 제대로 된 케이스와 냉각도 갖춰져 있음: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
  바로 옆에 하나 두고 쓰는데 i5-8500T, 32GB RAM, SSD 2개 구성이고, powertop 자동 튜닝 상태에서 유휴 전력이 현재 5W임: https://wiki.archlinux.org/title/powertop

  • GPIO, I2C, SPI가 없음. 단순히 작고 가벼운 서버를 찾는다면 적절하지만, Raspberry Pi는 소비자용/사무용 기기에서는 드문 입출력 기능 때문에도 인기가 있음
    마이크로컨트롤러에 직렬 연결을 추가할 수는 있겠지만, 그렇게 하면 해결책이 덜 깔끔해짐
  • 작년에 Kodi 미디어 플레이어를 RasPi 4에서 N3350 mini PC로 옮겼고, 후회하지 않음
    최근에는 NAS(N5105)와 서비스 머신(3215U)도 eBay나 벼룩시장에서 중고로 구한 mini PC와 잠금 해제된 Chromebook으로 옮겼음. 싸고, 전력 소모도 낮게 유지하면서 연산 성능은 Pi와는 완전히 다른 수준임
  • 나도 같은 식으로 쓰지만 Dell 7060을 씀
    호주에서는 리스 만료로 풀리는 물량이 수천 대씩 나옴. 8500T나 8700T 칩은 훌륭하고, 공식적으로 Windows 11을 실행할 수 있으며 하드웨어 트랜스코딩도 내장돼 있어서 Plex 서버로 좋음
    내 것 중 하나는 2TB SSD 2개와 64GB RAM으로 업그레이드했고, 문제 없이 24/7로 돌아감
  • 나도 마찬가지임. Dell 리퍼비시를 샀더니 훨씬 덜 귀찮아졌음
    SD 카드가 아마 가장 큰 문제 원인이었고, RPi에 SSD 같은 걸 붙이는 비용까지 고려하면 더 이상 비용 효율적이지 않았음
  • ARM 하드웨어와 비교하면 거의 아무 Linux 배포판이나 돌릴 수 있다는 점도 좋음

• 첫 조언이 파일시스템의 저널링 모드를 켜라는 것이어서는 안 됨
  첫 조언은 파일시스템을 읽기 전용으로 마운트하고, /var는 메모리에 마운트하며, 모든 로그를 RPi가 아니라 제대로 된 UPS와 NUT가 돌아가는 노드로 보내는 것이어야 함. 파일시스템이 읽기 전용이거나 임시 영역이면 정전은 사실상 무해해짐
  RPi 한 대라면 과할 수 있지만, 작성자는 집 곳곳에서 여러 대를 쓴다고 했음
  또한 A/B 시스템 파티션을 두고 전체 파티션을 다시 쓰는 방식으로 업그레이드한 뒤 활성 파티션을 바꾸는 것도 좋음. 그러면 새 버전에 치명적 버그가 있어도 항상 정상 시스템 파티션 하나가 남고 복구가 쉬워짐
  이런 방식으로 여러 소형/단일 보드 PC를 다양한 역할에 20년 넘게 잘 써왔음

  • 작성자는 몇 줄 아래에 읽기 전용 구성 조언 링크를 걸어놨음
    https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
  • /var뿐 아니라 /tmp 같은 곳에도 tmpfs를 써야 함. 그러면 SD 카드 수명이 크게 늘어날 것임
  • A/B 시스템 파티션을 두고 전체 파티션을 다시 쓰는 식으로 업그레이드한다면, 업그레이드 절차가 어떤지 궁금함
    새 디스크 이미지는 어떻게 만들고, 각 장치에 로그인해서 업그레이드하는지 아니면 자동화가 있는지 궁금함
  • 파일시스템을 읽기 전용으로 마운트하면 시스템 업데이트나 새 소프트웨어 설치는 어떻게 하는지 궁금함
  • Docker 같은 걸 쓰면 /var를 메모리에 마운트했을 때 장치 메모리를 초과할 수 있음
    /var/lib/docker를 보조 저장소로 옮겨야 할 수도 있음

• 2011년에 Global Scale Technologies의 초기 플러그 컴퓨터에서 돌아가는 상용 제품을 만든 적이 있음
  20대밖에 팔지 않았는데 전부 SD 카드 손상 문제로 반품됐고, 급하게 루트 파일시스템을 읽기 전용으로 바꿔야 했음. 그 뒤로는 이 방식을 좋아하게 됨
  그 초기 상용 제품은 아주 작은 홈 자동화 기능을 포함한 가정 보안 제품이었고, 2021년에 새 이름으로 오픈소스로 공개했으며 지금은 Jetson 계열 단일 보드 컴퓨터에서 동작함: https://github.com/hcfman/sbts-install
  이제는 고급 YOLO 모델도 트리거로 포함. 독립형 제품을 의도했기 때문에 HTTPS를 지원했고, 인증서 작업 전체를 감싸는 GUI도 있었음. 이 기능은 오픈소스 버전에도 남아 있어 장치 간 REST 호출에 자체 서명 인증서를 쓰기 쉬움
  또한 다중 파티션 메모리 overlayFS 방식을 유지하고 확장했으며, 설치 과정에서 먼저 sbts-base 시스템을 설치하게 해서 다른 사람들이 이를 자기 기반 시스템으로 쓸 수 있게 함

  • 비슷한 경험이 있음. 5달러짜리 Pentium 2 PC를 팬리스이자 무소음 워크스테이션으로 개조하면서 HDD를 CF 카드로 바꿨음
    시간이 지나자 디스크 쓰기 때마다 시스템이 1~2초씩 멈추기 시작했고 꽤 고통스러웠음

• 이런 걸 하려는 사람들에게 먼저 ESP32 같은 작은 보드로 필요한 일을 처리할 수 없는지 보라고 권하고 싶음
  전력 사용량은 훨씬 적고, 가격은 몇 달러 수준이며, 많은 용도에 충분함. Python 쪽을 선호한다면 많은 보드가 MicroPython과 CircuitPython을 모두 지원함
  초기 구매 비용과 계속 드는 전기료를 줄일 수 있으니 살펴볼 가치가 있음

  • 임베디드 프로그래밍의 시간 비용과 복잡도를 걱정하는 반론도 이해하지만, 취미 사용자라면 적어도 고려해볼 만한 훌륭한 추천이라고 봄
    마이크로컨트롤러로 해낸 프로젝트들은 Pi 기반 프로젝트보다 수십 년 단위로 더 안정적이었고, 기본 SSH 설정을 바꾸는 걸 깜빡해 봇넷 일부가 될 걱정도 덜함. 기본값이 pi:raspberry 아니었나 싶음
    MicroPython 외에도 ESP32C3용 no_std Rust 지원이 매달 좋아지고 있음. 재미로 작은 홈 자동화 프로젝트를 하는 사람에게는 추가 제약이 오히려 재미있고 보람 있게 만들 수 있음
    다만 Linux에 이미 익숙한 사람에게는 Pi가 대체로 훨씬 쉽고, 내 경험상 비용은 최소 10배쯤 비쌈. 같은 수준의 안정성을 얻기 위한 SSD 부팅, 네트워크 부팅, 읽기 전용 루트 파일시스템, 감시견 설정 같은 추가 구성과 더 높은 전력 사용량, 특히 Pi 5의 전력도 의사결정에 포함해야 함
  • ESP32에서 미디어 서버를 돌릴 수 있나? 못 함
    ESP32에서 비밀번호 관리자 서버를 돌릴 수 있나? 못 함. Pi-hole? 안 됨. Unifi 컨트롤러? 안 됨
    이런 추천은 사람들이 Pi를 차고문 컨트롤러 같은 데 쓴다고 상상하는 듯한데, 반사적으로 ESP32를 Pi 대체재로 제안하는 건 별 도움이 안 됨
  • ESP32와 관련 보드는 꽤 멋지지만 완전히 다른 사고방식이 필요함
    뭔가 안 될 때 HDMI와 키보드를 연결해, 일반적인 유틸리티가 다 있는 메인라인 Linux 환경에서 즉석 디버깅을 할 수는 없음
  • Pi Zero는 전기요금이 1년에 1달러 정도 나옴
  • 최근 조금 더 복잡한 구성에서는 Pi Zero 하나와 여러 ESP8266/32를 HTTP와 Wi-Fi로 통신시키며 쓰고 있음
    Arduino 대신 MicroPython을 처음 써봤는데 정말 마음에 들고, 놀랍게도 매우 안정적임. 예전에는 Wi-Fi 전력 상태 때문에 장기적으로 프로젝트가 자주 망가졌는데, 지금까지 MicroPython 구조에서는 문제가 없음

• “Wi-Fi 연결이 괜찮은지 주기적으로 확인하고, 아니면 Wi-Fi 인터페이스나 Pi 전체를 재시작하는 스크립트로 대부분 귀결된다”는 건 해킹이 아니라 모범 사례임
  데이터센터의 중요한 서버에 IPMI나 원격 제어 가능한 RPDU 콘센트 같은 대역외 연결이 있어야 하듯, 접근하기 어려운 원격 위치의 중요한 서버에는 감시견 스크립트가 있어야 함
  물론 재부팅의 영향과 재부팅 전까지의 다운타임을 고려해 용도에 맞게 조정해야 하고, 최소한 나중에 조사할 수 있도록 이상 이벤트를 기록할 수는 있음
  원격 RPi를 배포했을 때 가장 먼저 한 일이 간단한 Bash 감시견 스크립트였음. Wi-Fi 문제뿐 아니라, 깨질 수 있고 재부팅으로 고쳐질 수 있는 수십 가지 상황을 위한 것이었음

  • 요즘 대부분의 배포판에서 이런 감시견 역할은 init/PID 1, 즉 systemd가 맡고 있음
    init이 서비스를 관리할 수 있다고 신뢰할 수 없다면, 시스템이 서비스를 제공한다는 보장은 어디서 오는지 의문임
    스크립트로 다시 만들 수도 있겠지만 우리는 이미 그 단계를 지나왔음. systemd를 많이 언급하지만 편애하려는 것은 아니고 대안도 있음
    대부분의 서비스는 자신이 존재하는 환경을 제대로 활용하지 않음. 웹 서버가 특정 마운트를 필요로 한다고 선언하는 식의 사이트별 커스터마이징을 기대하는 듯함
    흔히 놓치는 지시어가 PartOf=임. 한 서비스나 리소스의 재시작을 다른 것과 묶을 수 있음
    더 간단하게는 NetworkManager가 Wi-Fi/포털 확인을 커스터마이즈하는 방법을 제공할 것 같음. 완전히 과격하게 갈 필요는 없을 수 있음
  • 비슷하게 ESP8266으로 Wi-Fi 라우터와 케이블 모뎀을 감시함. 문제가 생기면 재부팅함
    라우터의 경우 적절한 SSID에 연결을 시도하고 라우터에 ping을 보낸 뒤, 둘 중 하나라도 실패하면 다른 라우터로 전환함. 동일한 설정의 같은 라우터 두 대를 두고, 전원은 SPDT 릴레이의 NO/NC 접점에 연결해 하나가 실패하면 릴레이 상태만 바꿔 다른 쪽으로 전환함
    라우터가 살아 있으면 감시견은 케이블 모뎀 상태 페이지를 불러오고, ISP망 안에서 CMTS이거나 그 근처 장비로 보이는 IP 세 개 중 아무 데나 ping을 보내 HFC 설비가 살아 있는지 확인함. 재부팅으로 해결할 수 없는 장애라면 굳이 재부팅하고 싶지 않기 때문임
    안타깝게도 같은 MAC을 가진 케이블 모뎀 두 대를 두고 전환하는 방법은 찾지 못했고, ISP도 같은 계정에 모뎀 두 대를 허용하지 않아서 케이블 모뎀이 실패하면 재부팅하고 잘되길 바라는 수밖에 없음
    여기에 정전 중에도 라우터와 모뎀을 30시간 넘게 돌릴 수 있는 배터리 랙을 붙였고, 2020년 5월에 만든 뒤 거의 계속 온라인 상태를 유지했음. 코드는 끔찍하지만, 실제로는 매우 견고하게 동작함
  • 완전히 동의함. 감시견 타이머는 “영원히” 소프트웨어를 돌리는 마이크로컨트롤러와 컴퓨터에 필수임
    완벽한 코드와 설계로도 막을 수 없는 일이 생기고, 감시견 타이머는 무한 루프를 끊고 리셋해줌. 우주선이 비트를 뒤집는 일이나 순간 전압 강하 같은 것도 있고, Raspberry Pi에서는 SD 카드 손상도 걱정해야 함
    Raspberry Pi에는 내장 하드웨어 감시견 타이머가 있는 것으로 앎. Arduino에는 확실히 있음
  • 모범 사례이면서 동시에 해킹이기도 함. 필요하지 않아야 하지만, 버그가 존재하니 필요해짐

• 거의 10년 동안 수천 대의 Pi를 운영 환경에서 돌려왔고, 이제 x86으로 옮기기 시작하고 있음
  Pi의 가격 대비 성능은 예전 같지 않음. 최근 State of Open Con에서 이 경험을 발표했음: https://youtu.be/vX-qK9mxKZI

  • Raspberry Pi 디지털 사이니지 CEO 동료로서, 발표에서 Pi 4부터 가능한 보안 부팅 지원을 언급하지 않아 놀랐음
    우리 서비스는 아직 쓰지 않지만, 문서상으로는 꽤 견고해 보이고 디스크/SD의 데이터를 보호할 수 있음
    우리는 아직 Pi에 꽤 만족하고 있으며, 더 개방적인 API인 Mesa/DRM/KMS/FFmpeg로 이동한 것도 이제야 쓸 만한 상태가 되면서 매우 유망해 보임
    주된 용도가 여전히 디지털 사이니지라 원시 처리 성능은 크게 중요하지 않음. 비용이 큰 부분인 비디오 디코딩은 당연히 가속되고, Pi에서 가능한 하위 호환성은 훌륭함. 아직도 거의 10년째 Pi1B+를 계속 돌리며 우리가 제공하는 최신 OS 릴리스를 쓰는 고객들이 있음
  • 사용 방식을 감안해야 함. 유휴 상태가 많다면 ARM이 x86보다 낫다고 봄
    수명도 봐야 하는데, 거기서도 ARM이 x86보다 오래갈 것 같음. 모듈성 측면에서도 ARM이 x86보다 나음. 작은 장치를 여러 개 두기 더 싸기 때문임
    하지만 확장성, 즉 현재 경제에서의 사업성은 x86이 ARM보다 낫다
    또한 모든 그래프는 와트당 기준이어야 함. 2에서 4로 갔더니 성능이 좋아졌다는 건 새 소식이 아니고, 와트당 성능이 좋아졌는지가 중요함
    그렇게 보면 Raspberry Pi 5는 와트당 성능 향상이 기대만큼 크지 않다는 걸 알 수 있음. 인류 역사상 영구적으로 정점에 도달한 것 같음
    마지막으로, 지금 이 시점에서 어떤 진전의 유일한 희망은 성능이 아니라 개방성 측면에서 JH7110인데, 3D 지원이 뒤처져 있음
  • 디스플레이 구동용인지, 아니면 생산 조립 장비처럼 GPIO를 쓰는 운영 장비용인지 궁금함
  • x86으로 옮긴다는 게 구체적으로 무슨 뜻인지 궁금함

• 그런 것들을 하나도 하지 않았는데도 몇몇 Pi가 새 모델로 교체되기 전까지 수년 동안 문제 없이 돌아갔음
  HomeKit/Zigbee 게이트웨이와 데이터 로거는 지금 Pi 4임. 결국 좋은 SD 카드와 안정적인 전원 공급이 핵심인 듯함

  • 동의함. 나도 여러 Pi를 돌려왔고, 고장 났을 때는 SD 카드 불량 때문이었음
    pibenchmark가 좋은 정보원이라고 봄: https://pibenchmarks.com/
    구매 전에 SD 카드는 꼭 비교해봐야 함
  • 표본 크기가 경험에 더 큰 영향을 준다고 봄
    충분히 많은 장치를 운영하면 잘못될 수 있는 것은 전부 잘못되고, 꿈에도 생각 못 한 새로운 고장 모드도 나타남
  • 2016년 전후와 그 이전의 오래된 Raspbian OS는 접근 시간 기록이 켜져 있어서, 파일을 읽을 때마다 쓰기가 발생했음
    그 뒤로 손상된 카드 보고가 많았던 이유가 아마 그 때문일 것임
  • 나도 비슷함. Pi3 몇 대를 Cups 서버로 몇 년째 돌리고 있고, 가동 시간은 정전 때만 초기화됨. 정전도 매우 드묾
    micro SD 카드에 Raspbian을 설치하고, Cups를 설정하고, 프린터에 USB를 연결한 것 말고는 한 일이 없음. 다른 한 대는 네트워크 프린터를 관리함. 그 뒤로 그냥 놔뒀음
  • 아주 들쭉날쭉함. 어떤 것들은 끝없이 문제가 생겼고, 다른 것들은 오래 괜찮았음. 뚜렷한 패턴은 보이지 않음
    이제 대부분은 SSD로 바꿨음. 아니면 너무 주사위 굴리기 같음

• SD 카드 이야기가 첫 번째가 아니라는 데 놀랐고, 글에서 USB 부팅을 제안하지 않는다는 점도 더 놀라웠음
  Pi 하나를 몇 년째 거의 24/7로 켜두고 있는데, 문제가 없었던 이유를 1) 디스크를 거의 건드리지 않도록 Alpine을 구성한 것, 2) 손상될 SD 카드가 없는 것이라고 봄. 왜 USB가 더 안정적인지는 모르겠지만, 경험적으로는 그랬음

  • SSD를 붙인 내 Argon Raspberry 구성도 안정적임
    실패하는 유일한 이유는 전기가 나갈 때임. 10분만 버틸 수 있는 배터리면 완전히 충분할 듯함
  • Alpine을 디스크를 거의 건드리지 않게 구성하는 방법이 궁금함
    예를 들면 https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode 같은 걸 말하는지 알고 싶음
  • SD로 문제 없이 돌린 Pi 카드가 많았음. 그런데 딱 하나는 갑자기 SD 카드가 엄청 뜨거워졌고, 막 설정하던 새 Pi였음
    카드를 빼고 그 카드와 다음 Pi는 USB SSD로 바꿔서 쓰고 있음. 좀 무서웠음. 그래도 앞서 말했듯 micro SD로 Cups 서버를 몇 년째 문제 없이 돌린 Pi도 있음
  • 완전히 동의함. 내 RPi 고장은 모두 SD 카드 때문이었음
    RPi 두 대는 둘 다 USB에서 부팅하고 실행하며, 몇 년째 잘 돌아감
  • 나도 같음. M.2 HAT로 SSD에서 부팅하는데 아주 잘 동작함

• 2017년부터 같은 SD 카드로 Pi 두 대를 거의 계속 돌리고 있음. 정전은 2~3번 정도 있었음
  하나는 DNS/프린트 서버이고, 하나는 Kodi이며 미디어는 외부 NFS에 있음. 내가 한 일은 모든 로그를 끈 것뿐이고, 한 번도 문제가 없었음
  둘 다 SanDisk 2GB 카드를 쓰고 있음. “공간이 적다 → 비트 밀도가 낮다 → 신뢰성이 좋다”는 식으로 순진하게 생각했던 기억이 어렴풋이 있음

  • log2ram(github/azlux/log2ram)을 써왔고 결과에 만족함
    /var에 RAM 디스크를 마운트하고, 가끔씩만 로그를 RAM 디스크에서 SD 카드로 복사함. 덕분에 SD 카드를 심하게 두드리지 않으면서도 모든 로그를 볼 수 있음
  • 원래 SD 카드 그대로 Pi 1에서 Kodi를 거의 10년째 돌리고 있음
    대부분 켜져 있지만, 연결된 USB 전원 공급 장치를 실수로 끌 때가 가끔 있음. 5포트짜리 작은 전원 공급 장치인데 이것도 거의 같은 나이이고, 내 구성에서는 전원 버튼이 너무 쉽게 눌림
  • 2014년부터 같은 SD 카드로 쉬지 않고 돌아가는 RPi가 하나 있고, 날씨 웹사이트를 제공함
    기본적으로 모든 로그와 웹페이지를 tmpfs에 마운트했고, DB는 SD 카드에 있으며 5분마다 기록됨
  • 첫 Pi를 아직도 갖고 있음. 아마 Pi 1B일 것임
    여러 설치를 거쳤지만 지금은 백업 DNS 서버임. 파일시스템을 보니 2018년부터 Pi-hole로 쓰였고, 몇 번의 재부팅과 이사 때를 빼면 사실상 24/7로 돌아감
    SD에는 아무것도 쓰지 않고 전부 /dev/shm의 RAM으로 보냄. Pi-hole은 드물게 내려가면 목록을 다시 받으면 되고, 어차피 매일 다운로드함
  • 나도 마찬가지임. Raspberry Pi 3 두 대가 있고, 2019년부터 광고 차단용 Pi-hole을 돌리고 있음
    나중에는 로컬 DNS와 Tailscale 노드로도 쓰기 시작했음. 몇 달 동안 재부팅하지 않은 적도 있고, 최장 가동 시간은 약 11개월이었음. 매우 견고했음. UPS에 연결해두면 확실히 도움이 됨

• “Raspberry Pi를 몇 주, 몇 달, 몇 년 동안 무개입으로 온라인 상태로 유지하는 건 어느 정도 예술이다”라고 했는데, 나는 내장 파일시스템이 포함된 NetBSD 커널을 부팅함
  예를 들면 INSTALL 커널이나 커스텀 커널을 씀. 부팅 직후 SD 카드는 빼도 되고, 선택적으로 연결된 저장소에 chroot함
  이렇게 하면 몇 주, 몇 달, 몇 년 동안 돌아감. 블로그 작성자가 든 문제는 겪어보지 않았음
  내가 찾은 유일한 문제는 케이스를 쓸 때 전원 커넥터 쪽임. 예를 들어 교체 케이블을 쓰면 연결이 약할 수 있음. 최신 Pi에서는 나아졌을 수도 있음
  하지만 대부분의 컴퓨터도 비슷하다고 말할 수 있음. 케이블과 커넥터는 보통 약하고 싼 부품임. 움직임 때문에 전원이 끊기면 Pi는 자동으로 재부팅됨