Rootfs backups are stale #46

New issue

Closed

opened 2026-08-28 09:57:40 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-08-28 09:57:40 +00:00

Owner

Split out of #9, which is otherwise resolved now that the rescue card is current.

The rootfs tarballs on ouranos predate two days of work:

file	md5
`backup/draco-rootfs-20260827-1717.tar.gz`	`8c9ab86063798980f3582cf3ff3356c6`	394 M
`backup/draco-rootfs-20260827.tar.gz`	`2e3495e1c2055d8a24d71be055437e02`	387 M

Neither includes the S/PDIF and DMA work, the DRM/HDMI config, the IR clock fix, cd-gpios, or
the corrected bt-public-addr.sh — and the rescue card is now a second system that also wants
capturing.

These stop being irreplaceable the moment provision.sh exists and can rebuild a rootfs from a
stock Debian image (#8), which is the better fix than taking another tarball. Until then a fresh
one is owed for both systems.

See ARCHIVE.md.

Split out of #9, which is otherwise resolved now that the rescue card is current. The rootfs tarballs on ouranos predate two days of work: | file | md5 | | |---|---|---| | `backup/draco-rootfs-20260827-1717.tar.gz` | `8c9ab86063798980f3582cf3ff3356c6` | 394 M | | `backup/draco-rootfs-20260827.tar.gz` | `2e3495e1c2055d8a24d71be055437e02` | 387 M | Neither includes the S/PDIF and DMA work, the DRM/HDMI config, the IR clock fix, `cd-gpios`, or the corrected `bt-public-addr.sh` — and the rescue card is now a second system that also wants capturing. These stop being irreplaceable the moment `provision.sh` exists and can rebuild a rootfs from a stock Debian image (#8), which is the better fix than taking another tarball. Until then a fresh one is owed for both systems. See [ARCHIVE.md](ARCHIVE.md).

tiagoagueda added the

infra

P3-normal

labels

2026-08-29 12:35:07 +00:00

tiagoagueda commented

2026-08-29 12:53:37 +00:00

Author

Owner

Done — fresh tarball taken, and the rescue card now covers the second system

431 M  draco-rootfs-20260829-1245.tar.gz  6549c803cbe843f02482454fe9ceedc3

Taken after today's work, so it includes the ro/fsck change, the zram kernel and its config, the swapfile, the SSH hardening, the draco account and the initramfs firmware hook.

The "both systems" half of this is now structural rather than a second tarball: the rescue card was rebuilt as a full clone of the eMMC (verified identical package sets, 0 differences), so capturing the eMMC captures what the card is. The card's own deltas are deliberate and few — hostname, UUID, machine-id, its own fw_env.config and boot menu — and tools/sync-rescue-sd.sh regenerates all of them.

Recorded in ARCHIVE.md; the two 2026-08-27 tarballs are marked superseded.

Still true, and still the better fix: this stops mattering once #8 exists and a rootfs can be rebuilt from stock Debian rather than restored from a tarball.

## Done — fresh tarball taken, and the rescue card now covers the second system ``` 431 M draco-rootfs-20260829-1245.tar.gz 6549c803cbe843f02482454fe9ceedc3 ``` Taken *after* today's work, so it includes the `ro`/fsck change, the zram kernel and its config, the swapfile, the SSH hardening, the `draco` account and the initramfs firmware hook. The "both systems" half of this is now structural rather than a second tarball: the rescue card was rebuilt as a **full clone** of the eMMC (verified identical package sets, 0 differences), so capturing the eMMC captures what the card is. The card's own deltas are deliberate and few — hostname, UUID, machine-id, its own `fw_env.config` and boot menu — and `tools/sync-rescue-sd.sh` regenerates all of them. Recorded in [ARCHIVE.md](ARCHIVE.md); the two 2026-08-27 tarballs are marked superseded. Still true, and still the better fix: this stops mattering once #8 exists and a rootfs can be rebuilt from stock Debian rather than restored from a tarball.

tiagoagueda closed this issue

2026-08-29 12:53:37 +00:00

tiagoagueda referenced this issue from a commit

2026-08-29 12:53:56 +00:00

Tier 0: the filesystem was never checked, and there was no swap at all