본문으로 건너뛰기
피드

FreeBSD 15.0을 150MB까지 줄여보는 실험

devops 약 4분
vote
0
댓글
북마크

FreeBSD 15.0-RELEASE를 PKGBASE로 설치 후 불필요한 패키지를 제거해 루트 파일시스템을 150MB까지 줄인 과정. pkg 의존성 함정, SQLite DB 직접 수정으로 upgrade 복원 방지까지 다룸.

  • 1

    기본 PKGBASE 설치 450MB에서 devel/optional 셋 제거로 150MB 달성

  • 2

    pkg 동작에 필요한 숨겨진 의존성 5개를 lock으로 보호

  • 3

    pkg SQLite DB에서 set-devel 의존성 직접 삭제해 upgrade 시 복원 방지

  • 4

    커널 모듈 40MB + pkg-static 13MB 추가 제거 시 100MB 이하도 가능

FreeBSD 15.0을 150MB까지 줄여보기

  • FreeBSD 15.0-RELEASE를 PKGBASE로 설치한 뒤, 불필요한 패키지를 제거해서 루트 파일시스템을 150MB까지 줄인 실험기. ZFS zstd-19 압축 사용 기준

  • 일반적인 PKGBASE 설치([X] base 옵션)는 450MB를 차지함. 여기서 FreeBSD-set-develFreeBSD-set-optional 셋을 제거하면 150MB까지 내려감

삭제 과정의 함정들

  • pkg가 동작하려면 FreeBSD-libarchive, FreeBSD-openssl-lib가 필요한 건 금방 파악됨. 하지만 이것만 잠그고 나머지를 삭제하면... liblzma.so.5가 없다면서 libarchive.so.7이 뻗음

  • 숨겨진 의존성이 더 있었음: FreeBSD-xz-lib, FreeBSD-libucl, FreeBSD-libcasper도 잠가줘야 pkg가 살아남음. "경험이란 건 필요한 순간 직후에 얻는 법"이라는 저자의 자조가 웃김

  • 실제 잠가야 하는 패키지 목록:

    • FreeBSD-libarchive
    • FreeBSD-openssl-lib
    • FreeBSD-xz-lib
    • FreeBSD-libucl
    • FreeBSD-libcasper

pkg upgrade가 다 되돌리려는 문제

  • 패키지를 열심히 지워놨더니 pkg upgrade 하면 73개 패키지를 다시 깔겠다고 나옴. 458MB 추가 필요하다면서
  • 해결책: pkg의 SQLite DB(/var/db/pkg/local.sqlite)를 직접 열어서 FreeBSD-set-develFreeBSD-set-base 의존성을 삭제함
    delete from deps where origin = "base/FreeBSD-set-devel";
  • 이후 pkg upgrade 시 73개 → 4개 패키지만 설치 시도. 깔끔해짐

더 줄일 수 있나?

  • 커널 모듈(/boot/kernel) 중 안 쓰는 것만 해도 약 40MB. QAT 펌웨어, 무선 NIC 드라이버(iwm, iwn 시리즈), 네트워크 드라이버(if_*) 등이 대부분
  • pkg-static 바이너리가 13MB를 차지하는데, 이것까지 빼면 100MB 아래도 가능함

ℹ️참고

> 저자도 인정하듯이 이건 "비지원(unsupported)" 구성이고, PKGBASE가 원래 모듈성보다는 패키징/업그레이드/무결성을 목표로 설계된 거라 "2026년에 3.5인치 플로피에 OS 넣을 일은 없다"는 현실적 코멘트도 덧붙임. 그래도 이런 실험 자체가 시스템을 이해하는 데 좋은 연습이긴 함.

실용성보다는 시스템 내부 구조를 이해하는 연습으로서 가치 있는 실험. PKGBASE가 모듈성보다 패키징/업그레이드 무결성을 목표로 설계됐다는 점을 잘 보여줌.

댓글

댓글

댓글을 불러오는 중...

devops

포드가 AI 데이터센터 붐 수혜주로 뜬 이유는 자동차가 아니라 ESS였다

포드의 에너지 저장 사업이 AI 데이터센터 건설 붐을 타고 새 성장축으로 주목받고 있어. 전기차 수요 둔화로 남는 배터리 생산능력을 데이터센터·전력망용 ESS로 돌리는 전략이고, EDF 북미 사업체에 2028년부터 연간 4기가와트시 규모 공급 계약까지 체결했어.

devops

클라우드 빅3 차별화 논쟁, 정작 컴퓨트·스토리지는 거의 범용재가 됐다는 얘기

클라우드 업체들은 인공지능, 데이터베이스, 전용 서비스로 차별화를 강조하지만, 대부분의 기업 워크로드는 여전히 컴퓨트와 스토리지 위에서 돌아간다는 주장이다. AWS, 애저, 구글 클라우드의 핵심 인프라는 성숙도가 높아져 실질 역량 차이가 줄었고, 아키텍트는 브랜드보다 워크로드 적합성·비용·거버넌스·운영 정합성을 봐야 한다는 내용이다.

devops

DynIP, RFC 2136·IPv6·DNSSEC 지원하는 동적 DNS 서비스 공개

DynIP는 홈랩, 엣지 라우터, 인프라 팀을 겨냥한 동적 DNS(DDNS) 서비스다. 60초 안팎의 전파, RFC 2136 TSIG 기반 라우터 업데이트, 개인 도메인 연결, IPv6와 DNSSEC 지원을 핵심 기능으로 내세운다.

devops

깃허브 액션, 내부 데이터베이스 마이그레이션 여파로 4시간 지연

깃허브에서 2026년 5월 12일 13:41부터 17:43 협정세계시까지 일부 서비스 처리 지연이 발생했음. 내부 데이터베이스 마이그레이션으로 복제 지연이 생겼고, 작업 큐에 쌓이는 요청을 처리할 워커가 부족해진 게 원인이었음.

devops

AI 강국 경쟁, 결국 전기와 데이터센터 싸움으로 간다

AI 경쟁의 핵심이 모델과 반도체만이 아니라 안정적인 전력 확보로 이동하고 있다는 분석이야. 글로벌 데이터센터 전력 사용량은 2024년 400TWh에서 2030년 800TWh, 2050년 3500TWh 이상으로 커질 전망이고, 한국도 AI 데이터센터와 에너지 전략을 같이 설계해야 하는 상황이야.