Hi Start9 team — need guidance before I click REPAIR DRIVE. My server booted into StartOS Diagnostic Mode this morning with a Btrfs superblock error on the package-data volume. I understand from your warning modal and the upstream Btrfs project that btrfs check --repair can make things worse, so I want expert direction before running it.
HARDWARE: Unknown / to be checked. I’m a non-technical operator and don’t have this handy — happy to look it up if it matters.
STARTOS VERSION (last known): Unknown / to be checked.
WHAT HAPPENED: Unknown. Server just came up in Diagnostic Mode this morning; no known power event or unclean shutdown that I’m aware of, and no obvious warning symptoms in the prior days.
SYMPTOM: On boot, StartOS drops to Diagnostic Mode. Reachable at http://192.168.2.18 (raw IP only — the hostname doesn’t resolve because Avahi isn’t running in diagnostic mode).
ERROR (from the diagnostic screen):
Disk management error.
ERROR: superblock checksum mismatch
ERROR: superblock checksum mismatch
No valid Btrfs found on /dev/mapper/EMBASSY_ROUFFXKIN6BKNTHZFOJWBHZ6UTWDX7K6SGB6BXOGTQ7K5OWFS4GA_package-data
ERROR: cannot open file system
LOGS (VIEW LOGS button):
StartOS calls btrfs_check_readonly at startos/src/disk/fsck/btrfs.rs:10 → returns the superblock checksum mismatch above (twice, presumably from trying multiple superblock copies) → No valid Btrfs found → cannot open file system. Spantrace: btrfs_check_readonly → mount_fs → mount_all_fs → import → setup_or_init → inner_main.
There are NO I/O errors, NO SMART warnings, NO dmesg-style disk-timeout messages in the logs — only the Btrfs-level checksum rejection. The LUKS mapper opened successfully; corruption appears to be at the filesystem layer, not the block device.
ACTIONS TAKEN:
- Clicked RESTART SERVER once — came back to the same diagnostic screen with the same error. Persistent, not transient.
- Attempted REPAIR DRIVE, hit the “should only be executed if directed by a Start9 support specialist” warning modal, and cancelled.
QUESTIONS:
- Of Btrfs’s redundant superblock copies (65536 / 67108864 / 274877906944 offsets), which are intact? Your btrfs_check_readonly only reports “no valid Btrfs” without telling me which copies survived. If any backup superblock is intact,
btrfs rescue super-recovershould be a much safer first move thanbtrfs check --repair. - Is REPAIR DRIVE the right first move for this specific error pattern, or should I image the disk first with ddrescue and try
btrfs rescue super-recover/btrfs restorefrom a Linux live USB before doing anything destructive? - Is there a way to boot the server into a shell (recovery shell, initramfs prompt, or SSH-into-diagnostic-mode) so I can run btrfs-progs commands manually?
- What’s your read on the “no I/O errors, only Btrfs-level corruption” pattern — does that in your experience indicate a software fault (unclean shutdown, kernel bug) rather than a failing disk?
- Do you offer paid hands-on recovery support, and if so what would that look like and cost?
Data at risk is limited (business operations run on cloud Supabase; most ZAC_CORE source is mirrored on my Mac), so I have time to do this right rather than fast. Willing to image the disk to a spare drive first if you recommend it. I’m not comfortable running Linux command-line recovery myself.
Thanks for any pointers.