저는 u-boot를 부트로더로 사용하고 systemd init 시스템을 사용하여 임베디드 Linux를 개발 중입니다. 이러한 도구는 표준 busybox로 제한됩니다.
일부 문제를 분석하는 동안 루트 파일 시스템이 읽기 전용이어서 문제를 일으키는 것을 발견했습니다. 그 이유는 일부 서비스와 프로그램이 쓰기 가능한 루트 파일 시스템에 의존하여 오류를 일으키기 때문입니다.
몇 가지 조사 끝에 루트 파일 시스템은 전원이 꺼졌을 때만 읽기 전용이라는 사실을 알게 되었습니다. (특정 오류가 발생하면 기본 장치가 전원 재활용을 트리거합니다.) 루트 파일 시스템이 일부 중요한 파일을 쓰거나 일부 서비스/프로세스 로고를 업데이트하려고 할 때 정전 시 파일 시스템에 오류가 설정된 것으로 의심됩니다. 다음 부팅 시 fsck는 이 플래그를 읽고 루트를 읽기 전용으로 마운트/재마운트하거나, fsck가 루트를 일종의 복구 모드로 강제 전환합니다(복구 모드가 있는지는 모르겠습니다).
내 가정이 맞나요? 그렇다면 오류 발생 당시 FS에 설정된 fs 플래그는 무엇입니까? 루트가 RO로 시작되는 것을 방지하는 방법은 무엇입니까?
노트:
루트 파일 시스템은 "errors=continue"를 사용하여 마운트됩니다. 따라서 fsck가 remount 옵션에 대한 슈퍼블록을 읽는 경우 오류를 무시하고 RW로 다시 마운트해야 합니다.
dd 명령을 실행하면서 전원을 끄는 등 상황을 재현해 보았으나 한번도 재현이 되지 않았습니다.
추가 질문: 어떤 udev/systemd 매직이 루트 fs를 마운트합니까?
답변1
시작 시 파일 시스템을 검사하여 시스템이 제대로 종료되었는지 또는 충돌이 발생했는지 확인하고 후자의 경우 필요한 복구 작업을 수행해야 합니다. 최신 저널 파일 시스템에서 이는 일반적으로 자동화할 수 있는 간단하고 빠른 저널 복구 작업을 의미합니다.
루트 파일 시스템 검사 및 마운트는 일반적으로 initramfs/initrd에 의해 수행되지만 임베디드 시스템에는 있을 수도 있고 없을 수도 있습니다.
initramfs를 사용하지 않는 경우 전통적인 접근 방식은 커널을 사용하는 것입니다.언제나루트 파일 시스템은 초기에 읽기 전용으로 마운트됩니다(시작 옵션을 사용하여 root=/dev/<whatever> ro시작 스크립트가 fsck먼저 실행됩니다(사용된 파일 시스템 유형에 필요하다고 가정). 그런 다음 작업을 수행하기 전에 루트 파일 시스템이 다시 마운트됩니다. 읽기/쓰기 모드.
initramfs가 루트 파일 시스템을 확인하지 않는 경우(아마도 사용되지 않기 때문에) 루트 파일 시스템에서 파일 시스템 확인을 실행하는 데 사용되는 표준 systemd 서비스 이름은 으로 지정됩니다 systemd-fsck-root.service. 확인한 결과 systemd를 사용하여 루트 파일 시스템을 다시 마운트하는 서비스 이름을 찾을 수 없습니다.
부팅 시 루트 파일 시스템 검사에서 루트 파일 시스템 수정이 필요한 경우 수정 사항은 커널이 이미 읽고 캐싱하고 있는 내용에 영향을 줄 수 있으므로 루트 파일 시스템이 수정된 후에 수정되기 때문에 일반적으로 나중에 다시 재부팅됩니다. 일관성 없는. 디스크는 fsck.