quine-linux/docs/relocate-home-to-hdd.md

Relocating /var/home/ironmagma onto the HDD (sda3)

TL;DR

The nvme btrfs pool (/, /home, /var subvolumes sharing one ~23.5 GiB partition) is ~92% full and caused a Discord SIGBUS crash (full disk cache write — see hdd-partition-split-for-btrfs-pool.md for that investigation). Breakdown of the ~20.9 GiB used:

Location	Size
/sysroot/ostree/repo (the OS image itself, one deployment, not staged)	8.4G
/var/home/ironmagma (actual $HOME — lives in the "home" subvolume)	11G
/var itself (logs/cache)	169M

/var/home/ironmagma is the single biggest reclaimable chunk and is not part of the OS image, so relocating it onto the HDD (sda3, mounted at ~/hdd, 259G free at time of writing) fixes the actual problem directly, rather than just giving the pool more room to keep filling up (the partition-split doc's approach).

Not yet executed. This must be run from a TTY after a full logout — Claude Code itself runs from files under $HOME, so it cannot perform or supervise this live; there is no assistant available mid-procedure. Follow this doc standalone.

Why this is trickier than the existing flatpak bind mount

/var/lib/flatpak is already bind-mounted from the HDD (/var/home/ironmagma/hdd/flatpak), which works because the bind mount's source is nested a level below where the HDD itself is mounted, and none of that nesting is itself the target of another mount.

Relocating $HOME is different: the HDD (sda3) is currently mounted inside the very directory (/var/home/ironmagma) we want to replace with a bind mount. If we tried to keep that nesting and just bind-mount some subdirectory of the HDD back onto /var/home/ironmagma, the new mount would sit on top of the path leading to the HDD mount itself — Linux mount shadowing means the original sda3 mount (and the flatpak bind nested inside it) would become unreachable via the normal path afterward, even though it's technically still mounted underneath. This is why the HDD's mount point must first move to a path that is a sibling of /var/home/ironmagma, not a descendant of it (e.g. /var/hdd instead of /var/home/ironmagma/hdd).

Pre-flight checks done (safe, no changes made)

• Grepped for hardcoded references to the old /var/home/ironmagma/hdd path across ~/Code and ~/.config: no scripts, systemd units, or build configs depend on it. Only two trivial, non-blocking references found:
  • ~/.config/spectaclerc — Spectacle's screenshot save folder
  • ~/.config/session/dolphin_dolphin_dolphin — a remembered Dolphin tab Both just need re-pointing after the move; neither blocks anything.
• Current relevant /etc/fstab lines:

  UUID=a45a95fa-805f-43f2-bc32-8da8970c1b91 /var/home/ironmagma/hdd ext4 defaults,nofail 0 2
  /var/home/ironmagma/hdd/flatpak /var/lib/flatpak none bind,nofail 0 0
  

Plan

Phase 0 — from the normal desktop session, before logging out

1. Take a real backup of /var/home/ironmagma to somewhere independent of this machine's disks (external drive, another machine, cloud). The copy made in Phase 2 is not a substitute for this — it lands on the same physical HDD this plan is otherwise trusting; a real backup is the actual safety net if something goes wrong mid-procedure.
2. Note down anything you'd hate to lose track of that isn't obviously under $HOME in the usual places (e.g. GPG/SSH agent state, browser session you care about) so you can sanity-check it post-move.

Phase 1 — drop to a TTY

Log out of the graphical session fully (this ends the current Claude Code session too). Switch to a TTY (Ctrl+Alt+F3) and log in as ironmagma.

Phase 2 — move the HDD's mount point out from under $HOME

sudo mkdir -p /var/hdd
sudo umount /var/lib/flatpak
sudo umount /var/home/ironmagma/hdd

Edit /etc/fstab, changing:

UUID=a45a95fa-805f-43f2-bc32-8da8970c1b91 /var/home/ironmagma/hdd ext4 defaults,nofail 0 2
/var/home/ironmagma/hdd/flatpak /var/lib/flatpak none bind,nofail 0 0

to:

UUID=a45a95fa-805f-43f2-bc32-8da8970c1b91 /var/hdd ext4 defaults,nofail 0 2
/var/hdd/flatpak /var/lib/flatpak none bind,nofail 0 0

Then:

sudo systemctl daemon-reload
sudo mount /var/hdd
sudo mount /var/lib/flatpak
ls /var/hdd          # sanity check: should show the same old contents, incl. flatpak/

Home directory content is untouched by this phase — /var/home/ironmagma still has its old (now unused) empty hdd/ placeholder directory in it, harmless, cleaned up later.

Phase 3 — copy $HOME onto the HDD

Nothing is mounted inside /var/home/ironmagma anymore at this point, so this is a plain, non-nested copy:

sudo rsync -aHAX --info=progress2 /var/home/ironmagma/ /var/hdd/home-ironmagma/

-aHAX preserves permissions, hardlinks, ACLs, and xattrs (including SELinux labels stored as security.selinux xattrs — matters for .ssh permissions and SELinux contexts).

Phase 4 — verify before touching the original

sudo diff -rq /var/home/ironmagma /var/hdd/home-ironmagma

Should report no differences. Do not proceed if it does.

Phase 5 — swap

sudo mv /var/home/ironmagma /var/home/ironmagma.old
sudo mkdir /var/home/ironmagma
sudo chown ironmagma:ironmagma /var/home/ironmagma

Add to /etc/fstab:

/var/hdd/home-ironmagma /var/home/ironmagma none bind 0 0

Deliberately no nofail here, unlike the hdd/flatpak lines. If the HDD fails to come up, we want boot to visibly stop and demand attention, not silently hand you a freshly-empty /var/home/ironmagma that looks like your whole home directory vanished.

sudo systemctl daemon-reload
sudo mount /var/home/ironmagma
ls -la /var/home/ironmagma        # should show all the familiar dotfiles/dirs
sudo restorecon -R /var/home/ironmagma   # SELinux label safety net

Phase 6 — test before rebooting

sudo -u ironmagma touch /var/home/ironmagma/.relocate-test
ls -la /var/home/ironmagma/.relocate-test
rm /var/home/ironmagma/.relocate-test

Phase 7 — reboot and verify for real

Reboot, log into the normal graphical session, and check:

• SSH agent / keys work
• git works in ~/Code
• Dropbox resumes syncing
• 1Password unlocks
• Browser profile intact
• Claude Code itself starts (it lives under $HOME — if this doc is readable again from inside a working Claude Code session, that's a good sign the move succeeded)
• Re-point Spectacle's save folder and check the stale Dolphin tab (see pre-flight checks above)

Phase 8 — only once fully confident (a few days of normal use)

Nothing before this step actually frees space on the nvme pool — until now we've only relocated and kept a full fallback copy. This is the step that does it:

sudo rm -rf /var/home/ironmagma.old

This drops nvme pool usage from ~92% to roughly ~43%.

Optional cleanup

• /var/home/ironmagma/hdd no longer exists as a mountpoint (it's /var/hdd now); if you want a convenience path at the old location, a plain symlink works fine since nothing is mounted there anymore:

  ln -s /var/hdd /var/home/ironmagma/hdd
  

Open risks / unknowns

• Whether SELinux contexts translate perfectly onto ext4 via rsync -X — restorecon -R in Phase 5 is the safety net, but not independently verified here.
• Making the home bind mount required (no nofail) means a failed/missing HDD blocks login entirely rather than degrading gracefully. This is a deliberate choice (see Phase 5) but worth revisiting if the HDD turns out to be less reliable than expected.
• The still-unexplained podman system df discrepancy (reports 2.412GB of "reclaimable" images with an empty image list, real 2.3G sitting in ~/.local/share/containers/storage/overlay, and 9 volumes that return Permission denied on inspection) was not resolved — separate from this plan, and worth checking whether those volumes belong to a still-used distrobox/toolbox environment before ever running podman system reset.

---

Written 2026-09-26. No steps executed yet.