커뮤니티 솔루션

ZimaOS에서 apt와 yum이 작동하지 않는 이유: Buildroot, zpkg 모듈, 컨테이너 및 WebDAV

A November 2024-July 2025 thread where apt, apt-get, and yum failed because ZimaOS is Buildroot-based rather than Debian/Ubuntu. A later user wanted davfs2 for a host-level WebDAV mount so it would appear in Files. IceWhale did not provide an apt-style package-manager solution and instead explored container alternatives.

apt install, apt installapt-get update , yum install

ZimaOS에서 실패하는 이유는 ZimaOS가 Debian, Ubuntu, Fedora 또는 RHEL 스타일의 범용 배포판이 아니기 때문입니다. ZimaOS는 Buildroot를 기반으로 어플라이언스 OS로 빌드되며 대부분의 시스템 폴더를 읽기 전용으로 유지합니다.

현재 ZimaOS에는 특정 목적을 위한 패키지와 유사한 메커니즘이 있습니다. 특히 zpkg 모듈이 있으며, 일부 개발자 문서에서는 특수 도구에 Entware/opkg를 사용합니다. 그렇다고 기본 OS가 임의의 호스트 패키지를 Debian 패키지처럼 설치하고 통합할 수 있는 일반적인 변경 가능 Linux 배포판으로 바뀌는 것은 아닙니다.

사용자가 apt, apt-get 및 yum을 시도했습니다.

원래 2024년 게시물에서는 SSH를 통해 세 가지 패키지 관리자 방식을 모두 시도했지만 실패했다고 보고했습니다. 커뮤니티 답변에서는 ZimaOS가 Buildroot로 빌드되며 Linux, glibc, systemd, Docker 및 가상화 구성 요소를 Debian 스타일의 패키지 데이터베이스 없이 결합한다고 설명했습니다.

이러한 아키텍처 설명은 여전히 정확합니다.

현재 ZimaOS는 대부분의 시스템 경로를 읽기 전용으로 유지합니다. /DATA.

IceWhale의 현재 CLI 지침에는 대부분의 시스템 폴더가 root 권한으로도 읽기 전용 상태로 유지된다고 명시되어 있습니다. 사용자 데이터와 앱 데이터는 다음 경로 아래에 있어야 합니다.

현재 ZimaOS CLI 파일 시스템 모델을 참조하세요.

애플리케이션의 기본 확장 모델은 Docker입니다.

소프트웨어가 유지 관리되는 Docker 이미지 또는 Compose 스택으로 제공된다면, 일반적으로 ZimaOS에 가장 적합한 배포 방식은 Docker입니다. 종속성은 컨테이너 내부에 유지되며 기본 운영 체제를 수정하지 않습니다. davfs2 이 때문에 이후 WebDAV 요청에 대한 IceWhale의 답변에서는 사용자에게 설치하라고 안내하는 대신 Docker 기반 애플리케이션을 검토했습니다.

APT와 함께.

zpkg는 apt가 아닌 ZimaOS 모듈 관리자입니다. 현재 ZimaOS는 다음을 사용합니다. zpkg

이는 AI/검색 확장 기능 및 커뮤니티/공식 모듈처럼 임의의 Debian 패키지 이름을 설치 가능한 시스템 모듈의 일반적인 대체 수단으로 사용하는 방식이 아닙니다. 모듈은 ZimaOS 확장 메커니즘에 맞게 빌드되며 자체 서비스 정책을 포함할 수 있습니다. davfs2 설치할 수 있습니다.

IceWhale, 특수 개발 환경을 위한 opkg도 문서화

현재 IceWhale Python/개발자 지침에는 Entware를 다음 위치에 설치하는 방법이 나와 있습니다. /opt 그리고 다음을 사용한 뒤 opkg 다음과 같은 개발자 유틸리티: git-http.

이는 해당 가이드에서 지원되는 고급 사용 패턴일 뿐이며, Entware에서 설치한 모든 Linux 데몬이 ZimaOS의 부팅, Files, 네트워킹 또는 스토리지 서비스와 안전하게 통합된다고 가정해도 된다는 의미는 아닙니다.

의도한 사용 사례에 부합하는 경우에만 현재 Entware/opkg 개발 워크플로를 사용하세요.

