먼저 전체 호스트 잠금과 네트워크 장애를 구분하세요
보고된 시스템은 네트워크 액세스, ping, 컨테이너, 로컬 콘솔 응답 및 영상 출력을 모두 잃었습니다. 이는 SMB, Docker 또는 NIC 장애의 범위를 넘어서는 현상이며, 전원 주기가 필요한 완전한 호스트 잠금과 일치합니다.
서버가 원격에서 사라진 경우, 교체용 NIC를 구매하기 전에 로컬 콘솔과 디스플레이를 확인하세요. 콘솔이 응답하면 조사의 초점은 네트워킹으로 향하고, 콘솔이 멈추고 디스플레이도 사라졌다면 커널, 펌웨어, 전원, 스토리지 또는 하드웨어 문제일 가능성이 높습니다.
정확한 이벤트 시간과 시스템이 스스로 재부팅했는지, 아니면 전원은 켜진 상태에서 응답하지 않았는지를 기록하세요. 이러한 관찰 결과에 따라 어떤 이전 부팅 구간과 외부 모니터링 데이터를 비교할지 결정됩니다.
변수를 변경하기 전에 이전 부팅의 증거 수집
해당 주제에서 처음 수집한 유용한 정보는 다음과 같습니다. journalctl -b -1부팅부터 멈춤으로 끝난 부팅의 커널 및 우선순위가 높은 메시지를 포함합니다. 이후 ZimaOS 팀은 비공개 검토를 위해 이전 부팅에서 마지막 500개 항목과 영구 저널을 요청했습니다.
로그를 공개적으로 게시하기 전에 개인정보가 포함되어 있는지 검토하세요. 이 경우 영구 저널링이 활성화되어 있었지만, 패닉, OOM 킬, GPU 재설정, 스토리지 오류, 온도 이벤트, 워치독 잠금 또는 정상 종료 없이 관찰된 장애 시점에 로그가 갑자기 중단되었습니다.
최종 기록이 비어 있다고 해서 아무것도 실패하지 않았다는 뜻은 아닙니다. 이는 사용 가능한 로컬 로깅 경로가 원인을 기록하기 전에 호스트가 중지되었음을 보여 줍니다. 동일하게 아무 기록도 남기지 않는 잠금이 발생할 때마다 같은 로그 명령을 반복하는 것은 캡처 방법을 바꾸지 않는 한 큰 의미가 없습니다.
GPU 및 Frigate 테스트로는 해결책을 찾지 못함
시스템은 Intel i915 그래픽과 Frigate VAAPI를 사용하고 있었으므로, 작성자는 먼저 GPU 가속을 비활성화했습니다. 그래도 호스트는 멈췄습니다. Frigate를 완전히 중지했을 때 한 차례 더 긴 간격이 발생했지만, 이후 테스트로는 Frigate가 원인이라는 사실이 입증되지 않았습니다.
작성자는 i915를 비활성화하는 방법도 시도했지만, 이로 인해 다른 워크로드를 사용할 수 없게 되었고 시스템은 결국 다시 충돌했습니다. 따라서 이 사례에서는 “i915 비활성화”가 성공적인 해결 방법이 아님을 알 수 있습니다.
OpenMediaVault와의 비교는 의미가 있었습니다. 동일한 하드웨어와 Frigate 구성이 그곳에서는 안정적으로 작동했기 때문입니다. 이는 ZimaOS에 특화된 커널 또는 드라이버 상호작용을 의심하게 하지만, 그 자체로 어떤 구성 요소가 실패했는지는 밝혀 주지 않습니다.
IOMMU, VFIO 및 SATA LPM 제안은 해결책으로 배제됨
ZimaOS에는 처음에 다음이 포함되어 있었습니다. intel_iommu=on 및 vfio_iommu_type1.allow_unsafe_interrupts=1. 팀원 한 명이 작성자에게 두 항목을 모두 제거해 달라고 요청했습니다. 활성 명령줄에는 해당 항목이 없다는 것이 확인되었지만 시스템은 다시 잠겼습니다.
작성자는 이어서 다음을 테스트했습니다. libata.force=nolpm 데이터 디스크가 M.2-SATA 어댑터를 사용했기 때문입니다. 다음 날 아침 또 다른 멈춤이 발생했습니다. 따라서 이 스레드는 두 부팅 매개변수 변경 중 어느 것도 해결책이라고 뒷받침하지 않습니다.
이 테스트는 업데이트가 실험을 무효화할 수 있는 이유도 보여 줍니다. 한 업데이트가 사용자 지정 명령줄 파일을 덮어쓴 사례가 있었습니다. 가동 시간을 해석하기 전에 활성 부팅 명령줄을 항상 확인하고, 확립된 충돌 발생 시간대 동안 한 번에 하나의 변수만 변경하십시오.
영구 저널, pstore 및 원격 포워딩도 한계에 도달함
커널에는 pstore와 하드/소프트 락업 감지 기능이 포함되어 있었고 NMI 워치독도 활성화되어 있었습니다. 그러나 /sys/fs/pstore 충돌 후에도 비어 있었고, kdump용 충돌 커널도 예약되지 않았습니다.
부팅 시 netconsole은 구성을 해석했지만 다음보다 먼저 시작되었습니다. eth0 이 존재했으며 스스로 비활성화되었습니다. 사용자 공간 journalctl-UDP 포워더가 두 번째 Linux 시스템에 도달했지만, 호스트가 멈췄을 때 최종 원인 없이 역시 중단되었습니다.
이 결과는 유용합니다. 스케줄러나 네트워크 스택이 중단된 후에는 사용자 공간 포워딩으로 메시지를 보낼 수 없으며, 발생하지 않은 커널 경고를 만들어 낼 수도 없습니다. 이 시점에서는 동일한 사용자 공간 캡처를 또 수행하는 것보다 공급업체 디버그 커널이나 표적 계측이 더 가치 있습니다.
ZimaOS 1.7.1에서 의심되는 구성 요소가 변경되었지만 아직 검증되지는 않음
ZimaBoard 2의 두 번째 사용자가 멈춤 직전에 Python 및 기타 프로세스가 반복적으로 충돌했다고 보고했습니다. ZimaOS 팀은 다음에서 Crudini 종속성을 제거했다고 밝혔습니다. zimaos-welcome해당 서비스의 리소스 요청 빈도를 줄였으며, 변경 사항을 테스트 릴리스에 반영할 계획이었습니다.
팀은 이후 Crudini 문제가 단지 트리거였으며 실제 시스템 충돌 원인은 여전히 조사 중이라고 명확히 밝혔습니다. 또한 ZimaOS 1.7.1에서는 컨테이너 시작을 개선하고 DBus 브로커 메시지 차단 가능성을 줄이기 위해 Docker Engine 버전을 롤백했습니다.
마지막 게시물은 다른 사용자가 1.7.1에서 안정적으로 사용 중인지 묻지만, 필요한 가동 시간 결과는 제공하지 않습니다. 원래의 장애 조건이 이전 발생 시간보다 긴 기간 동안 안정적으로 유지되기 전까지는 1.7.1을 멈춤 문제의 확정적인 해결책이라고 설명하지 마세요.
이미 배제된 테스트와 함께 에스컬레이션하기
강력한 지원 자료에는 하드웨어 모델, ZimaOS 및 커널 버전, 스토리지 컨트롤러, 워크로드, 충돌 시각, 활성 부팅 매개변수, 이전 부팅 로그, 그리고 결과와 함께 통제된 테스트 목록이 포함됩니다.
이 소스 사례에서는 GPU 가속, Frigate 격리, IOMMU/VFIO 매개변수 제거, i915 비활성화, SATA LPM 변경, 영구 로그, pstore, 원격 사용자 공간 로깅으로 확실한 복구가 확인되지 않았음을 명시하세요.
동일한 워크로드에서 다른 운영 체제는 안정적으로 작동하는 반면 ZimaOS가 계속 멈춘다면, 해당 비교 결과를 보존하고 맞춤형 빌드 또는 공급업체 조사를 요청하세요. 안정성이 운영상 중요한 경우, 검증되지 않은 매개변수를 계속 추가하기보다 안정적인 환경으로 되돌리는 것이 유효한 중단 기준입니다.
FAQ
Frigate 또는 Intel VAAPI가 ZimaOS 충돌을 일으켰나요?
그 내용은 입증되지 않았습니다. GPU 가속을 비활성화한 후에도, 그리고 추가적인 i915 격리 테스트 후에도 충돌이 계속되었습니다.
IOMMU 및 VFIO 매개변수를 제거하면 멈춤 문제가 해결되었나요?
아니요. 활성 명령줄에서 두 항목이 모두 제거된 것이 확인되었지만, 호스트는 다시 멈췄습니다.
ZimaOS 1.7.1에서 시스템 전체 멈춤 문제가 해결되었나요?
릴리스에서 Crudini가 변경되었습니다. zimaos-welcome, Docker Engine 및 DBus 관련 동작이었지만, 안정성 회복을 확인하는 결과가 나오기 전에 주제가 끝났습니다.
