Create NetizenOS-base chroot using debos #4

Closed
opened 2026-04-23 23:16:40 +01:00 by bits · 5 comments
Owner

Create a reduced Debian-based OS that will be one of the foundations of NetizenOS. We want to follow some of the existing Debian-reduction practices that already exist.

The goals of a reduced Debian are as follows:

  • smaller binary footprint - less program binaries make downloads faster and able to fit on systems with smaller disk, meaning more people can run it on constrained hardware
  • smaller execution footprint - less unused programs means less memory and cpu wasted
  • increased auditability - less unused programs means fewer programs to read through and verify
  • increased security - less unused daemon, library, or service means smaller attack surface with fewer potential vulnerabilities
  • clarity of purpose - a focused deliberate OS signals design intent so new contributors can better understand what the project is and isn't. There's no ambiguity buried under layers of general-purpose tooling
  • lower maintenance burden - fewer upstream dependencies to track, patch, and test
  • community coherence - contributors tend to share a tighter common context. Discussions, documentation, and onboarding are more focused, and it's easier to build shared expertise.
  • composability - minimal systems tend to embrace Unix philosophy — small tools that do one thing well. This aligns naturally with open source culture and makes it easier for community members to swap components or extend functionality without touching unrelated parts of the stack.

The community coherence through increased auditability, security, and clarity of purpose in particular will become a critical part of community maintenance. I want core OS issues and patches to be uniform, quickly discoverable, addressable, and easily documented and understood. This is core to the Netizen philosophy that more enabled minds means faster and trusted resolutions.

[ Minimal Base OS ]
        |
[ Core Config Layer ]  ← shared, community-maintained
        |
   ┌────┴─────────────────┬───────────────────┬───────────────────────┐
[Hypervisor]           [Router]       [Netboot-k3s-controller]     [k3s]

Using mmdebstrap, produce a minimal Debian chroot (root fileystem for Linux) — just enough to boot and run apt. No desktop, no recommended packages, no extras.

Here's a basic starter guide.

mmdebstrap --variant=apt trixie ./rootfs

--variant=apt gives you truly the floor — only Essential: yes packages, their hard dependencies, and apt. Around 100MB. Everything else is intntional.