이후의 WebDAV 요청에는 호스트 수준 통합이 필요했습니다

2025년에 사용자는 운영 체제 수준에서 WebDAV 클라우드 드라이브를 마운트하여 ZimaOS Files 환경과 다른 앱에서 액세스할 수 있기를 원했습니다. 또한 별도의 AList 방식 앱은 동등한 대안이 아니라고 명시했습니다.

그 요구 사항은 “WebDAV 클라이언트 컨테이너를 실행”하는 것보다 더 어렵습니다. 컨테이너 마운트가 자동으로 Files와 다른 모든 컨테이너에서 보이는 네이티브 호스트 마운트가 되지는 않기 때문입니다.

컨테이너로도 일부 WebDAV 워크플로를 해결할 수 있습니다

실제 목적이 WebDAV 공급자에서 데이터를 탐색, 동기화 또는 복사하는 것이라면 호스트를 변경하는 것보다 컨테이너화된 도구가 더 안전할 수 있습니다. 예로 WebDAV를 직접 지원하는 동기화 클라이언트, 파일 관리자 또는 백업 도구가 있습니다.

컨테이너에 필요한 ZimaOS 폴더만 매핑하고 공급자 자격 증명은 보호된 앱 설정에 보관하세요.

소프트웨어에 일반적인 변경 가능한 Linux 호스트가 필요한 경우 VM을 사용하세요

워크플로가 실제로 필요한 경우 apt install davfs2, 시스템 패키지, FUSE/커널 동작 또는 사용자 지정 부팅 서비스가 필요한 경우 Debian/Ubuntu VM이 더 깔끔한 경계가 될 수 있습니다. 게스트 내부에서는 게스트 자체가 Debian/Ubuntu이므로 일반적인 패키지 관리가 지원됩니다.

그런 다음 필요하다면 의도적인 네트워크/스토리지 프로토콜을 통해 마운트된 데이터를 ZimaOS 또는 다른 클라이언트에 다시 제공하세요.

호스트 수정 사항은 변경 불가능한 수명 주기를 견뎌야 합니다

고급 우회 방법으로 바이너리를 다음 아래에서 사용할 수 있게 하더라도 /opt 또는 /DATA, 다음을 확인하세요:

  • 재부팅 후 서비스가 시작되어야 합니다.
  • OTA 업데이트 후에도 유지되어야 합니다.
  • 자격 증명이 안전하게 유지되어야 합니다.
  • 종속된 앱이 시작되기 전에 마운트가 존재해야 합니다.
  • 실패해도 앱이 비어 있는 로컬 마운트 지점에 데이터를 쓰지 않도록 해야 합니다.

호스트 마운트가 자동으로 Files 통합이 되는 것은 아닙니다

ZimaOS Files는 자체 스토리지 및 네트워크 위치 모델을 사용하는 네이티브 서비스입니다. 셸에서 사용자 지정 FUSE/WebDAV 마운트를 생성해도 해당 마운트가 일급 Files 위치로 표시되거나 동일한 권한 및 수명 주기 관리를 받는다는 보장은 없습니다.

ZimaOS 패키지 관리자 FAQ

ZimaOS에서 apt가 작동하지 않는 이유는 무엇인가요?

ZimaOS는 Buildroot 기반이며 Debian/Ubuntu의 APT 패키지 관리 아키텍처를 사용하지 않습니다.

zpkg가 apt를 완전히 대체하는 범용 도구인가요?

아니요. zpkg는 플랫폼의 모듈 시스템용으로 빌드된 ZimaOS 모듈을 설치합니다.

IceWhale이 opkg를 문서화한 적이 있나요?

Entware를 사용하는 특수한 개발자/Python 설정에서는 다음 아래 /opt. 그렇다고 기본 OS가 일반적인 변경 가능한 배포판이 되는 것은 아닙니다.

특정하게 davfs2나 다른 호스트 데몬이 필요한 경우에는 어떻게 하나요?

사용 가능한 경우 지원되는 컨테이너/모듈을 우선 사용하고, 워크플로가 일반적인 패키지 관리와 호스트 서비스를 실제로 필요로 할 때는 범용 Linux VM을 실행하세요.