2 Followers
1 Following
19 Posts
엔지니어
개정안 주요 내용
- 연합우주 시민이 "연친소 각이다"라고 선언하는 즉시 상장서버와 비상장서버를 막론하고 연친 소각 실시
- 서버장이 같은 서버 연친을 보유한 경우 자사주로 간주하고 1년 내 연친소각 (서버장과 연친을 함께 소각)

RE: https://yuri.garden/notes/akpbke4vqi
@pbzweihander @hoong 그게… voyage 는 위키낱말사전 기준으로도 /ˈvɔɪ.ɪd͡ʒ/ 이고 [^1] 메리엄-웹스터 발음 표기도 ˈvȯi-ij 이고 [^2] 네이버 사전 발음도 /ˈvɔɪɪdʒ/ 이고 [^3] 다음 사전 발음도 /vɔ́iidʒ/ 입니다. [^4] 즉 /ə/ 음가가 없다는 것이 학계 다수설로 보입니다.

왜 "a" 가 들어 있는데 "a" 같은 음가가 없느냐 하시면… 만악의 근원인 대 모음 추이 [^5] 때문이겠죠. package 가 "패카지" 가 아니라 /ˈpækɪdʒ/ "패키지" 인 것과 같이…

[^1]: https://en.wiktionary.org/wiki/voyager
[^2]: https://www.merriam-webster.com/dictionary/voyage
[^3]: https://en.dict.naver.com/#/entry/enko/27472534047d483382a7cfe73fe6ea36
[^4]: https://dic.daum.net/word/view.do?wordid=ekw000182234&q=voyage
[^5]: https://en.wikipedia.org/wiki/Great_Vowel_Shift
voyager - Wiktionary, the free dictionary

Wiktionary
리부트는 잘 되었다. 그러나 이 시스템이 사용되는 일은 없었다. F2FS 와의 사투에 모든 힘을 쏟아낸 xt 는 이 서버를 전혀 써먹지 않고 의욕 상실, 무기력 상태로 뒹굴었다.

F2FS 마운트 옵션으로 atgc, checkpoint_merge 등을 넣고 싶다. 문제는 이걸 /etc/fstab 에 넣으면 systemd-remount-fs 가 실패하며, 옵션은 적용이 안 된다는 것이다. 루트 파일시스템은 initramfs 시점에서 이미 마운트당했고 그걸 다른 마운트 옵션으로 리마운트하려다가 망하는 것이다.

다른 파일시스템 같으면 "RO 후 RW 리마운트" 라는 전략에 아무 문제가 없다. 리마운트 하면서 마운트 옵션 바꾸는 것도 어지간하면 다 된다. 하지만 F2FS 는 그런 거 애초에 지원 안 한다고 한다. 진짜냐? F2FS 의 비위를 맞추겠다고 깨진 멘탈이 질펀했습니다. 이 모든 삽질을 하면서 나는 무엇을 얻고 있는 것일까요?

아무튼 처음부터 RW 로, 그리고 원하는 옵션 넣어서 마운트하는 수밖에 없다. 예를 들어
cmdline.txt

rootflags=noatime,nodiscard,checkpoint_merge,flush_merge,atgc,data_flush,fsync_mode=strict
같은 걸 끼얹는 것이다. 이게 될까? 지금 리부트해 보겠습니다. (플래그)

"이제 곧 F2FS 삽질이 끝난다"
"F2FS 삽질이 끝나면 어떻게 되는데?"
"모르는가? 새 F2FS 삽질이 시작되지"

으휴

F2FS 마운트 옵션 문제로 RO 마운트 상태에 빠졌다면 dmesg | grep -i f2fs 로 찍어 볼 수 있다. 대충 이런 게 찍힌다.

F2FS-fs (mmcblk0p2): FLUSH_MERGE not compatible with readonly mode
Pi OS 기준 제일 간단한 해결책은
/boot/firmware/cmdline.txtrw 추가하는 것이다. 그러면 루트 파일시스템이 처음 마운트 될 때부터 RW 로 마운트 되므로, 문제가 없어진다. 급한 불은 껐다.

그러나 이게 "올바른" 해결책인가? 들여다본다. 첩첩산중이다. 전산학이 아니라 역사학이다. 결론부터 말하자면
rw 해도 되는 것으로 보인다.

