CosmoOS 1.0.10

CosmoOS 1.0.10

fsck at boot and scrub --repair

The root is checked on every boot, before it is mounted. Init runs
the kernel's own structural check on the root's pool, read-only, and
prints one line:

cosmofs: root checked, 0 findings, 0 repaired

What a crash or a bookkeeping slip leaves is repaired without asking:
blocks allocated that nothing uses, a wrong total, a stale rollback
record or hold, a snapshot's identity -- and, named by inode on the
console, an inode no name reaches or a wrong link count. Anything else is
a question about which of two things is real, and the boot does not
answer it: the root is refused, the class is named, and you are left at
the live system's shell with the pool unmounted and the command to run:

cosmofs: root refused: cross-linked; vda2 is not mounted. From this shell: fsck.cosmofs --repair vda2

fsck=check on the kernel command line reports and repairs nothing;
fsck=skip does not check.

fsck.cosmofs checks a pool nothing has mounted. fsck.cosmofs --check DEVICE writes nothing; --repair repairs what has one right
answer -- including, offline only, a block in use that the allocator
calls free -- and reports the rest. It is the kernel's checker, through
/dev/fsctl, not a copy of it. Its output names each finding with its
class, the block or inode and what was done, one line each, and its exit
status is fsck's: 0 nothing found, 1 all repaired, 4 findings left, 8
could not check.

fsctl scrub reports; fsctl scrub --repair repairs. The scrub
reads every block of every tree -- the live one and each snapshot's --
on every copy, and on a mirror rewrites a bad copy from a good one only
when asked. It reads at most fs.scrub_rate blocks a second (4096,
16 MiB, unless set with sysctl) and steps aside between tenths of a
second, so the programs using the pool keep going. mkfs.cosmofs --mirror A B makes a two-way mirror.

See the guide's new page, Checking and repairing.

Fixes

• A read-only mount writes nothing. Mounting a cosmofs read-only used
  to write the replay of what the last commit freed, or of inodes deleted
  while open, at unmount; it now does that in memory only.
• A root that is not a directory is refused, not a panic. One changed
  mode byte on a disk stopped the kernel when the root was mounted.
• An allocation that fails no longer throws away the open
  transaction. A file whose extent map needed a new block, or an
  inode's map path, at a moment memory was short failed every change
  after it until the next unmount; the operation now fails alone and can
  be retried.
• Older-format pools stay readable by their kernels: a pool below
  format 6 no longer gets compressed records.
• The scrub's counts reach you when it finds damage, and it no longer
  reports blocks it is still writing as unrecoverable.
• A rollback left pending says why. When the mount could not apply a
  pending rollback (no room), init's line now ends with the reason.

Upgrading from v1.0.9

cosmo-upgrade --fetch v1.0.10, reboot, then pkg update && pkg upgrade. The upgrade takes a boot environment, so cosmo-upgrade --rollback returns the root and the boot set as they were. The first boot
of v1.0.10 checks the root before it mounts it; a root an older kernel left
with findings a boot may repair is repaired then, and the line says so.

Tested: on every change, on both architectures, make test-fsck (the
installed root damaged 23 ways and booted; scrub --repair on a mirror)
beside the release tests; and on a Parallels virtual machine, upgraded from
v1.0.9 to v1.0.10-rc1 before this release was tagged.

About CosmoOS

CosmoOS 1.0.10: the 1.0 roadmap completed. CosmoOS installs to a disk, reboots into it, is used through BusyBox ash, keeps files across reboots, reaches the network by name, accepts an ssh login, and has a verified boot chain and sound randomness, on x86-64 and AArch64 under QEMU.

Start with the user guide. Each architecture's files: cosmoos-ARCH.img (the signed live image), its UEFI loader, kernel.elf, boot.tar, cmdline, the signed manifest, cosmo-upgrade and its signed package. SHA256SUMS.sig is SHA256SUMS's detached signature with the release key below (scripts/modsign.py verify-detached, or cosmo-verify on an installed system); check the files with sha256sum --ignore-missing -c SHA256SUMS.

