Linux: pstore, ramoops

pstore (Persistent Storage)

리눅스 커널이 크래시(Crash)가 발생하거나 재부팅되는 상황에서도 로그 데이터를 보존하기 위해 사용하는 파일시스템 인터페이스입니다.

 

1. pstore의 핵심 역할

일반적인 리눅스 시스템은 커널 패닉(Kernel Panic)이 발생하면 시스템이 멈추기 때문에 디스크에 로그를 기록할 수 없습니다. 따라서 재부팅 후에는 왜 죽었는지 원인을 찾기가 어렵습니다.

pstore는 이 문제를 해결하기 위해 커널이 죽기 직전의 데이터(dmesg, console 등)를 사라지지 않는 저장소에 기록하고, 재부팅 후에 유저가 파일처럼 읽을 수 있게 해줍니다.

2. pstore의 구조 (아키텍처)

pstore는 프론트엔드(Frontend)와 백엔드(Backend) 구조로 나뉩니다.

• Frontend (파일시스템 인터페이스):
  • 사용자(User Space)에게 /sys/fs/pstore라는 경로를 제공합니다.
  • 사용자는 이 경로에서 ls, cat 명령어로 로그를 확인합니다.
  • 어떤 하드웨어에 저장되었는지는 숨기고, 일관된 파일 접근 방식을 제공합니다.
• Backend (실제 저장 드라이버):
  • 실제 데이터를 하드웨어에 기록하는 역할을 합니다.
  • 시스템 환경에 따라 다른 백엔드를 선택하여 사용합니다.

3. 주요 Backend 종류 (저장 매체)

pstore는 데이터를 어디에 저장하느냐에 따라 여러 백엔드를 지원합니다.

4. pstore에 저장되는 데이터 유형

/sys/fs/pstore 디렉토리에 생성되는 파일들은 이름에 따라 담고 있는 정보가 다릅니다.

• dmesg-xxx: 커널 로그 버퍼(kmsg)의 마지막 내용. (가장 중요: 패닉 로그)
• console-xxx: 콘솔 출력 내용.
• pmsg-xxx: 유저 공간(User Space)에서 기록한 메시지. (Android의 경우 Logcat 일부 등)
• ftrace-xxx: 함수 추적(Function Trace) 데이터. (디버깅용)

5. 사용 워크플로우 (요약)

1. 설정: 커널 Config에서 CONFIG_PSTORE 및 원하는 백엔드(CONFIG_PSTORE_RAM 등) 활성화.
2. 크래시 발생: 커널 패닉 발생 -> pstore가 백엔드(예: RAM)에 로그 기록 -> 재부팅.
3. 로그 확인: 부팅 후 mount -t pstore pstore /sys/fs/pstore (대부분 자동 마운트됨).
4. 분석: /sys/fs/pstore/dmesg-ramoops-0 등의 파일을 열어 죽은 원인 분석.
5. 정리: 파일시스템 공간 확보를 위해 분석이 끝난 파일은 삭제하거나 백업. (많은 init 스크립트들이 부팅 시 /var/log 등으로 옮기고 pstore를 비웁니다.)

---

Ramoops oops/panic logger

ramoops는 리눅스 커널의 pstore (persistent storage) 서브시스템을 사용하여, 시스템이 커널 패닉(Kernel Panic)이나 웁스(Oops)로 인해 크래시가 발생했을 때 로그 데이터를 RAM의 특정 영역에 기록하는 기능입니다.

이 기능은 디스크 I/O가 불가능한 상황에서 시스템이 죽기 직전의 로그를 보존하고, 웜 부팅(Warm Boot) 후 이를 다시 읽어낼 수 있게 해줍니다. 임베디드 리눅스(Android 포함) 개발 시 매우 중요한 디버깅 도구입니다.

1. Ramoops 작동 원리

