Hi,
I wanted to understand what the recommended filesystem structure was
… it seems that in fact to make the most use of Nix one should have
/home/* and /root/ on different volumes to the root partition.
well, there is probably no “guide” because anyone decide to slice disks
so data as per personal need and taste. Normally having a separate home
volume means have their personal data separate from the system, like in
a car you have engine separated from cabin, this make easy in case of
snapshot-enabled fs/storage solution to backup the home, to modify the
system (i.e. change distro) without touch personal data etc.
My personal single-disk desktop recipe is:
- EFI partition
- boot partition separated because of LUKS encryption
- LUKS volume with zpool on top in the past, lvm now
- root
- var
- varhome
- dothome
- datahome
where var is separate to have logs and various spool separated from
the root, sometime I may would like to keep them while erasing the
system root, varhome is the /home/$myuser or the container of anything
I do not care (cache, defaults apps settings etc), dothome are my
dotfiles symlinked (in the past by hand, after with GNU stow, now I
try Nix-integrated homeManager) in /home/$myuser, datahome are the
rest of my personal data (documents, projects, images, videos, music,
…). When I have used zfs due to it’s flexible volume size I have
had many more volumes for home, one for my personal kb/wiki, another
for projects, another for docs, another for multimedia stuff etc and
for system (petc, for custom etc configs, linked in /etc like home
dotfiles).
Consider your scenario: you switch from Gentoo to NixOS and you have
both on zfs. If your home is on a dedicated volume you can simply
create a rpool/nixos volume aside rpool/gentoo volume and simply
change bootloader config. Your home remain there (backed up for safety
but untouched). Far simpler that have to backup and restore everything.
However you may encounter few problem with modern DE like Gnome/Kde
because they may badly digest you ancient DE dotfiles. So having only
the setting you care separated and an “erasable” home for other/defaults
setting may help migration, you simply wipe the “erasable home” run the
new DE and re-link back your relevant configs.
Now add a bit of complexity: you may have many different desktops for
different kind of work, for instance a personal laptop, a work laptop,
a personal desktop and a work desktop. You may want to share some data
between them, but not all. If you have different volumes for them it
may be only a matter of zfs send few volumes, or you may use unison,
my actual preferred way, for two way sync of ONLY the tree you want
too keep in sync. Here again slicing and (sym)linking/bind-mount may
help.
On proprietary systems you have no choice but keep up with limited
options, on free software you do have choices, and normally you end up
in creating your really personal setup that is so personal to surely
not fit much others, that’s the reason we do not have “slicing
suggestions” out-of-the-box.
Even your personal taxonomy and automation is normally so personal that
does not work for others, for instance typical “modern” guys have tons
of binary files divided per application (like raster image, vector
images, videos, music, …) in a vertically simple (not much nested
dirs), horizontally big (many files/dir in a single subdir), classic
unix guys tend to have tons of text spread across complex (but easy to
traverse for them) vertically big taxonomy, Emacs guys tend to have few
bigger files normally not much categorized since Emacs have a so easy
bookmark system that you tend to ignore fs layout.
As this is not explained in the install instructions, it makes
modifying the current config post-facto difficult if you do not have
another disk around and time for hoop-jumping (I don’t).
Well, if you have up-to-date and tested backups so you feel (and be)
safe, you can easy change things in a live system. For instance you
can create new volume like (zsh/fish syntax)
# move /home/me to /home/me.old
mv /home/me{,.old}
# create&mount new volumes and mount in the correct place
for vol in rpool/home{,/var,/docs,/prjs,/dotfiles}
do
zfs create $vol
zfs set mountpoint=legacy $vol
zfs mount -t zfs $vol /home/me${vol/rpool\/home}
echo "fileSystems.\"/home/me${vol/rpool\/home}\" = \n { device =
\"$vol\";\n fsType = \"zfs\";\n };" >> /tmp/addToHwConfig.nix
done
chown -R me:mygrp /home/me
mv /home/me.old/* /home/me
nixos-rebuild switch
than you have your original data sliced on different volumes, without
locally copy them so without occupy too much disk space. It’s only a
matter of wait the local move on disk… Now it’s only a matter to
choose how to symlink/bind them, for instance with homeManager or
even via bind-mount that in hwconfig.nix appear as
fileSystems."/mount/point" =
{ device = "rpool/vol";
fsType = "none";
options = [ "bind" ];
};
and you are done, all locally, all without secondary disk 
Therefore, I will not be adventuring around boot loaders again any
time soon.
Anyway do not be afraid, even bootloader change happen functionally
Very happy to have a functional system which is so fast and neat!
You have more, you can reproduce your exact system simply copying
your .nix files and install so in case of system disk failure you
can be up in a very little time and nearly zero manual work without
missing things or doing something wrong. You may also provision many
systems in lan with NixOps, like have a builtin Saltstack or Ansible
at system level, you may upgrade from a release to another substantially
issue-less (generally you have a least to adjust few pkgs names in
your config) since if anything goes wrong you still have ancient
version up and running, selectable at boot like OpenSolaris/IllumOS BE.
I also try to gravitate toward free software but I am very time
constrained and sometimes there are no viable alternatives,
particularly when issues like community, reputation, geographic
replication, etc. are at stake and you have limited time and resources
to devote.
IME it’s mostly a matter of knowledge, if you can “study” enough you
can go FOSS way full-stack in many many many cases, right now we have
even 3D parametric CAD good enough to compete with SolidWorks&c, not
a Catia/Nx/Creo level but enough for a small mechanic firm, we have
enough free FEM/FEA/EDA FOSS for not-so-complicated but not even too
simple project, for instance Purism OEM design their phone motherboard
with free software.
Sometime it’s not only a matter of knowledge since for certain jobs
FOSS support is limited and not so easy to use but in the long run
if you have knowledge you gain far more than any proprietary product
mostly because you have no tie, no imposed limitation.
The real and abruptly serious problem we have is that knowledge is
more and more “private”, we have less and less functional universities,
no more public research, even no more “open devices” to work with and
that’s a thing no less dangerous than a big atomic weapon. Fortunately
something start to move, small open OEMs start to appear, more people
who feel the need of FOSS start to “enter the game” with important
results, so I hope for at least a feature with a jailed mass-market
but a small free niche that can stand on it’s own without being
destroyed by not-really-free market.
Technology help this a bit,think about the possibility in the near
future of 3D printers good enough to print metal (low quality steel)
not only plastic, this is far far away from ancient universities and
big companies open research labs but it’s enough for a new start
especially since managerial driven companies keep going down in quality
and are less and less sustainable to a point that most of our industry
will crush in few decades at actual trend…
Freedom is power, only it does not pay immediately, it’s not easy to
get at first and must be defended continuously, however if you can
face the challenge you’ll be re-paid really well.
Sorry for the long post and poor English.
– Ingmar
