BlueberryLinux - Stardance

Ship #1 Changes requested

@zsigisti on BlueberryLinux · about 3 hours ago

Blueberry Linux is a source-built rolling x86-64 server distro I’ve been working on since May. It isn’t a respin of anything. It has its own package manager (bpm, written in Rust with streaming installs and SHA-256 verification), its own package format, and its own signed repository using an Ed25519 signature over the index.

There are 225 package recipes so far, from glibc and binutils upward.

It’s also self-hosted in the real sense. The base system is built from Blueberry packages using the Blueberry toolchain, and if a build falls back to a foreign bootstrap, that’s considered a build failure rather than a successful build.

I came back to the project after about a month away and spent some time auditing the live infrastructure before getting back to development. I fixed the repository issues I found, published nine package updates, and built something new: you can now try Blueberry directly in your browser at https://try.blueberrylinux.org.

The hardest part of this round was actually a near miss.

There’s an old copy of bpmrepo.sh sitting on the repository host that predates serial support. It doesn’t emit the |serial| line. It was sitting there looking perfectly usable, and it would have worked.

The problem is that using it would have silently removed rollback protection from the signed repository index. Nothing would have obviously failed. The index would still have been signed and the repository would still have worked.

I only caught it because I went back and checked what my own client actually expects instead of assuming the existing tool was the right one.

The browser shell also had two bugs that took a bit of debugging.

First, pty.fork() already calls setsid(), so I was calling it a second time. That resulted in EPERM and killed every session immediately after launch.

Then the xterm CDN URLs started returning 404s. The frontend failed before it could even display the actual error, so from the user’s perspective it just sat there saying “connecting…”.

I vendored the assets locally and changed the frontend to report asset loading failures properly.

The part I’m happiest with is how the browser environment is built.

The thing you’re running in the browser is actually assembled from the same packages the distro itself uses.

The isolation is also verified rather than assumed. From inside a live session, the router, the hypervisor, and 1.1.1.1 are all unreachable, and only three PIDs are visible.

If you want to try it, open https://try.blueberrylinux.org.

It’s a real shell on a real Blueberry rootfs.

There’s no network access, nothing persists between sessions, and each session is limited to ten minutes.

The source is available here: https://github.com/zsigisti/blueberry

1 devlog
45h

Try project → See source code →

Open comments for this post

@zsigisti on BlueberryLinux · about 4 hours ago

45h 18m 25s logged

Came back to Blueberry after a month and audited the live infrastructure before writing any code.State of the system: the distro is healthy. 225 recipes, valid index signature, and the main mirror is serving real packages.There were two actual issues.The published bpm.index was dated 31 July, so it was seven weeks stale. The other was blueberry-build.timer on the repo host, which had failed every hour since 29 June — 2,217 consecutive failures — because it was still trying to run blueberry-build-server.sh. I deleted that script during the .bpm migration and never disabled the unit.I also initially thought repo1 was broken. It isn’t. Its index is 0 bytes because it’s the BUR community mirror and nothing has been approved there yet. Nginx correctly returns 404 at the origin. That one was just me reading the state incorrectly.Both actual issues are now fixed.I disabled the timer rather than bringing the old script back. I also republished the index with a fresh serial using tools/release/repo-publish.sh. It re-indexes remotely using the hardened bpmrepo.sh, including a count-floor check, timestamped backup, and atomic index + signature swap.I almost used the wrong script. /opt/blueberry/tools/bpmrepo.sh is an orphaned copy from before serial support was added and doesn’t emit the |serial| line. Publishing with that one would have silently removed rollback protection from the signed index.I also did an upstream sweep. 110 of the 225 packages are currently outdated. The first scan hit 11 GitHub HTTP errors because of unauthenticated API rate limiting. Passing a token brought that down to one.I bumped and built nine packages from the current sources and published them:tzdata 2026b -> 2026dcurl 8.21 -> 8.22libcap 2.73 -> 2.78libxml2wireless-regdbless 668 -> 710jq 1.8.2htop 3.5.3nano 8.7.1All nine were built using the Blueberry toolchain with no bootstrap fallback. The changes are on branch pkg-bump-2026-09-20.Three automatic bumps produced incorrect source URLs. ca-certificates tried to fetch a 2026-08 PEM from the 2026-05 path, and expat tried to fetch 2.8.4 from the R_2_8_2 tag. Those were left unpublished rather than shipping the wrong tarball.sqlite needs a manual bump. openssl 3.4.6 -> 4.0.2, perl 5.40 -> 5.44, and gettext 0.26 -> 1.0 are ABI-level changes, so those will get separate passes.There’s also something new: you can try Blueberry directly in your browser.https://try.blueberrylinux.orgNo install and no signup. It’s a real shell running on a real Blueberry rootfs. The rootfs is about 480 MB, assembled by walking the dependency closure from bpm.index and pulling the packages directly from the live mirror. It contains 41 packages, including bpm 1.11.6.The frontend is xterm.js, with an aiohttp WebSocket connected to a PTY, served through Cloudflare.Each session gets an overlay over a read-only rootfs, its own network, PID, mount, and UTS namespaces, a 32 MB tmpfs, and a hard 10-minute limit. There are 12 concurrent sessions allowed, and sessions are torn down when the client disconnects.I also verified the isolation from inside a live session. The router, hypervisor, and 1.1.1.1 are unreachable, and only three PIDs are visible.There were two bugs while building the browser shell.First, pty.fork() already calls setsid(), so my additional setsid() call failed with EPERM and killed every session during startup. The server reported “operation not permitted” and closed the WebSocket before the shell even started.Second, the xterm CDN URLs were returning 404s. The page failed before it could report the error and just sat on “connecting…”. I vendored the assets locally and changed the frontend to report asset load failures explicitly.So the current state is: the repository is publishing again, the dead build timer is gone, the first batch of package updates is built and published, and Blueberry now has a browser-accessible shell for trying out the system without installing anything.