- 요오즘 대부분의 그누/리눅스 배포판은
최초 램디스크 를 쓴다. 이것은 파일시스템 하나를 통째로 담고 있는 "디스크 이미지 압축 파일" 이다. 부팅 시 이것을 메모리에 압축 풀어 놓으면 그게 그대로 파일시스템이 되며, OS 가 된다. initrd 와 initramfs 가 미묘하게 다르지만, 비닐봉투에 담느냐 종이봉투에 담느냐 정도의 차이일 뿐 하는 일은 비슷하다.
- 근데, 루트 파일시스템을 담고 있는 파티션이 있을 텐데 왜 그걸 그냥 쓰지 않고 굳이 무슨 램디스크 이미지 같은 것을 따로 쓰는가? 그것은 말이여. 요오즘 젊은이들이 바라는 게 많아서 그랴! 예를 들어 루트 파일시스템에 FDE 되어 있으면
cryptsetup open 같은 걸 누군가 해 줘야 한다. 그렇다. initramfs 와 루트 파일시스템의 관계는 대한민국 임시정부와 대한민국 정부의 관계이다.
- 이 initramfs 이미지를 굽기 위해 데비언 계열에서는 커널이나 관련 패키지 버전 올라갈 때마다 update-initramfs 돌아가는 것을 볼 수 있고 아치에서는 mkinitcpio 돌아가는 것을 볼 수 있다.
- initramfs 를 쓴다면 "fsck 를 위해서 RO first, RW later 한다" 같은 것은 무의미한 소리가 된다. initramfs 는 이름 그대로 파일시스템이며 OS 로 기능할 수 있다. 독립국이다. 얘가 fsck 하면 된다. RO 고 RW 고 나발이고, 루트 파일시스템은 마운트할 필요조차 없다.
- Pi OS 는 원래 initramfs 를 쓰지 않았다 (!). 이유는 모르겠음. 짐이 지금 1GB 더 절약해 보겠다고 눈물의 관심법을 하고 있는데 어찌 임시정부 하나를 통째로 구워서 microSD 의 소중한 공간을 차지할 수가 있느냐 이 미련한 것아! 하면서 철퇴 당한 게 아닐까?
- 그러나 이제 microSD 도 기본 수백 GB 단위로 나오는 세상이 와 버렸으며 8GB 같은 것은 잘 팔지도 않는다. 그래서 Pi OS 도 기본 동작이 바뀌었다. 이제 기본 이미지에도 initramfs 들어 있고,
apt upgrade 하면 알아서 새 버전 구워지고, /boot/firmware/config.txt 에는 auto_initramfs=1 이 기본값이다.
- 따라서 initramfs 를 굳이 따로 껐다든지, 옛날에 구성한 오래된 Pi OS 를 쓰고 있다든지, 그런 게 아니라면 initramfs 이미 잘 쓰이고 있을 것이다. 그러므로
cmdline.txt 에서 ro 하느냐 rw 하느냐와 무관하게 fsck.mode 의 값은 본인의 기호에 맞는 매운맛으로 조절하면 된다.

Initial ramdisk - Wikipedia

- 오랫동안 셀프호스티드의 이념을 숭상함
- 오랫동안 하스켈을 숭배함
- 둘 다 제 깜냥보다 더 큰 근성이 필요 (…)
- 하스켈로 셀프호스티드에 도움이 되는 뭔가를 만든 것이 있는데, 완성도가 부족해서 공개를 못함. 공개할 수 있는 수준까지 망치를 더 붓기로 결심
- 근성으로 삽질을 하고는 있지만 동굴 속에서 망치질만 하기가 너무 답답하고, 그동안 엔지니어링 잡담과 넋두리를 어딘가 공개된 곳에 쓰고 싶음
- (그 잡담 공간도 셀프호스티드로 직접 운영함이 마땅하지만 그러면 순환종속성으로 망하므로 타협해야 함)
- 도저히 맘에 드는 플랫폼이 없음
- 요즘 대세는 ActivityPub 라는데 그 프로토콜 얼마나 복잡한지, 제대로 다루려면 얼마나 방대한 구현체가 필요한지 어떤 분이 이미 잘 설명하심. 나보다 망치 많은 사람도 심연으로 빨려들어갔는데 내가 손대면 어떤 끝없는 야크 심도의 무저갱으로 추락할지 100% 확신. 절대 안 됨. 바퀴의 재발명은 꿈도 꾸지 말고, 있는 바퀴 중에 골라야 함
- 생각해 보니 쯔 대개방은 믿음직하고 든든하며 대개방께서 령도하시는 인스턴스는 드팀없이 영생불멸할 것이며 백합.정원은 세계GL코스모폴리타니즘에 부합하는 자유가입체제임
- 이런 결론으로 난데없이 계정을 개설하고 수다 떨기 시작
- 그냥 온갖 아무 상관 없어 보이는 엔지니어링 삽질, 푸념, 좌절, 한탄, 넋두리를 늘어놓을 예정이니 엔지니어링 인사이트 같은 것은 기대하지 마시고 대충 보시고 저의 절망을 힐끗 비웃으며 넘기실 것을 권장합니다
- 저는 물론 백합에는 전면 찬성하며 《ヨコハマ買い出し紀行》는 불후의 백합 걸작이니 꼭 보십시오

이 계정이 신성한 백합.정원에 누를 끼친다는 정원사의 선고가 있을 시 미련없이 폭파하겠습니다.
그누/리눅스 시스템은 부트 시퀀스에서 루트 파일시스템을 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 서비스들이 꿋꿋이 뜬다는 게 신기할 정도.

최악의 경우 "설정이 잘못되었는데 그 잘못된 설정의 수정도 불가능한" 수렁에 빠지겠죠. 주의하십시오. 어떻게 알았는가? 저도 알고 싶지 않았다.
아무튼 파이 서버가 안 올라오던 문제: 에이전트 보고도 없고 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 잘 되는 것을 보장하는 체제를 만들어야 할 것이라는 결론이다. 으윽