Create a reduced Debian-based OS that will be one of the foundations of NetizenOS. We want to follow some of the [existing Debian-reduction](https://wiki.debian.org/ReduceDebian) practices that already exist. The goals of a reduced Debian are as follows: * **smaller binary footprint** - less program binaries make downloads faster and able to fit on systems with smaller disk, meaning more people can run it on constrained hardware * **smaller execution footprint** - less unused programs means less memory and cpu wasted * **increased auditability** - less unused programs means fewer programs to read through and verify * **increased security** - less unused daemon, library, or service means smaller attack surface with fewer potential vulnerabilities * **clarity of purpose** - a focused deliberate OS signals design intent so new contributors can better understand what the project is and isn't. There's no ambiguity buried under layers of general-purpose tooling * **lower maintenance burden** - fewer upstream dependencies to track, patch, and test * **community coherence** - contributors tend to share a tighter common context. Discussions, documentation, and onboarding are more focused, and it's easier to build shared expertise. * **composability** - minimal systems tend to embrace Unix philosophy — small tools that do one thing well. This aligns naturally with open source culture and makes it easier for community members to swap components or extend functionality without touching unrelated parts of the stack. The community coherence through increased auditability, security, and clarity of purpose in particular will become a critical part of community maintenance. I want core OS issues and patches to be uniform, quickly discoverable, addressable, and easily documented and understood. This is core to the Netizen philosophy that more enabled minds means faster and trusted resolutions. ``` [ Minimal Base OS ] | [ Core Config Layer ] ← shared, community-maintained | ┌────┴─────────────────┬───────────────────┬───────────────────────┐ [Hypervisor] [Router] [Netboot-k3s-controller] [k3s] ``` ~~Using [`mmdebstrap`](https://manpages.debian.org/trixie/mmdebstrap/mmdebstrap.1.en.html), produce a minimal Debian chroot (root fileystem for Linux) — just enough to boot and run apt. No desktop, no recommended packages, no extras.~~ ~~Here's a [basic starter guide](https://ostechnix.com/create-chroot-environments-using-mmdebstrap-in-debian-linux/).~~ ~~`mmdebstrap --variant=apt trixie ./rootfs`~~ ~~`--variant=apt` gives you truly the floor — only Essential: yes packages, their hard dependencies, and apt. Around 100MB. Everything else is intntional.~~
Author
Owner
Also look at some of the bootstrap steps done in these to see if there's anything new. https://galaxy.ansible.com/ui/standalone/roles/HanXHX/debian_bootstrap/documentation/ https://galaxy.ansible.com/ui/standalone/roles/pythoniccafe/debian_bootstrap/documentation/
Author
Owner

Maybe we should consider debos instead which wraps mmdebstrap.

Debos doesn't have a native qcow2 export action — but it's a one-step conversion after the fact. The output formats debos directly supports are: tarballs via pack, bootable disk images via image-partition + filesystem-deploy, and OSTree commits via ostree-commit. GitHub
The Pattern for qcow2
You produce a raw disk image from debos, then convert it:

# In your debos recipe
- action: image-partition
  imagename: trixie-base.img   # raw image
  imagesize: 4GB
  partitiontype: gpt
  partitions:
    - name: EFI
      fs: vfat
      start: 0%
      end: 512MB
      flags: [boot]
    - name: root
      fs: ext4
      start: 512MB
      end: 100%

- action: filesystem-deploy

Then after debos finishes, one qemu-img command converts it:

qemu-img convert -f raw -O qcow2 trixie-base.img trixie-base.qcow2
Maybe we should consider [debos](https://manpages.debian.org/trixie/debos/debos.1.en.html) instead which wraps `mmdebstrap`. Debos doesn't have a native qcow2 export action — but it's a one-step conversion after the fact. The output formats debos directly supports are: tarballs via pack, bootable disk images via image-partition + filesystem-deploy, and OSTree commits via ostree-commit. GitHub The Pattern for qcow2 You produce a raw disk image from debos, then convert it: ``` # In your debos recipe - action: image-partition imagename: trixie-base.img # raw image imagesize: 4GB partitiontype: gpt partitions: - name: EFI fs: vfat start: 0% end: 512MB flags: [boot] - name: root fs: ext4 start: 512MB end: 100% - action: filesystem-deploy ``` Then after debos finishes, one qemu-img command converts it: ``` qemu-img convert -f raw -O qcow2 trixie-base.img trixie-base.qcow2 ```
Author
Owner

Outside of debos there is mkosi, which has a larger set of features, such as exporting directly to qcow2 and so many more.

The reason I am not choosing this one is that I want to continue prioritizing simplicity and minimal design by keeping tools Debian-focused. Using Debian specific tooling lowers the temptation to complicate things with other operating systems that solve some bespoke issue but will make maintenance more difficult in the future.

Depending on a tool with fewer feature keeps the scope focused and dependency low.

Also the licensing for mkosi is rather strange and debops is simply a permissive Apache 2.0 license.

Outside of [`debos`](https://github.com/go-debos/debos) there is [`mkosi`](https://github.com/systemd/mkosi), which has a larger set of features, such as exporting directly to `qcow2` and so many more. The reason I am not choosing this one is that I want to continue prioritizing simplicity and minimal design by keeping tools Debian-focused. Using Debian specific tooling lowers the temptation to complicate things with other operating systems that solve some bespoke issue but will make maintenance more difficult in the future. Depending on a tool with fewer feature keeps the scope focused and dependency low. Also the licensing for mkosi is rather strange and debops is simply a permissive Apache 2.0 license.
bits changed title from Create NetizenOS-base chroot using mmdebstrap to Create NetizenOS-base chroot using debos 2026-04-24 21:45:45 +01:00
Author
Owner

Closed with 52c1cbe7a1

Closed with https://git.neti.center/bits/neticenter/commit/52c1cbe7a1c4880eb8ab2ddef12605da58107ac8
bits closed this issue 2026-06-02 05:22:04 +01:00
Author
Owner
Added a bunch of considerations around base OS https://wiki.debian.org/AptConfiguration#apt.conf https://askubuntu.com/questions/179060/how-to-not-install-recommended-and-suggested-packages https://wiki.debian.org/ReduceDebian#Remove_non-critical_packages https://manpages.debian.org/bookworm/systemd-resolved/systemd-resolved.service.8.en.html
Sign in to join this conversation.
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
bits/neticenter#4
No description provided.