From 61d9ee15778002f076c8c8fde88e2ca5c1479cd3 Mon Sep 17 00:00:00 2001 From: Bernardo Magri Date: Fri, 10 Jul 2026 09:32:06 +0100 Subject: [PATCH] docs(migration): clarify installer vs @home-snapshots layout (#64) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Installer: disko @snapshots → /.snapshots + first-boot nested /home/.snapshots. Migration machines may use top-level @home-snapshots (TuringMachine); either works for snapper. --- docs/MIGRATION.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/MIGRATION.md b/docs/MIGRATION.md index 5b73432..c2e10b9 100644 --- a/docs/MIGRATION.md +++ b/docs/MIGRATION.md @@ -30,6 +30,17 @@ assumptions. Check each: | **LUKS** (optional, themed prompt) | `lsblk -f` shows `crypto_LUKS` | none — LUKS is optional | | Already a **flake** config | `test -f /etc/nixos/flake.nix` | fine either way; you'll write a fresh flake regardless | +**Installer vs migration snapshot layout.** A fresh Nomarchy install +(disko) creates a top-level `@snapshots` subvolume mounted at +`/.snapshots`, then a first-boot oneshot makes a *nested* +`/home/.snapshots` under `@home` for snapper's home timeline — it does +**not** create a separate top-level `@home-snapshots`. Migration machines +(e.g. TuringMachine) may already use top-level `@snapshots` **and** +`@home-snapshots`; that is fine. Snapper only needs a `.snapshots` path +under each tracked subvolume (`/` and `/home`), so either layout works — +reuse what you have, or create the missing pieces if you want snapper +without reformatting. + TuringMachine matches all of these, including the `@snapshots` / `@home-snapshots` subvolumes — so snapper works with zero disk work.