• 메모리 예약: 부팅 시 RAM의 일정 영역(예: 0x8f000000 번지)을 운영체제가 일반 메모리로 쓰지 못하게 예약합니다.
• 크래시 발생 시: 커널 패닉이 발생하면 디스크 쓰기가 불가능해질 수 있으므로, 미리 예약된 RAM 영역에 로그(dmesg)를 씁니다.
• 재부팅 후: 전원이 완전히 차단되지 않은 웜 리셋(Warm Reset)의 경우, RAM의 데이터가 보존됩니다. 부팅 후 /sys/fs/pstore를 통해 이 영역을 파일처럼 읽을 수 있습니다.

2. 사용을 위한 설정 방법

사용을 위해서는 커널 설정(Config)과 메모리 예약(DTS 또는 부트 파라미터) 두 단계가 필요합니다.

A. 커널 설정 (Kernel Config)
커널 빌드 시 .config 파일에 다음 항목들이 활성화되어야 합니다.

CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y  # 콘솔 로그 저장
CONFIG_PSTORE_RAM=y      # RAM을 저장소로 사용 (Ramoops)

 

B. 메모리 예약 (두 가지 방법 중 택 1)
방법 1: Device Tree (DTS) 사용 (추천 - 임베디드/Android) 가장 정석적인 방법으로, 디바이스 트리 파일(.dts)에 reserved-memory 노드를 추가합니다.

/ {
    reserved-memory {
        #address-cells = <2>;
        #size-cells = <2>;
        ranges;

        /* RAM의 특정 물리 주소(예: 0x8f000000)를 예약 */
        ramoops@8f000000 {
            compatible = "ramoops";
            reg = <0x0 0x8f000000 0x0 0x100000>; /* 주소 및 크기(1MB) */
            record-size = <0x4000>;             /* 로그 레코드 크기 (16KB) */
            console-size = <0x4000>;            /* 콘솔 메시지 크기 */
            pmsg-size = <0x4000>;               /* 유저공간 메시지 크기 */
        };
    };
};

 

방법 2: 커널 부트 파라미터 사용 (x86 또는 DTS 수정 불가 시) 부트로더(GRUB, U-Boot)의 커널 커맨드 라인에 직접 인자를 전달합니다.

mem=1024M ramoops.mem_address=0x3f000000 ramoops.mem_size=0x100000 ramoops.record_size=0x4000

 

• mem=1024M: 커널이 사용할 메모리를 제한하여 ramoops 영역을 침범하지 않게 합니다.
• ramoops.mem_address: 예약할 물리 메모리 시작 주소입니다.

3. 실제 사용 예제 및 확인

설정이 완료된 리눅스 시스템에서 실제로 어떻게 동작하는지 확인하는 절차입니다.

1) 강제로 커널 패닉 유발 (테스트)
root 권한으로 sysrq를 이용해 강제로 크래시를 일으킵니다.

 

echo c > /proc/sysrq-trigger

 

시스템이 즉시 재부팅됩니다.

2) 로그 확인 (재부팅 후)
재부팅 후 pstore 파일시스템을 마운트하여 저장된 로그를 확인합니다. (대부분의 배포판은 자동으로 마운트됩니다.)

# 마운트가 안 되어 있다면 수동 마운트
mount -t pstore pstore /sys/fs/pstore

# 로그 파일 확인
ls -al /sys/fs/pstore/
# 출력 예: dmesg-ramoops-0, dmesg-ramoops-1 등의 파일이 보임

# 내용 읽기 (죽기 직전의 커널 로그)
cat /sys/fs/pstore/dmesg-ramoops-0 | more

 

4. 온라인 출처 사례

The Linux Kernel Documentation (공식 문서)

• 설명: Ramoops의 모든 파라미터(mem_address, record_size 등)와 디바이스 트리 바인딩에 대한 가장 정확한 기준입니다.
• 실제 예제 코드: 문서 내 "Setting the parameters" 섹션에서 커맨드 라인 예제와 DTS 예제를 모두 제공합니다.
• 링크: Kernel.org Admin Guide - Ramoops

OpenWrt Wiki (네트워크 장비 적용)

• 사례: 공유기 등 임베디드 장비에서 커널 패닉 로그를 확보하기 위해 64KB의 아주 작은 메모리 영역(0x3f00000)을 할당하여 사용하는 실전 예제입니다.
• 링크: OpenWrt Wiki - Crashlog with pstore