Release signing key

The loader in these images verifies the kernel, boot archive and command line against this Ed25519 key (and the kernel trusts it for modules and packages):

• public key: d2c778bcb38775790b6b6e843631bd2e76d6a29ec52296ece6e2d67c1bef41f8
• key id: 36ae7bb4947896ab (the first 8 bytes of SHA-512 of the key; the boot log prints it: verified boot, key 36ae7bb4947896ab)
• in the repository: tools/keys/release-2026.pub

Toolchain

Built and tested in the project's CI images (ci/Dockerfile), pinned by digest:

• toolchain: ghcr.io/vkuttyp/cosmoos-ci@sha256:f6aee1470b952bdb426b8d55cfcccb734c9c1f4dac50c89edefba4e8be3be385
• litmus: ghcr.io/vkuttyp/cosmoos-ci@sha256:c8b16f9c652cd99e4a557c08adc451528cc9cd36ba0e9e37b2973feffb15a5a9
• clang 1:19.0-63
• lld 1:19.0-63
• llvm 1:19.0-63
• qemu-system-x86 1:10.0.13+ds-0+deb13u1
• qemu-system-arm 1:10.0.13+ds-0+deb13u1
• ovmf 2025.02-8+deb13u1
• qemu-efi-aarch64 2025.02-8+deb13u1
• mtools 4.0.48-1
• python3 3.13.5-1
• clang-19 1:19.1.7-3+b1
• lld-19 1:19.1.7-3+b1
• llvm-19 1:19.1.7-3+b1

Third-party sources

Fetched and checked against these SHA-256 digests (ports/busybox/busybox.mk, ports/dropbear/dropbear.mk, ports/openssh/openssh.mk, ports/mbedtls/mbedtls.mk):

Source	Version	SHA-256
BusyBox	1.37.0	3311dff32e746499f4df0d5df04d7eb396382d7e108bb9250e7b519b837043a4
musl	1.2.5	a9a118bbe84d8764da0ea0d28b3ab3fae8477fc7e4085d90102b8596fc7c75e4
compiler-rt	19.1.7	c12b6e764202c615c1a3af9a13d477846878757ae0e29e5f8979215a6958fffc
dropbear	2026.94	e098034a843699200c8c977a991fff73159735bf795d5f72ef672c41a6b1ae81
OpenSSH portable (sftp-server only)	10.6p1	a9dc9565dffe8640f64d863cd29a32bc4a3dbdec0566a7fc44c5d6ee767d5f39
mbedTLS	3.6.7	a7e8bcbec0e6f761b4af24f25677626b35f762f68eef79c08677a363212d11f6
CA certificates (curl's extract of Mozilla's)	2026-09-25	a41b5d356aea97a529fe27e0f7316d2f9d946d75927476cf9cf1b90637d00505

Reproducibility

Each architecture was built twice from the tag v1.0.10, in two fresh containers of the toolchain image above, with the release key; every file below was identical in both:

• x86_64: two builds, 10 files each, identical; cosmoos-x86_64.img sha256 c6b379efd47c534ca7ff71ed6144a2665389f170548b4a6d6755d183d2b4b78f
• aarch64: two builds, 10 files each, identical; cosmoos-aarch64.img sha256 377a9529dd159b361c25771ecc52a65227480d61dedd67c3818c66af73053427

To rebuild: check out the tag, run the toolchain image above, and make ARCH=<arch> SIGNING=release MODSIGN_KEY=<key> KEYRING_PUBS=tools/keys/release-2026.pub release. Without the private key, a build with your own key differs in what the key reaches: the key ring compiled into the kernel and loader, the signatures on modules, packages and the manifest, and the archive and image that hold them.

SHA256SUMS

