Problem
When a mixtape base image (~/.config/mb/mixtapes/<name>/nixos.qcow2) is replaced while an existing VM overlay (~/.config/mb/vms/<name>/disk.qcow2) references it, the overlay's backing chain is silently broken. The overlay stores deltas by block offset against the original backing file — a new image has entirely different block layout, resulting in ext4 corruption on next boot:
EXT4-fs error (device vda2): ext4_init_orphan_info:627: orphan file block 16: bad checksum
EXT4-fs (vda2): mount failed
The user sees a hang or post-boot provisioning: waiting for stereosd ready: context deadline exceeded with no indication that the disk is corrupt.
Expected behavior
mb up (re-boot path) or mb start should detect that the backing file has changed and either:
- Warn the user and refuse to boot, suggesting
mb destroy && mb up
- Auto-recreate the overlay from the new backing image (losing VM state)
Possible implementation
- On overlay creation, store the backing file's SHA-256 (or size + mtime) in
state.json
- On re-boot, compare the current backing file against the stored hash
- If mismatched, error with a clear message explaining the overlay is stale
Workaround
mb destroy <name> && mb up creates a fresh overlay against the new base image.
Problem
When a mixtape base image (
~/.config/mb/mixtapes/<name>/nixos.qcow2) is replaced while an existing VM overlay (~/.config/mb/vms/<name>/disk.qcow2) references it, the overlay's backing chain is silently broken. The overlay stores deltas by block offset against the original backing file — a new image has entirely different block layout, resulting in ext4 corruption on next boot:The user sees a hang or
post-boot provisioning: waiting for stereosd ready: context deadline exceededwith no indication that the disk is corrupt.Expected behavior
mb up(re-boot path) ormb startshould detect that the backing file has changed and either:mb destroy && mb upPossible implementation
state.jsonWorkaround
mb destroy <name> && mb upcreates a fresh overlay against the new base image.