https://youtu.be/X4P0jirfyro?si=YGg8v5MJgyCCT7gB

 

---

efi-pstore (UEFI NVRAM 사용)

대부분의 현대 x86 PC(서버, 데스크탑) 및 일부 ARM 서버가 사용하는 UEFI 펌웨어의 비휘발성 메모리(NVRAM)를 저장소로 사용합니다.

• 작동 방식: 커널이 죽기 전, 로그를 UEFI 변수(Variable) 형태로 NVRAM에 기록합니다.
• 특징: 전원을 껐다 켜도(Cold Boot) 데이터가 유지됩니다. 별도의 디스크 설정 없이 메인보드 기능만으로 작동합니다.
• 주의점:
  • NVRAM은 용량이 매우 작고(보통 64KB~128KB), 쓰기 수명 제한이 있습니다. 너무 자주 로그를 쓰면 메인보드가 고장 날 수 있어, 커널은 이를 방지하기 위해 중요 오류(Panic/Oops)만 기록하도록 제한합니다.
  • 커널 설정은 활성화되어 있는 경우가 많지만, firmware 지원 여부에 따라 실제 로그가 남지 않을 수 있습니다.
  • UEFI firmware가 EFI_VARIABLE_NON_VOLATILE 변수를 지원하는지, NVRAM 용량 제한, Secure Boot / firmware policy 에 따라 달라집니다.

설정 (Kernel Config)

CONFIG_EFI_VARS_PSTORE=y
CONFIG_EFI_VARS=y

 

ls -al /sys/fs/pstore/
-r--r--r-- 1 root root 2048 Dec 21 10:00 dmesg-efi-161358030901001
-r--r--r-- 1 root root 1800 Dec 21 10:00 dmesg-efi-161358030902002

---

pstore/blk (블록 디바이스 사용)

HDD, SSD, SD 카드, eMMC와 같은 블록 디바이스의 특정 파티션을 로그 저장소로 사용합니다.

• 작동 방식: panic_write와 같은 긴급 경로를 통해 파일시스템 레이어를 거치지 않고 디스크의 지정된 영역(Raw Sector)에 직접 씁니다.
• 특징: 용량이 넉넉하여 많은 로그(ftrace 등)를 저장할 수 있고 영구 보존됩니다.
• 주의점: 커널 패닉 상황에서 디스크 드라이버가 정상 작동한다는 보장이 없으므로(Deadlock 위험), ramoops보다는 성공률이 낮을 수 있습니다.

설정 (Kernel Config 및 Boot Args)

CONFIG_PSTORE_BLK=y

부트 파라미터로 사용할 장치를 지정해야 합니다. pstore_blk.blkdev=/dev/sda1 (또는 파티션 UUID)

 

ls -al /sys/fs/pstore/
-r--r--r-- 1 root root 65536 Dec 21 10:15 dmesg-pstore-blk-0

---

mtd-pstore (Flash 메모리 사용 - mtdoops)

임베디드 시스템에서 흔히 쓰는 Raw Flash 메모리(NOR/NAND)를 제어하는 MTD(Memory Technology Device) 서브시스템을 통해 로그를 저장합니다.

• 작동 방식: 플래시 메모리의 특정 파티션(예: "panic" 파티션)을 지정하여, 커널 웁스(Oops)나 패닉 발생 시 해당 영역에 텍스트를 씁니다.
• 특징: 별도의 파일시스템 없이 raw flash에 기록하므로 구조가 단순하고 영구적입니다.
• 주의점: 플래시 메모리도 쓰기 수명이 있으므로, 일반적인 로그 저장용이 아니라 패닉 상황에서만 써야 합니다.

설정 (Kernel Config)

CONFIG_MTD_PSTORE=y (또는 CONFIG_MTD_OOPS=y)

 

ls -l /sys/fs/pstore/
-r--r--r-- 1 root root 16384 Dec 21 10:30 dmesg-mtd-0

 

---

 

https://docs.kernel.org/power/shutdown-debugging.html