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`](./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`

```bash
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:
```bash
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:

```bash
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

```bash
sudo diff -rq /var/home/ironmagma /var/hdd/home-ironmagma
```
Should report no differences. Do not proceed if it does.

### Phase 5 — swap

```bash
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.

```bash
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

```bash
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:

```bash
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:
  ```bash
  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.*