c6b379efd47c534ca7ff71ed6144a2665389f170548b4a6d6755d183d2b4b78f  cosmoos-x86_64.img
115ef94c7916d2ba01ed3127701506beb2cc8199f6835a4e4489966fa34ffb67  cosmoos-x86_64-BOOTX64.EFI
1e9ef09738ddc030e721e7a48fe35cfae0c90211377c6311af36fb0860403f3f  cosmoos-x86_64-kernel.elf
56ebca11eba13e474d679be2ae5ffee00cc2f7900bdceb0cdec4a8d8993ef8be  cosmoos-x86_64-boot.tar
7a77470be4312a22db40932c6cd8ddcd6d42a29b07101cbbe135cbfa1fc1aa14  cosmoos-x86_64-cmdline
b6d1564b7cbbb23787dfd143bfe27f81428d92499b26c61ee7e7b689cb09154f  cosmoos-x86_64-manifest
9b103eb1224401ca901357a86a1b715870092c8a78b4f738f9bb97cfaff5f24d  cosmoos-x86_64-cosmo-upgrade
ff858d4c55f95bd0067259ea6f41112268cb7e2ab3802b9a9cdfb4e850c4bb2b  cosmoos-x86_64-cosmo-upgrade.cpk
377a9529dd159b361c25771ecc52a65227480d61dedd67c3818c66af73053427  cosmoos-aarch64.img
0d00053d85654789deaf9fa0edc5cb8231d8d142140c1198bcb38cfedc8ff87e  cosmoos-aarch64-BOOTAA64.EFI
175529abee6cda6c59555f15bad319a5af7e41c5a96a8646c6c99ac321a591c8  cosmoos-aarch64-kernel.elf
bb7b5b9505a94c90de444ba33d2e3f6f706d29017a27a63c766033d9486898f7  cosmoos-aarch64-boot.tar
7a77470be4312a22db40932c6cd8ddcd6d42a29b07101cbbe135cbfa1fc1aa14  cosmoos-aarch64-cmdline
f550ec0bc38fc3c100f2c1540ff8b487bf014f8f088bdb6c339ed1c3efa81bdb  cosmoos-aarch64-manifest
d1d3d8337fca37a86aa56a36e3008552f8663fb2d4e364996fc106b49c0cd75c  cosmoos-aarch64-cosmo-upgrade
ca457ff4daa632c308cecf5c0fe3751d4be859d0d93b26ca6964200fc0ee021e  cosmoos-aarch64-cosmo-upgrade.cpk

Known limitations

What CosmoOS 1.0 does not do, or does differently from what you may
expect. Each item names where it is recorded; the work that remains
after 1.0 is in docs/plan.md, and the full list of known
gaps in the deferred-work inventory.

Machines

• QEMU is the tested platform. x86-64 on q35 and AArch64 on virt
  are tested by CI; there is no physical hardware matrix. Since v1.0.1
  the AArch64 image boots on Parallels Desktop 27 on Apple Silicon, and
  since v1.0.3 installs on its NVMe disks and has a network there; its
  SATA disks are not seen (Tested platforms). Out of scope for 1.0
  (roadmap): GPU and display beyond a text console (on
  the firmware's framebuffer, or a virtio-gpu adapter at the display's
  own size: no 3D, cursor or display interface for programs), hotplug, NUMA, more than 64 CPUs, huge pages, live migration,
  RAID-Z, eBPF, and the Intel VMX backend on hardware.
• Randomness from the weakest source last. The pool seeds from the
  CPU's random instructions, the firmware's EFI_RNG_PROTOCOL or a
  virtio-rng; with none of them (Parallels Desktop) a timing-jitter source
  seeds it, credited conservatively (docs/kernel/security/design.md §6).
  random.jitter=off on the command line turns that off, and the pool
  then never seeds there. The commands in this guide add -device virtio-rng-pci.
• The clock is stepped, not slewed. The wall clock is set at boot
  from the RTC or, with none (Parallels), the firmware's time. Since
  v1.0.4 root can set it (date -s, hwclock -w where there is an RTC)
  and ntpd -q steps it once from a server; there is no NTP daemon,
  because adjtimex is not implemented, and no time zone.
