Pi 3B+ 하나가 망했기 때문에 복구하기 위한 대장정을 시작한다
일단 자동으로 켜져야 할 에이전트가 안 켜지고, SSH 접근도 안 된다
그리고 직접 키보드와 모니터를 연결해 봤지만 어째 로그인도 안 된다. 패스워드 관리를 나름대로 철저히 하고 있다고 생각하는데... 로그인이 안 되다니... 갑자기 이거 혹시 취약점 공격이라도 당한 게 아닌가 하는 불안감이 든다
microSD 카드를 뽑아서 직접 파일시스템을 수정한다. /etc/passwd 를 고쳐서 jdoe:x:1001:1001:John Doe:/home/jdoe:/bin/bash 중에서 x 부분을 삭제하면 된다고 하는데... 적용 후 (인터넷 연결 안 하고) 키보드와 모니터만 연결한 상태로 다시 tty 로그인을 시도해 본다. 안 된다!
파이에서 F2FS 써서 이득을 누리기... 라고 써 놓고 보니 내가 힙스터인가 하는 생각이 든다.
F2FS - ArchWiki 에도 흉흉한 이야기가 가득함.
근데 저거 다 몇 년 전 얘기고 지금은 저 정도로 혼파망은 아니고요. F2FS 도 그간 꾸준한 개발로 많이 성숙했습니다. 제가 Pi 3B+ 에서 F2FS 를 루트 파일시스템으로 쓰고 있습니다. 물론 그래서 얻은 것이 무엇이냐 하면 잘 모르겠다.
F2FS 란 무엇인가: 플래시메모리는 기존 저장매체와 영 다른 작동특성을 갖는다. SSD 의 경우 펌웨어에 심오하고 숭고한 묘리를 담아 플래시메모리의 온갖 고통과 액난을 유유히 건너가지만, microSD 같으면 그것도 불가능하다(펌웨어 넣을 공간이 어딨어). F2FS 는 플래시메모리의 이런 약점을 파일시스템 층위에서 보완하려는 설계 사상이다. 이론상으로는 플래시메모리가 제공하는 인터페이스를 플래시메모리의 특성에 맞게 적절하게 잘 활용하는 파일시스템이며, 성능 벤치마크도 ext4 등에 비해 우수하다. 파일시스템 구현이 오래 전부터 메인라인 커널에 들어가 있으므로 국밥처럼 든든하다. (물론 유틸리티는 당연히 별도다.)
그래서 무슨 짓을 했는가: 이 Pi 3B+ 처음 설정할 때, Pi OS 이미지 있는 그대로 갖다 쓰지 않고 굳이 루트 파일시스템을 F2FS 로 설정하는 삽질을 했습니다. Pi OS 설정해 보신 분들은 아시겠지만 그냥 ext4 쓰면 dd 한 번으로 microSD 준비가 끝난다. 반면 F2FS 를 루트 파일시스템으로 쓰려면 microSD 를 수동으로 파티셔닝 하는 것은 물론이고 Pi OS 이미지를 루프 디바이스로 마운트하네 어쩌네 하며 별 삽질을 다 해야 함.
그 짓을 해서 행복한가: 뭔가 전반적으로 빠른 것 같기는 한데 잘 모르겠습니다. 사실 제대로 알고 싶으면 벤치마크를 돌려야겠지만 그러면 microSD 를 마모시켜야 되잖아. microSD 의 마모를 줄이려고 F2FS 를 쓰는 건데. 주객전도다. 그래서 차마 못하고 있다. 몇 년째...아무튼 파이 서버가 안 올라오던 문제: 에이전트 보고도 없고 SSH 접근도 안 되고... 직접 콘솔로 붙어 보니 커넥티비티가 없다. ping 8.8.8.8 이 안 된다. 왜 안 되는가? IP 주소를 못 받는가? DHCP 문제인가? DHCP 는 잘 되었다. 근데 놀랍게도 DHCP 가 잘 된 결과 IP 주소를 예전 것과 새 것 두 개를 잡고 있었다. 애초에 전 ip addr 했을 때 하나의 인터페이스에 두 개의 inet 이 뜰 수 있다는 것을 이번에 처음 알았습니다.
원인은 예전에 이 파이의 NM 설정에 "선호하는" IP 주소를 넣어 두려고 했던 것이었다. 그게 되겠냐. 근데 이러고서도 그 IP 주소를 실제로 할당받는 데에는 몇 년 동안 문제가 없었는데, 첫째로 MAC 주소가 동일하고 (따라서 ISP 가 매번 웬만하면 같은 것을 준다) 둘째로 리부트가 대개 새벽에 unattended-upgrades 에 의해 자동으로 일어났기 때문이었다. 새벽 네 시는 인간이 가장 잔인해지는 시간대로서, 장치 추가든 재설정이든 그냥 아예 뭔가를 잘 하지 않는다. 그래서 이 시간대에 시스템이 꺼졌다 켜져도 주소를 그대로 다시 점유할 수 있었던 것. 운 좋게.
그러나 이번에는 아주 오랜만에 낮 시간대에 하드웨어 전원 내리고 작업을 한 결과, 몇 년 동안이나 유지하던 IPv4 주소를 상실하는 비참한 수모를 겪었다. 근데 그것뿐이면 사실 언젠가는 다시 올라왔을 가능성이 높은데, 시스템은 계속 이 주소를 탈환 (...) 하려고 할 것이고 그러면 점유자가 이탈하는 순간 되찾을 가능성이 있기 때문이다. 근데 어이없게도 DHCP 도 작동해서 하나의 인터페이스에 두 개의 IP 주소가 뜨고 이 상태로 과연 인터넷 프로토콜이 동작하는지 아닌지도 알 수 없는 상태가 되어 버렸다.
예전에 "선호하는" IP 주소 넣어 두려고 했다가 (이때는 아주 높은 업타임을 지향했다) 좀 아닌 것 같아서 다시 없애려고 했던 것 같은데, 제대로 없애지 못하고 뭔가 이도 저도 아닌 상태로 남은 듯... 기억이 안 난다... 반성합니다. 게다가 sudo nmcli 쳐서 설정했던 부분이라 어디 설정 파일에 있는 것도 아니고, 다른 머신에는 전혀 없는 설정이니 더더욱 발견할 수 없었다.
이게 다 결국 DHCP 가 "웬만하면" 같은 IP 주소를 주는 게 문제다. 다이내믹이면 다이내믹답게 매번 다른 주소를 줘야 하는 것 아닙니까? (아님)
의도적으로 긴 다운타임을 만들든지 아니면 MAC 주소를 조금씩 흔들든지 해서 일부러 IP 주소 바뀌게 하면서 에이전트 잘 되고, DynDNS 잘 되는 것을 보장하는 체제를 만들어야 할 것이라는 결론이다. 으윽
그누/리눅스 시스템은 부트 시퀀스에서 루트 파일시스템을 RO (read-only) 로 우선 마운트한 뒤, /etc/fstab 적용 단계에서 RW (read-write) 로 리마운트하는 "RO first, RW later" 를 기본 동작으로 하는 경우가 많습니다.
이 짓을 왜 하는가? 가장 큰 장점은 루트 파일시스템에 대해 "RW 마운트 중에는 불가능한 일" 을 할 수 있다는 것입니다. 예를 들어 많은 파일시스템이 "RW 마운트 중 fsck" 를 지원하지 않습니다. 아무래도 체크섬, 오토 힐 등을 하려는 경우 RW 마운트 중에는 힘들죠 (Btrfs 같은 외계 기술만 예외). 또 하드웨어든 소프트웨어든 문제가 있어서 시스템이 부팅 초기에 거듭 실패하는 경우, 루트가 RW 마운트 중이면 루트의 "깨짐" 이 더 악화될 수 있겠죠. 그래서 적어도 fsck 를 수행할 수 있을 만큼 멀쩡한 시스템 상태가 완비되고, fsck 가 수행되고, 완료될 때까지 루트는 RO 로 둔다는 전략입니다. 그럴듯하죠.
문제는 마운트 옵션을 변경하려는 경우입니다. 예를 들어 F2FS 마운트 옵션 중 flush_mount, atgc 등은 첫 마운트 시점에 들어가야 하고, RO-RW 리마운트 시점에는 넣을 수 없습니다. 따라서 이것들을 /etc/fstab 에 넣고 리부트 해 보면 리마운트가 실패하며 (dmesg 로 볼 수 있음) 루트가 RO 인 채로 부팅이 됩니다. 이러면 시스템은 당연히 마비 상태입니다. 이래도 systemd 서비스들이 꿋꿋이 뜬다는 게 신기할 정도.
최악의 경우 "설정이 잘못되었는데 그 잘못된 설정의 수정도 불가능한" 수렁에 빠지겠죠. 주의하십시오. 어떻게 알았는가? 저도 알고 싶지 않았다.