• No Wi-Fi, Bluetooth or sound.

Boot and security

• Verified boot covers the loader's three files (kernel, boot archive,
  command line). The root filesystem is not verified; the loader is
  not signed for UEFI Secure Boot; there is no TPM measurement
  and no rollback protection for manifests or modules (inventory
  2.9).
• No KASLR: the kernel is at a fixed address. User-space ASLR covers
  the stack, heap, mmap and PIE executables; a non-PIE (ET_EXEC)
  program loads at its fixed address.
• One user, root. Privileges, not uids, separate what processes may
  do (Privileges). A root session holding fewer
  privileges can still rewrite files in /etc that a later boot runs
  with all of them (M5 report, inventory 2.9).

Shell and commands

• The commands are the BusyBox applets listed in the shell
  page: no ping6; no hard links; no /sys.
• /proc has the process directories and a fixed set of system files
  (meminfo, stat, loadavg, uptime, mounts, version,
  cpuinfo). A process has no nice value and no user/system split of its
  CPU time; ps's TT column is a pair of Linux device numbers (5,1
  for the console), since devices here have none of their own; and a
  process's environ is what exec gave it, not what it has since written
  over (inventory §13).
• The terminal driver honours the common modes (canonical input, echo,
  signals, raw mode, window size); most other termios flags and control
  characters are accepted and ignored (inventory 1.4).
• No swap.

Networking

• wget's certificate authorities are fixed in the image
  (/etc/ssl/certs/ca-certificates.crt, as built); nothing updates them,
  and there is no certificate revocation check
  (Networking).
• The address comes from DHCP. There is no runtime tool to set one by
  hand; /etc/resolv.conf is written once per boot, not on lease
  renewal; the DHCP client does no ARP probe or DECLINE, no INIT-REBOOT,
  no RELEASE, and ignores classless routes (option 121) (inventory 2.5).
• IPv6 is link-local; there is no IPv6 routing beyond the link, no IP
  fragmentation, and no TCP SACK, window scaling or timestamps
  (inventory 2.5).
• ssh is dropbear with key login only (Ed25519 or RSA), root only;
  no port forwarding (ssh).

Storage

• cosmofs files are capped at 516128 blocks of 4 KiB (about 1.97 GiB),
  64516 blocks (252 MiB) when encrypted; a larger write fails with
  EFBIG.
• A read-only mount still writes the replay of an interrupted free or
  orphan record, as a journalling filesystem replays its journal.
• A rollback to a snapshot takes effect at the next boot (or the next
  mount of another filesystem), not in the running system
  (Snapshots and rollback); a clone of a clone, and a
  snapshot of a clone, are not possible; no RAID-Z, no resilvering
  (backlog CFS-9, CFS-13).
• A root disk that appears late (USB storage) is not waited for: init
  stays on the live root and says so.

Packages

• A network repository is fetched whole, file by file: no mirrors, no
  delta updates. Its index's freshness is only as good as the clock, which
  is stepped by hand or by ntpd -q, with no NTP daemon
  (Packages).
• cosmo-upgrade --rollback returns packages and /etc only to a boot
  environment, which upgrades made by v1.0.8's cosmo-upgrade and later
  take; past an upgrade made by v1.0.7 or older it returns the boot set and
  the base system only (Upgrading). Only
  files under /root, /home and /var/log written after the upgrade
  are kept across a rollback; the root is rolled back at the next boot,
  never while it runs; one pool.

Linux programs

• Static and PIE Linux binaries for x86-64 and AArch64 run under the
  Linux personality; it is a subset of Linux's system calls, so a
  program that needs a missing one gets ENOSYS. Dynamically linked
  musl programs run through musl's own linker, /lib/ld-musl-$ARCH.so.1,
  with libc.so and dlopen; glibc's has not been
  tried. A library with text relocations is refused (W^X); build it
  -fPIC. Native CosmoOS programs stay static.
  No containers or desktop software (docs/plan.md).