jutty/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Migrate to Zola

Browse source
This commit is contained in:
jultty 2024-08-18 13:23:10 -03:00
commit 86d0d27ef2
64 changed files with 1044 additions and 2477 deletions
Download patch file Download diff file Expand all files Collapse all files

5
content/feeds.md Normal file
View file

@ -0,0 +1,5 @@
+++
+++
- Posts: [RSS](https://blog.jutty.dev/rss.xml) [Atom](https://blog.jutty.dev/atom.xml)
- Links: [RSS](https://blog.jutty.dev/links/rss.xml) [Atom](https://blog.jutty.dev/links/atom.xml)

5
content/feeds.pt.md Normal file
View file

@ -0,0 +1,5 @@
+++
+++
- Posts: [RSS](https://blog.jutty.dev/pt/rss.xml) [Atom](https://blog.jutty.dev/pt/atom.xml)
- Links: [RSS](https://blog.jutty.dev/pt/links/rss.xml) [Atom](https://blog.jutty.dev/pt/links/atom.xml)

7
content/links/_index.md Normal file
View file

@ -0,0 +1,7 @@
+++
title = "Links"
sort_by = "date"
template = "links.html"
page_template = "link-page.html"
generate_feeds = true
+++

6
content/links/_index.pt.md Normal file
View file

@ -0,0 +1,6 @@
+++
title = "Links"
sort_by = "date"
template = "links.html"
page_template = "link-page.html"
+++

8
content/links/mrusme-reader.md Normal file
View file

@ -0,0 +1,8 @@
+++
title = "mrusme/reader: for your command line what the 'readability view' is for browsers"
date = 2024-08-06
[extra]
url = "https://github.com/mrusme/reader"
+++
Happy to see *any* tool that reduces having to open a browser.

8
content/links/mrusme-reader.pt.md Normal file
View file

@ -0,0 +1,8 @@
+++
title = "mrusme/reader: pra sua linha de comando o que o 'readability view' é para navegadores"
date = 2024-08-06
[extra]
url = "https://github.com/mrusme/reader"
+++
Bom ver *qualquer* ferramenta que evita precisar abrir um navegador.

6
content/posts/_index.md Normal file
View file

@ -0,0 +1,6 @@
+++
title = "Posts"
sort_by = "date"
template = "posts.html"
page_template = "post-page.html"
+++

6
content/posts/_index.pt.md Normal file
View file

@ -0,0 +1,6 @@
+++
title = "Posts"
sort_by = "date"
template = "posts.html"
page_template = "post-page.html"
+++

133
content/posts/introducing-tori.md Normal file
View file

@ -0,0 +1,133 @@
+++
title = "Introducing tori"
date = 2024-06-30
aliases = ["posts/introducing-tori.html"]
+++
**[tori](https://tori.jutty.dev/)** is a tool to track your personal systems' configurations and replicate them.
For the past 5 months, I've been simultaneously using and writing it to manage my main machine's configuration. By "manage the configuration" what I mean is keeping track of installed packages, configuration files, symlinks, and other settings that can be queried and set through command line interfaces.
After installing a given system, I wanted to get it to the same configuration state I was used to, or to a certain configuration specific to its purpose. Just copying backups would certainly be a very manual task, namely because:
- Not all settings live in `/etc`
- Some settings must be set using a specific CLI utility
- Backups usually carry an overwhelming amount of redundant default configuration you never even touched
- It does not track what is changing as you are still using the system
- I actually wanted to _know_ what I was tracking
Configuring a system can become a very vague process as you start to lose track of where the changes are being made and what is the specific configuration needed for something to work.
Every time you change some configuration file, every time you create a symlink somewhere, that's all having effects on the system that you may expect to be there in the future, but you may not remember how to accomplish that. This drift between what you have and what you are able to replicate only grows as you keep using your system.
To get a better idea, see the code snippet below. It's from the main file that I use to manage all function calls:
```sh
xbps_get_many packages
check_service dbus
check_group audio
check_group video
copy dhcpcd.conf /etc/dhcpcd.conf
place kernel-cmd-line.conf /etc/dracut.conf.d
check_link /etc/localtime /usr/share/zoneinfo/America/Sao_Paulo
get_nix tailspin tspin
get_cargo taplo-cli taplo --locked
get_bun bash-language-server
get_bin 'https://raw.githubusercontent.com/hackerb9/lsix/master/lsix' lsix
check_gsettings gtk-theme 'Plata-Noir'
check_gsettings font-name 'Mononoki Nerd Font Regular'
```
What is happening here:
1. A file named `packages` containing package names is parsed and all packages are queried and installed by the `xbps` package manager, if not already installed
1. Service `dbus` is enabled if not already enabled
1. The user is added to groups `audio` and `video`, unless already in them
1. File `dhcpcd.conf` from the configuration directory's `base` directory is checked against the one in the passed path and overwrites it if the user chooses to do so
1. File `kernel-cmd-line.conf` from the configuration directory's `base` directory is copied into the passed path. If the file already exists or differs, tori will present an error
1. A symlink is checked to be on `/etc/localtime` pointing to the passed path. If it doesn't, it is created or fixed
1. If not installed, a few packages are installed using different package managers: `tailspin`, `taplo` and `bash-language-server`
1. If absent, an executable for `lsix` is downloaded from a URL and placed at `~/.local/bin`
1. Some `gsettings` values are read and set if they differ: `gtk-theme` and `font-name`
Notice how everything is conditioned to the system not already presenting that state? tori aims to be idempotent. Running it twice should do nothing the second time it runs so you can run it multiple times while making changes without any doubled effects.
I mentioned a `base` directory. This is what a sample tori directory would look like in its present state:
```
.
├── base
│   ├── dhcpcd.conf
│   ├── kernel-cmd-line.conf
│   ├── packages
│   └── vars.sh
├── .bkp
│   ├── canonical
│   │   ├── etc
│   │   └── opt
│   └── ephemeral
│   └── etc
├── src
│   ├── checks.sh
│   ├── copy.sh
│   └── get.sh
└── strap
```
What you are seeing in this sample of the directory are the following files and directories:
- `base`: Where you place the configuration files that functions like `copy` and `place` will look for and copy into the desired locations
- `.bkp/canonical`: Where tori will look for initial backups and create them if none exists
- `.bkp/ephemeral`: Where tori will place timestamped backups every time a file is modified or overwritten
- `src`: Where the source files live, mostly containing function definitions
- `strap`: The main file used to call the functions
Because I developed tori for my own purposes initially, I didn't really care to separate the actual source files from the context-sensitive data. While a mistake from a higher level, it allowed me to just keep developing the whole system configuration and the code that tracked it from a single, version-controlled location, amounting to very little complexity. I can't deny to have enjoyed it so far, but going forward that is going to change.
Currently, tori is able to install several package managers and their packages, including xbps, apt, nix, opam, stack, cargo, go, sdkmanager, npm, flatpak and pipx.
It can also perform several other tasks:
- setup programming runtimes for OCaml, Scala (via Coursier), Go, JavaScript (node and bun), Rust (via rustup)
- generate GPG certificates
- query and set options with `update-alternatives` and `gsettings`
- change the user shell
- check and enable services (systemd and runit)
- download pre-built binaries from tarballs and (g)zip files, unpacking and making them executable
- get files through the network using rsync
- several other things likely not worth mentioning
The application slowly grew to accommodate many of my needs, but I also made it very hard to share with the world in the process, since I never really meant to go public with it.
## Portability issues
Despite it being very useful to me in its current state and still being something I actively use every day, a lot of it is hard-coded for my very personal use. It was not written with portability in mind and therefore requires a lot of source-code editing to use in a different system.
For instance, when I switched from Debian to Void Linux, most of it broke. I certainly would not expect the package list to be compatible between them, but I realized at that point how tightly it was coupled to Debian.
When I started delving deeper into FreeBSD and setting up the system, I kept reaching out to something like tori. But it wasn't there, and it wouldn't work even if it were.
Something that certainly influenced my desire to write tori was my experience using NixOS, which was full of mixed feelings, but undeniably had good feelings that stuck.
I really liked being able to manage the system configuration and packages from a single file. But, at the same time, I felt it was overkill. It was limiting because most of the time you were **forced** to configure things through its interfaces. It was basically incompatible with what every other Unix system expects, and therefore what people who write software for these systems also expect.
I appreciated bringing the system configuration to a centralized file, but I certainly did not want to manage all my `~/.config` configuration files from that same place. After writing tori, I can choose what to place under its tracking and what not to. Third-party software still works as both me and its creators expect it to, instead of my system breaking things and needing them to work the way _it_ expects.
## Glad to reinvent the wheel
While I understand there are very mature and powerful tools to manage a system's state and reproduce it, I am aiming here for a much simpler use case. I have no intention to see it used in enterprise or distributed systems. It is all about managing how your personal computing is set up and having a backup of how you did it.
What I need is not a tool that can orchestrate a fleet of containers running a given configuration. What I need is a tool that can run in a bare system that just got installed and get it to a state that feels useful to me. I do not want it to run instructions over a range of IPs, I just want to be able to check at any time if the system state has diverged from the configuration I am using to track it. I wanted a tool that would help me develop a different habit when I need to make system-level changes.
And finally, I suppose I just really wanted to build this. I really enjoy the process of configuring operating systems and learning how they work and differ. And I really wanted to learn more about portable, POSIX-compatible shell scripting.
So I decided to rewrite it with portability in mind. I am doing this rewrite in FreeBSD, to put the portability to the test. Once some basic functionality is done, the next step will be bringing it to Void Linux, Debian and NetBSD.
tori is a bird that has just hatched, so everything is still very, very crude. At this stage, the docs often show intentions rather than implemented functionality. Still, because it is something I've come to depend on, it has this rewarding sense of usefulness behind it.
If it sounds interesting to you, take a look. You can follow development at the main [Git repository](https://brew.bsd.cafe/jutty/tori) in BSD.Cafe's Git forge or through its mirrors on [GitHub](https://github.com/jultty/tori) and [Codeberg](https://codeberg.org/jutty/tori). Going forward, I will also probably be talking a lot about it on my [Mastodon profile](https://mastodon.bsd.cafe/@jutty).

45
content/posts/meeting-the-bsd-family.md Normal file
View file

@ -0,0 +1,45 @@
+++
title = "Meeting the BSD family"
date = 2024-05-20
aliases = ["posts/meeting-the-bsd-family.html"]
+++
During this year I have been delving deeper and deeper in the BSD realm. Switching my home server to FreeBSD, trying NetBSD and OpenBSD on my backup machine, getting a cheap SSD to see how they'd all run on my main one, all beaming with the joy of tinkering and learning.
As a nerd who delights in reading documentation, manuals and handbooks, I feel like I have found a gigantic library to lose myself in. And to me the delight of such reading is in that it's never a passive learning experience, but something you can act on and bring to fruition yourself.
While Linux-based operating systems, with all the popularity they have gained, have developed into a complex and extremely active ecosystem, the BSD operating systems feel less bloated and more focused on whatever their specialty is.
You can't really complain about software availability, given the amount of pre-packaged binaries you will find. When trying FreeBSD, I could not miss anything I needed. More recently, on NetBSD, I also found most of the tools I reached for.
Though I have a mostly text-driven workflow, doing almost all things with a browser and a terminal alone -- which certainly helps in making your stack more portable -- I do rely on some GUI applications for the domains where they excel.
What you might experience is a slower pace of change for major things, such as on Wayland adoption, which like it or not is coming for all of us with X deprecation looming.
Running BSD is an incredible opportunity to really learn about UNIX-like systems and operating systems in general.
Recently, I've been learning more about NetBSD after spending some time with FreeBSD. And this inner diversity of fully-independent operating systems with their own kernels and perks keeps multiplying the learning opportunities.
If you already learned a lot about whatever OS you currently use, I'd say particularly if that OS is Linux-based, when you start to play with a BSD system you are able to realize what is similar and what is not.
Whatever is different is likely teaching you the more portable, UNIX way of doing things. Even if it isn't, it's teaching you how a different OS is designed and behaves.
Things that are the same, which are not few, also offer learning opportunities. You get to see what parts of a Linux-based OS perhaps didn't really originate there, or aren't in any way an exclusive feature of it.
Now, to lay any zealousness aside and not make this a saccharine one-sided tale, I'd also like to mention a certain social phenomenon that this endeavour reminded me of.
This is certainly not something specific to BSD, but because it has such an engaged and savvy community, you definitely get to notice it sometimes. I'm talking about the tendency to identify with and then indiscriminately defend the software you use.
One common meme you'll find is people complaining about lack of hardware support, especially wifi. In response, I've seen people stating with little nuance that any difficulty to getting your hardware to work on \<insert a BSD OS here> is to be explained by poor skills or lack of dedication in reading the documentation.
I see that as denial. When everyone around is just defending something to no end, no critiques allowed, it starts to feel... awkward, to say the least.
Conversely, when I see people openly pointing out weaknesses in something I value and that I can tell they also care for, I feel relief and admiration for that person and that community at large. And thankfully I have also found a lot of this among the BSD folks.
Because running a given operating system on a machine you rely on is such a big commitment, it intensifies this phenomenon where users start to identify with the software they use and defend it beyond reason.
It happens with frameworks, desktop environments and window managers, but operating systems require you to commit even more because you can't just swap them as easily, so my guess is we identify to compensate this sense of being tied to it. And from this identification comes an urge to deny any defect.
If you are cognizant of the perils, identifying with something is not necessarily a bad thing, though. To some extent, it is inevitable, and being really into something, caring about it, nurturing immense curiosity and a desire to discuss it, are all sources of pleasure I do not excuse myself from.
Software wars aside, getting to know this family of operating systems better has been a joy. It opened up whole new avenues and perspectives to understanding operating systems as a whole, and how beyond Linux-based OSs there are numerous other free and open source operating systems that strengthen the diversity in this field.

36
content/posts/scripts-em-ocaml.pt.md Normal file
View file

@ -0,0 +1,36 @@
+++
title = "Scripts em OCaml"
date = 2024-02-23
aliases = ["posts/scripts-em-ocaml.html"]
+++
Este blog gera suas postagens com o Pandoc, mas quem faz o trabalho lógico de identificar os arquivos e montar os comandos é um pequeno script em OCaml.
Descobri essa linguagem quando comecei a investigar como poderia substituir o Bash como uma linguagem para scripts. Eu acho que o Bash é excelente para cumprir essa função, apesar de bastante inseguro e propenso a erros. O que me incomodava mesmo era ver que todo aquele tempo escrevendo scripts com Bash poderia ser tempo aprendendo uma linguagem cujo conhecimento se transferisse para muitas outras aplicações.
O script se resume a:
```ocaml
let pandoc_params =
"--css ../../assets/style.css -s --to html5 --metadata pagetitle='basename' "
let vert md = begin
if md <> "gen.ml" && md <> "html" then
ignore( Sys.command (
"pandoc " ^ pandoc_params ^ md ^ " -o html/" ^ md ^ ".html "
) )
end ;;
let contents = Array.to_list (Sys.readdir ".") in
List.map vert contents ;;
```
Primeiro, armazeno em `pandoc_params` os parâmetros comuns que serão passados ao Pandoc para gerar os arquivos HTML a partir dos arquivos em Markdown.
Em seguida, defino a função `vert`, que, caso o arquivo não se chame "gen.ml" (o próprio script) nem "html" (o diretório onde os arquivos gerados ficam), o comando do Pandoc é chamado com os nomes dos arquivos de entrada e saída.
Essa função então é aplicada com `List.map vert contents` a cada arquivo do diretório atual.
## Referências
- [Walk a directory/Non-recursively - Rosetta Code](https://rosettacode.org/wiki/Walk_a_directory/Non-recursively#OCaml)
- [Pandoc Markdown CSS Theme](https://jez.io/pandoc-markdown-css-theme/)

63
content/posts/unwinding.md Normal file
View file

@ -0,0 +1,63 @@
+++
title = "Giving up simplicity"
date = 2024-08-10
aliases = ["posts/unwinding.html"]
+++
_or_
# Unwinding
Due to a worker strike, the university semester ended late this year. That meant everything had to be compressed into little more than a month in order to wrap up what would have taken four. Now that we're almost through it, my mind wanders to writing. It is almost always what springs from the void in me, what has been winded up loosens and the scattered meaning starts to recollect into the drain of language and swirl through the piping of my nervous system.
_Wind_ is air that has been somehow compressed. If there was no pressure pushing it anywhere, it would be just expansive air, floating in peace with the atmosphere.
If you'd entertain this thought further, consider a work of visual art. It can be more figurative, clearly depicting shapes that mean something, and therefore able to convey an array of ideas to whatever extent of detail the artist wants. Conversely, it can be more abstract, where ideas will be a lot more sparse, possibly to the point where nothing at all is conveyed other than the appearance, whatever aesthetic is employed being the whole message in itself. Very little is packed into the work, just like the air you can't even feel weighing on you.
In computing, and more specifically in the realm of programming -- a craft presently overshadowed by the semantically starved jargon of whatever the department responsible for inflating public perception numbers is called these days -- simplicity is often emphasized. Code is supposed to be clear, expressive and clean. A software application is supposed to have as few dependencies as possible, and strive to keep it simple, or risk stupidity.
While that is a lofty goal, and while clear, expressive and clean code is a refreshing and tranquilizing sight, more often than not software just can't be simple.
Not having dependencies means implementing more and more yourself. There are corner cases to cover, tests to run, different architectures and operating systems to support. Even the simplest of software ideas, say, a calculator, a program that prints back a sentence in reverse, that displays a picture you give it, whatever you conceive as the simplest use case, is hardly ever implemented with simplicity in the naïve sense of something that is, quite literally, simplistic.
More often than not, simplicity is actually abstraction. The breaking apart of complexity behind a simpler facade. More so a way to manage complexity by conveying it simply than to enact simplicity in its actual sense. Each step in abstraction is actually a layer deeper into intricacy. And yet, it makes things immensely easier to manage and understand.
For some reason, I have always felt very drawn to abstract works. Staring into them, there is no expectation to understand, get, or argue about. Interestingly, to me that also means they couldn't be any more clear. It does not mean a specific, intelligible message is conveyed from the artist to me, rather, it means whatever impression is caused on the viewer was never intended to reach too deep anyways. It never intended to carry that much through its medium.
Sometimes, too much detail, no matter how specific, can draw an idea so far out that it becomes harder and harder to grasp. In contrast to that, a brisk exposition can get the message across like lightning.
So detail does not always convey meaning, although it can convey a specific meaning to someone who will bear with you as you build the context for it. Otherwise, you could convey your message just as effectively in an abstract manner if your receiver already has that context from the outset.
In computing, such possibility is simply absent from us. No context whatsoever can be assumed, and if it is present, that is because some other structure is providing it.
Complexity produces confusion, confusion produces frustration, and frustration can lead to either surrender or a rebound. So the interesting thing about this pressurizing of ideas is that it springs back into action a process that may reverse it or deflect into something else entirely.
Instead of surrendering to the frustration of complexity, sometimes I actually take the time to recollect myself and analyze it into understanding. This feeling of winning over something that had me on my knees and ready to give up is a very gratifying one. It convinces me I can squeeze grit from despair if I bet on it and willingly risk desperation in order to see it through.
Yet, after chasing the deadline of effort all of it relaxes back into this state. In it, the only way to rest is to embrace complexity as the whole, and simplicity as one of its manifestations. It is so cold right now in the south, but in the north it is not. Four days and nine hours ago it was the peak of the winter. I'm wrapped in blankets and the room is dark like the depths of a submarine cave, LED lights here and there like fluorescent eyes blinking in silence.
The professor had us build games and then present them to the whole faculty. Among the outputs, one algorithm I produced stuck with me for what I deem is simplicity. It is responsible for causing an enemy to chase the player by finding the difference between their positions and lowering it:
```Python
func move_to(x, y):
var x_difference = self.global_position.x - x
var y_difference = self.global_position.y - y
if abs(x_difference) > chase_speed:
if x_difference > 0:
self.global_position.x -= chase_speed
else:
self.global_position.x += chase_speed
else:
self.global_position.x += x_difference
if abs(y_difference) > chase_speed:
if y_difference > 0:
self.global_position.y -= chase_speed
else:
self.global_position.y += chase_speed
else:
self.global_position.y += y_difference
```
It could be further abstracted. The logic is repetitive. The math could be condensed. But should it? Would that make it harder or easier to understand? And to whom? There is no single answer, and yet I would really appreciate knowing.

651
content/posts/void-on-zfs.md Normal file
View file

@ -0,0 +1,651 @@
+++
title = "Void on ZFS"
date = 2024-06-09
aliases = ["posts/void-on-zfs.html"]
+++
![An L-shaped desk with two laptops, an external monitor, a router and a third headless computer in a tower case with several power cables connected to a power strip on top of it. Next to the power strip are two cellphones, a long red box, and a charging case for Bluetooth headphones with a red LED on. The tower case has three stickers on it: one with the machine specifications, one the FreeBSD logo, and one reading "platform feodalism (sic) is so 1492". Scattered around the machines are some office supplies, medicine containers, a screwdriver, a notepad, a small notebook, an NVMe SSD card on top of its packaging, a mug, a water bottle and a scarf. Hanging on the wall are a small painting of a dead tree before the twilight, prayer beads, a sunflower-pattern keychain and a calendar. Between the desk and the camera, a green plastic chair has a pillow and blanket on top of it. A few wires and cardboard boxes are visible under the desk.](/assets/img/posts/void-on-zfs/desk.jpg)
June is here. It brings the usual cold weather and some extra rhinitis complications. With that I find myself in a recovery mood Sunday, wrapped in a blanket with a mug of tea, a screwdriver, some notes on paper, a flash drive, a couple of NVMe cards and the trio of Unix-powered machines that will help me get this done.
The mission is to get a root-on-ZFS EFI installation of Void Linux with ZFSBootMenu on a Dell Latitude 7480.
To my left, a ceiling-collapse-survivor Sony VAIO is running NetBSD with spectrwm. It's split with sakura and tmux on a terminal to one side, where Neovim is storing these words, and Firefox on the other, ready to fetch all the docs. In the middle, the object of today's operation. And to my right, a headless PC board runs FreeBSD with ZFS, holding all the backups needed for the post-install tasks.
![Two laptops side-by-side on a desk, each with a USB keyboard plugged in. Writing utensils inside a holder and post-its are between the two. A sunflower-patterned keychain and prayer beads hang from the wall. The computer on the left has a brown cloth for a wrist rest in front of its USB keyboard, to the left of which lies a small blue Campus notebook.](/assets/img/posts/void-on-zfs/duo.jpg)
This lengthy post, written not after the fact but during it, is my way of documenting and also sharing how it all went. Additionally, it's a way to delve deeper into many of the things the ZFSBootMenu docs leave unexplained, an urge I already had yesterday as I just tried it out without much modification.
Last night, I ran through the [ZFSBootMenu documentation guide for Void](https://docs.zfsbootmenu.org/en/latest/guides/void-linux/uefi.html) and followed it both on a VM and then on an external SATA HDD plugged through a USB case, taking some notes and getting a general idea of the process.
The Void installer does not support ZFS out of the box, so the [Void Handbook](https://docs.voidlinux.org/) itself recommends the ZFSBootMenu documentation before [its own](https://docs.voidlinux.org/installation/guides/zfs.html) (a manual chroot installation) when it comes to doing a ZFS-on-root install. This guide from ZFSBootMenu is what we'll be following throughout this post.
Do note that, while comprehensive, my account is no replacement for [the original guide](https://docs.zfsbootmenu.org/en/latest/guides/void-linux/uefi.html). Although more concise, it contains certain notes not included in this post and covers a larger set of possibilities than I did here. Some of the code blocks you'll see here are identical to the ones from the guide, but many others are specific to how I did things, so keep that in mind and try things before going with your final installation.
## Why Void?
I don't really enjoy distro-hopping. I usually will spend a few years on the same OS and only switch for good reason and after some thorough testing. And after some Debian time, I felt interested in trying Void for a few reasons:
- rolling, but stable
- runit init system
- BSD-like rc files
- BSD-like handbook documentation
- numerous, up to date, but stable packages
After trying it, some other features made me settle:
- fast and feature-packed package manager
- very fast startup time (kudos to runit)
- first-class support in ZFSBootMenu
The Void package manager, [xbps](https://docs.voidlinux.org/xbps/index.html), has several interesting features. One of my favorites, for a taste, is `xbps-query --cat`, which shows the original contents of a given file in a package.
For example, `xpbps-query --cat /etc/zfsbootmenu/config.yaml zfsbootmenu` will show you the original content of the `config.yaml` file in the `zfsbootmenu` package. You can use it for very core packages like `base-system` or `runit-void` to determine the original version of files shipped by them.
## And why ZFS?
My first contact with ZFS was when using FreeBSD, which provides it as an option in its installer, making it a bit too easy not to try. Having a server on ZFS means all the data it holds can be safeguarded and transferred in robust ways, and mistakes are also easier to recover from.
Aside from all the data integrity features and flexibility it brings, the features that interest me the most are the ones for managing snapshots.
ZFS snapshots allow you to store the filesystem state at a given point in time, and to compare against, access the content of, and fully revert to this state. After the guide has been followed throughout, an extra section at the end of this post has some snapshot basics.
## Getting in
So, first things first, open the machine up and swap the NVMe cards. For me, that means getting my 128 GB NVMe stick, which I use basically for tests, and replace it with the 256 GB one which currently has Debian on it. Yes, I get by just fine with that much.
While a bit dusty, the machine was overall in good state. The release date for the model is 2017, which for my computing standards is very recent.
It has a single NVMe slot, one 16 GB RAM stick and one unused RAM slot. If you look closely, you can notice a dent on the vent tube connecting the cooler to the CPU. Despite this, it very rarely heats up.
![The Dell laptop seen from above, lid closed, with the screen against the desk and the bottom cover removed, exposing the motherboard.](/assets/img/posts/void-on-zfs/karu-inside.jpg)
Next up is to boot up [hrmpf](https://github.com/leahneukirchen/hrmpf) in EFI mode.
hrmpf is a Void-based rescue system maintained by a Void team member and distributed as a bootable image that can accomplish many things, some of them being a full Void installation, entering a proper chroot, and being ZFS-ready with the needed drivers and tools.
Once booted into it, EFI support can be confirmed by filtering the output of `dmesg`:
```sh
dmesg | grep -i efivars
```
The output should contain "Registered efivars operations".
Make sure you have an Internet connection at this point. Most of the following steps will run fine without one, but closer to the end, when installing the Void base system, it will all go to waste if we can't reach a package mirror.
## Setting up the installation environment
The ZFSBootMenu guide uses some variables in order to avoid mistakes and make the instructions more portable across the different storage types and supported operating systems.
### `/etc/os-release`
The `/etc/os-release` file typically contains information on the operating system you are running.
In the hrmpf live system, these are its contents:
```sh
NAME="Void"
ID="void"
PRETTY_NAME="Void Linux"
HOME_URL="https://voidlinux.org/"
DOCUMENTATION="https://docs.voidlinux.org/"
LOGO="void-logo"
ANSI_COLOR="0;38;2;71;128;97"
DISTRIB_ID="void
```
For comparison, here is FreeBSD's `os-release` file:
```sh
NAME=FreeBSD
VERSION="14.0-RELEASE"
VERSION_ID="14.0"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 14.0-RELEASE"
CPE_NAME="cpe:/o:freebsd:freebsd:14.0"
HOME_URL="https://FreeBSD.org/"
BUG_REPORT_URL="https://bugs.FreeBSD.org/"
```
In contrast, NetBSD has no such file.
For the purposes of the ZFSBootMenu guide, only the `$ID` value appears to be used. And because the file already is structured as shell-compatible variable assignments, we just source it:
```sh
source /etc/os-release
export ID
```
### `hostid`
Required by ZFS intallations, a host ID is a 32-bit hexadecimal value that, supposedly, will uniquely identify a machine. Considering the number of existing machines and the 32-bit range, you might guess why I say _supposedly_.
If your machine has the `hostid` utilities, you can see the host ID by simply running `hostid`. Prior to generation, my hrmpf live system reports `00000000`.
It can't provide a real guarantee that it will be unique, so it's up to you to take care that it is unique among _your_ machines. Read on for why that's hardly an issue.
From the `gethostid(3)` man page:
> [...] a unique 32-bit identifier for the current machine. The 32-bit identifier was intended to be unique among all UNIX systems in existence. This normally resembles the Internet address for the local machine, as returned by `gethostbyname(3)`, and thus usually never needs to be set.
This seems to be more or less a legacy feature. In Void's man page for `gethostid(3)`, you see this in the history section:
> 4.2BSD; dropped in 4.4BSD. SVr4 and POSIX.1-2001 include gethostid() but not sethostid().
Still, it is something that OpenZFS requires to be set:
> At time of import or creation, the pool stores the system’s unique host ID and for the purposes of supporting multipath, import into other systems will fail unless forced. <br/><br/>
> --- [OpenZFS docs, Introduction to ZFS: Storage pools](https://openzfs.readthedocs.io/en/latest/introduction.html)
`zgenhostid`, which is shipped by OpenZFS, according to its man page "emulates the `genhostid(1)` utility and is provided for use on systems which do not include the utility or do not provide the `sethostid(3)` function."
When used without arguments, these commands will generate a random host ID. But they can also be passed a hexadecimal value, which gets stored by default in `/etc/hostid` unless another path is given with `-o`.
Considering this information, it threw me off a bit that the ZFSBootMenu guide tells you to specify an arbitrary host ID rather than generate a random one:
```sh
zgenhostid -f 0x00bab10c
```
If they must be unique, that seems odd.
The value `0x00bab10c` actually has significance in the context of OpenZFS as an identifier (and leetspeak) for its uberblock. However, it apparently is totally unrelated to host IDs.
Should you be curious still, you can refer to [this GitHub discussion](https://github.com/zbm-dev/zfsbootmenu/discussions/465) where a ZFSBootMenu user brought this exact question to the developers.
According to the answer given above, the uniqueness of host IDs is useful for "multipathed SAS enclosures with two discrete head unis attached", which is an enterprise-grade storage solution.
The value `0x00bab10c` is indeed unrelated and chosen for easy identification. Any value may be used, but when using the pre-built ZFSBootMenu images it may make the process slightly slower (around 250ms) as ZFSBootMenu will have to "discover the hostid every boot".
### Disk variables
Here too, the ZFSBootMenu guide [works with a set of variables](https://docs.zfsbootmenu.org/en/latest/guides/void-linux/uefi.html#define-disk-variables) to make it easier covering different possible storage types:
- `BOOT_DISK`, `BOOT_PART` and `BOOT_DEVICE`
- `POOL_DISK`, `POOL_PART` and `POOL_DEVICE`
My target device is an NVMe at `nvme0n1`, so I'll have:
- `BOOT_DISK="/dev/nvme0n1"`
- `BOOT_PART="1"`
- `BOOT_DEVICE="${BOOT_DISK}p${BOOT_PART}"`
- which evaluates to `/dev/nvme0n1p1`
<br/><br/>
- `POOL_DISK="/dev/nvme0n1"`
- `POOL_PART="2"`
- `POOL_DEVICE="${POOL_DISK}p${POOL_PART}"`
- which evaluates to `/dev/nvme0n1p2`
While this may seem silly at first, it allows using the values separately in the next steps. It also makes the docs a lot more concise while covering several possible disk setups.
### Confirming the environment setup
At this point, we should be able to print something like this in our environment:
```sh
# env | grep ID
ID=void
# hostid
00bab10c
# echo $BOOT_DEVICE
/dev/nvme0n1p1
# echo $POOL_DEVICE
/dev/nvme0n1p2
```
Take care to keep this same environment for all the next steps as they depend on it. For instance, the hrmpf live system ships tmux. While that is great and I have used it throughout, you must be careful to use a single pane for all the actual steps, and the other panes just for secondary things like looking up man pages or checking file contents.
## Filesystem setup
### Wiping
The first step is to clear the current ZFS label information from the device:
```sh
zpool labelclear -f "$POOL_DISK"
```
The `-f` option will "treat exported or foreign devices as inactive", per the man page.
This step fails consistenly for me, which I assume is because the previous filesystem was not ZFS to begin with.
Next, we will use `wipefs` to erase the current filesystem signature.
This command is not ZFS-specific, but part of the kernel utilities. It does not erase the filesystems themselves, nor their content, but the signatures that aid in their detection.
Without any options, it will list all the filesystems that are still visible:
```sh
# wipefs "$BOOT_DISK"
DEVICE OFFSET TYPE UUID LABEL
nvme0n1 0x200 gpt
nvme0n1 0x3d9e655e00 gpt
nvme0n1 0x1fe PMBR
```
The `-a` option is for erasing all signatures. This means it will "scan the device again after each modification until no magic string [signature] is found", as per its man page.
In my case:
```sh
wipefs -a "$POOL_DISK"
wipefs -a "$BOOT_DISK"
```
Along the guide, commands are sometimes repeated for both `$POOL_DISK` and `$BOOT_DISK`. If you are using the same disk for both, this may be redundant, although also harmless.
This is my case, so I am not typically running it twice. I'll still leave it as is however, so as not to mislead the reader.
Now, when listing the signatures again with `wipefs "$BOOT_DISK"`, there should be no output.
Finally, the current MBR and GPT tables must be destroyed. For this, the ZFSBootMenu guide uses `sgdisk`. This is also not ZFS-specific.
```sh
sgdisk --zap-all "$POOL_DISK"
sgdisk --zap-all "$BOOT_DISK"
```
The `--zap-all` option contrasts with `--zap` in that it will destroy both MBR and GPT partition tables.
### Partitioning
In the ZFSBootMenu guide, `sgdisk` is used again for creating the partitions:
```sh
sgdisk \
-n "${BOOT_PART}:1m:+512m" \
-t "${BOOT_PART}:ef00" "$BOOT_DISK"
sgdisk \
-n "${POOL_PART}:0:-10m" \
-t "${POOL_PART}:bf00" "$POOL_DISK"
```
In the commands above, option `-n` is short for `--new`, and is specifying the start and end sectors by using relative kibibyte measures. The format is `--new partnum:start:end`.
Breaking it down:
- `1m` 1 mebibyte from the start of the disk
- `+512m` 512 mebibytes after the default start sector
- `-10m` 10 mebibytes before the last available sector
- `0` the default value
In the list above, "default" is "the start of the largest available block for the start sector and the end of the same block for the end sector", as per the `sgdisk` man page.
`1:1m:+512m`, therefore, means that partition 1 will start 1 mebibyte from the start of the disk and end 512 mebibytes after the start of the largest available block.
`2:0:-10m`, in turn, means partition 2 will begin at the start of the largest available block and end 10 mebibytes before the last available sector.
Option `-t` is for setting the typecode for each partition. Typecode `ef00` is for the EFI system partition, and typecode `bf00` is for "Solaris root", the Unix system upon whose ZFS implementation OpenZFS was based.
For a list of typecodes, see `sgdisk -L`.
While just running these commands as-is is your safest option, you might have a different layout in mind or prefer an interactive UI.
For one thing, I've had issues in the past with the boot partition being too small, so I'll be using `2g` instead of `512m` for it.
`sgdisk` has a friendlier counterpart named `gdisk`, which you can use just by passing it the disk path, as in `gdisk /dev/sda`.
At this point, you should be safe to try partitioning and going back to wiping as needed until you are satisfied.
When you are done, you can use `lsblk` to confirm the results. The following will show you the options just configured:
```sh
lsblk -o NAME,SIZE,TYPE,PARTTYPENAME
```
### Creating the pool
This part of the guide was the one that actually made me want to delve deeper and understand what each option meant.
With little knowledge about ZFS still, I wanted to understand precisely what was happening here, but also what a pool even is and what its creation meant.
Here's the `zpool(8)` man page:
> A storage pool is a collection of devices that provides physical storage and data replication for ZFS datasets. All datasets within a storage pool share the same space.
The definition of a dataset is then indicated to be at `zfs(8)`:
> A dataset is identified by a unique path within the ZFS namespace: <br/>
> `pool[/component]/component` for example: `rpool/var/log`
Here, it's also explained that a dataset can be a file system, logical volume, snapshot or bookmark.
Further information is also hinted to be found at `zpoolconcepts(7)`.
At this point you start to notice the breadth of knowledge available in the documentation. The man pages are not only comprehensible, but sometimes contain several examples on how to apply their concepts. Each command has their own man page named with a hyphen for separation, as in `zpool-create`.
We'll be exploring only the `zpool-create(8)` command in depth, in particular the options used in the ZFSBootMenu guide:
- `-f` force the use of virtual devices, even if they appear in use
- `-o feature=value` set a pool feature
- `-O property=value` set a file system property in the root file system of the pool
- `-o compatibility=off|legacy|file[,file]` specify a compatibility feature set
- `-m mountpoint` the mountpoint (default: `/pool`)
- `pool` the pool
- `vdev` the virtual device
The listing with pool features (including compatibility feature sets) is at `zpool-features(7)`. Pool properties are at `zpoolprops(7)` and file system properties at `zfsprops(7)`.
In the guide, these are the options given:
```sh
zpool create -f \
-o ashift=12 \
-O compression=lz4 \
-O acltype=posixacl \
-O xattr=sa \
-O relatime=on \
-o autotrim=on \
-o compatibility=openzfs-2.1-linux \
-m none zroot "$POOL_DEVICE"
```
Among the options above, several pool features and system properties are set:
- `-o ashift=12` "Alignment shift", used to calculate physical sector sizes.This is discussed at greater length in the [online documentation on Workload Tuning](https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#alignment-shift-ashift)
- `-O compression=lz4` Sets the compression algorithm used ([LZ4](https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)))
- `-O acltype=posixacl` Whether [ACLs](https://en.wikipedia.org/wiki/Access-control_list) are enabled and what type to use. The value `posixacl` is equivalent to `posix` (default on Linux: off)
- `-O xattr=sa` Enables extended attributes. If value is `on`, uses directory-based extended attributes, while `sa` uses system-attribute-based. The latter has performance benefits, and is important for ACLs and SELinux usage
- `-O relatime=on` "Causes the access time to be updated relative to the modify or change time." Also, "access time is only updated if the previous access time was earlier than the current modify or change time or if the existing access time hasn't been updated within the past 24hours"
- `-o autotrim=on` Automatically reclaims unused blocks from time to time. Can put the filesystem under some stress
The last option, the compatibility feature set, specifies in this case a relative filename to `/usr/share/zfs/compatibility.d`:
- `-o compatibility=openzfs-2.1-linux`
`zpool-create(8)` also states:
> By default, all supported features are enabled on the new pool. The `-d` option and the `-o` compatibility property [...] can be used to restrict the features that are enabled, so that the pool can be imported on other releases of ZFS.
The compatibility option `openzfs-2.1-linux` is described as a "conservative" choice in the ZFSBootMenu guide and in my tests had little impact, so I decided to not use it for this installation.
### Creating the filesystems
Once the pool is ready, the filesystems can be created.
For this task, the `zfs` command is used with `create`:
```sh
zfs create -o mountpoint=none zroot/ROOT
zfs create -o mountpoint=/ -o canmount=noauto zroot/ROOT/${ID}
zfs create -o mountpoint=/home zroot/home
```
The ZFSBootMenu guide explains at this point that if `canmount=noauto` is not set on file systems with the `/` mountpoint, the OS will try to mount them all and fail. It goes on to say:
> Automatic mounting of / is not required because the root file system is explicitly mounted in the boot process.
After the filesystems have been created, the boot file system must be set.
```sh
zpool set bootfs=zroot/ROOT/${ID} zroot
```
Essentially, this is saying "set `zroot`'s `bootfs` property to `zroot/ROOT/void`"
### Export, reimport and mount
The next steps consist in exporting and then importing the pool with a given mountpoint.
```sh
zpool export zroot
zpool import -N -R /mnt zroot
```
From what I gather, exporting means putting the pool in a more portable state. According to the `zpool-export(8)` man page, "the devices [marked as exported] can be moved between systems [...] and imported as long as a sufficient number of devices are present."
If `zfs import` is used without any arguments, it will list the exported pools available to be imported.
The `-N root` option imports the pool without mounting any of its file systems, the `-R` option "sets the `cachefile` property to `none` and the `altroot` property to `root`". In this case, that `root` will be `/mnt`.
`altroot` stands for the alternate root directory. In `zpoolprops(7)`, this becomes clearer when it is stated that "this directory is prepended to any mount points within the pool."
Once re-imported, we can mount:
```sh
zfs mount zroot/ROOT/${ID}
zfs mount zroot/home
```
And verify that all is mounted correctly with `mount | grep mnt`:
```sh
# mount | grep mnt
zroot/ROOT/void on /mnt type zfs (rw,relatime,xattr,posixacl,casesensitive)
zroot/home on /mnt/home type zfs (rw,relatime,xattr,posixacl,casesensitive)
```
Lastly, we request the device events from the kernel to update the device symlinks:
```sh
udevadm trigger
```
## Setting up Void
### Installation
So far, not much here was Void-specific. This is when we start bootstrapping the void system into the filesystem we laid out.
```sh
XBPS_ARCH=x86_64 xbps-install \
-S -R https://repo-fastly.voidlinux.org/current \
-r /mnt base-system
```
Here, we are passing an environment variable to set the architecture to `x86_64`, then use `xbps-install` from the xbps package manager to fetch the Void base system.
`-S` takes care of synchronizing the data from the mirror so that package data is fetched, `-R` allows us to manually specify the repository for this run, and `-r` allows choosing a different root directory to act upon.
Here, I chose the Fastly mirror over the ServerCentral one. [Any working mirror](https://xmirror.voidlinux.org/) should do.
Note that not all mirrors have the same content at the root of their URL. Some point directly to a Void repo, some don't. You can access the mirror in a browser or otherwise inspect it to find the path to the `current` directory.
With this done, we can copy the host ID file, which will also be required in our final system, and we are ready to chroot.
```sh
cp /etc/hostid /mnt/etc
```
### chrooting
We will chroot into the system mounted at the `/mnt` directory using `xchroot`, which is part of the xbps `xtools` package and should already be available on hrmpf. It provides a [more sane](https://docs.voidlinux.org/config/containers-and-vms/chroot.html#chroot-usage) chroot than the plain one, in particular regarding the required mountpoints:
```sh
xchroot /mnt
```
This is a good time to get back to the notes I mentioned taking the day before.
![A block of paper with some notes scribbled: "check connection first of all", "reconfigure after chroot", "see /usr/share/doc/efibootmgr/README.voidlinux for automatic EFI entry management", "superb docs", "take the first snapshot ASAP". An arrow points from the last note to "on chroot?" Visible above the block of paper is a keyboard. To the right, the tip of a notebook and a piece of brown cloth are visible. On top of the block, there is a mechanical pencil and a Tombow MONO One plastic eraser.](/assets/img/posts/void-on-zfs/notes.jpg)
#### Reconfiguring packages
After chrooting, it may be a good idea to run `xbps-reconfigure` to make sure packages are properly configured. This is because in the bootstrap process some packets may have tried to configure themselves while relying on directories that were not mounted anywhere.
This is particularly true for [`dracut`](https://github.com/OSInside/kiwi/issues/1867), which is a tool that generates initramfs and initrd images, therefore being critical to the early boot process. You might see error messages related to it in your first run of xbps outside of the chroot, when installing the base system.
To reconfigure **all** packages, just run `xbps-reconfigure -fa`. If you'd rather only reconfigure `dracut`, go with `xpbs-reconfigure -f dracut`.
#### root password
As early as possible is a good time to run `passwd` and set the root password.
#### `rc.conf`
`runit` reads the `/etc/rc.conf` file during startup to configure the system, setting up things like the keymap, hardware clock and terminal font.
For your reference, here is what I added to mine during the installation:
```sh
HARDWARECLOCK="UTC"
KEYMAP="br-abnt2"
FONT="ter-120n"
```
#### Time zone and locale
To configure your local time zone, create a symlink at `/etc/localtime` that points to the corresponding time zone in the `/usr/share/zoneinfo` directory.
```sh
ln -sf /usr/share/zoneinfo/<timezone> /etc/localtime
```
Unless you are using `musl`, you also want to set and generate the `glibc` locales. Edit `/etc/default/libc-locales` and uncomment the desired locales, then run `xbps-reconfigure -f glibc-locales`.
#### dracut
`dracut` generates file system images used by the kernel at the very early stages of boot. We have to make it able to identify our ZFS root filesystem by enabling the proper modules. This is accomplished by creating `/etc/dracut.conf.d/zol.conf` with:
```sh
nofsck="yes"
add_dracutmodules+=" zfs "
omit_dracutmodules+=" btrfs "
```
Notice the spaces surrounding the module names.
## Installing and configuring ZFSBootMenu
We are now ready to install both ZFS and ZFSBootMenu. Let's start with ZFS:
```sh
xbps-install -R https://repo-fastly.voidlinux.org/current zfs
```
Now, before installing ZFSBootMenu, we set the kernel commandline. This is the command line that will be used by the Linux kernel, so any options you are used to go here.
The ZFSBootMenu guide has only the `quiet` option. In my case, I added `net.ifnames=0` to have the classic `eth0`, `wlan0` network interface names, and `fbcon=nodefer video=efifb:nobgrt`, which prevents the manufacturer's logo from showing after boot and sometimes obscuring the boot process output.
```sh
zfs set org.zfsbootmenu:commandline="quiet net.ifnames=0 fbcon=nodefer video=efifb:nobgrt" zroot/ROOT
```
We also need a `vfat` filesystem on our boot device:
```sh
mkfs.vfat -F32 "$BOOT_DEVICE"
```
Now we can add an `/etc/fstab` entry pointing to it, and mount:
```sh
echo "$(blkid | grep "$BOOT_DEVICE" | cut -d ' ' -f 2) /boot/efi vfat defaults 0 0" >> /etc/fstab
mkdir -p /boot/efi
mount /boot/efi
```
Into this directory we just mounted, we can now install ZFSBootMenu.
The guide provides two different paths here: a prebuilt image or the Void package, which you can get through xbps.
While there are advantages to both, I decided to go with the prebuilt image since I'd rather the package manager not touch the boot manager on updating. This has the downside of you having to take care of being aware of any relevant versions and when to upgrade to them.
```sh
xbps-install curl
mkdir -p /boot/efi/EFI/ZBM
curl -o /boot/efi/EFI/ZBM/VMLINUZ.EFI -L https://get.zfsbootmenu.org/efi
cp /boot/efi/EFI/ZBM/VMLINUZ.EFI /boot/efi/EFI/ZBM/VMLINUZ-BACKUP.EFI
```
If you'd rather use the repository package, see the [corresponding instructions in the guide](https://docs.zfsbootmenu.org/en/latest/guides/void-linux/uefi.html#install-zfsbootmenu).
Finally, a second choice has to be made between `rEFind` or plain `efibootmgr` for managing the boot entries. I prefer to go with the simpler one, but you may find `rEFind` more feature-packed.
First, install `efibootmgr` using `xbps-install efibootmgr`, then run the following commands:
```sh
efibootmgr -c -d "$BOOT_DISK" -p "$BOOT_PART" \
-L "ZFSBootMenu (Backup)" \
-l '\EFI\ZBM\VMLINUZ-BACKUP.EFI'
efibootmgr -c -d "$BOOT_DISK" -p "$BOOT_PART" \
-L "ZFSBootMenu" \
-l '\EFI\ZBM\VMLINUZ.EFI'
```
If you'd prefer to use rEFInd, see the [guide's relevant section](https://docs.zfsbootmenu.org/en/latest/guides/void-linux/uefi.html#configure-efi-boot-entries).
`zbm-kcl` is mentioned here in passing. This utility allows you, among other things, to set ZFSBootMenu options, such as the delay before automatically booting. I am not sure if it comes included with the ZFSBootMenu package, as I went for the pre-built image, but you can nonetheless get it from GitHub:
```sh
curl -O https://raw.githubusercontent.com/zbm-dev/zfsbootmenu/master/bin/zbm-kcl
chmod +x zbm-kcl
```
Now, if you want to change an option, you can use its `-a` option to append an argument to the target image's command line:
```sh
zbm-kcl -a 'zbm.timeout=2' /boot/efi/EFI/ZBM/VMLINUZ.EFI
```
In the example above, the timeout before automatically booting is set from its 10 seconds default to 2 seconds.
## Getting out
We are all done. It's time to exit the chroot, unmount and export the pool.
```sh
exit
umount -n -R /mnt
zpool export zroot
```
If all above went well, we can now run `reboot`, remove the flash drive used for installation, and log in for the first time into our new system.
## ZFS snapshot basics
Something you might want to do at this point is to take a snapshot of the current state, since it can serve as a baseline before any further tweaking, allowing you to go back or access the files in this state as you make important changes that could potentially break the system.
```sh
zfs snapshot -r zroot/ROOT/void@baseline
```
Note that, if you followed the ZFSBootMenu guide in creating a separate dataset for your home directory, this snapshot will not include the contents inside and under `/home` (which at this point should be empty anyways).
You can access the contents of a snapshot at any time in the `.zfs` directory at the root of a given dataset. For the ones we previously set up, those would be `/.zfs` and `/home/.zfs`. Note that these directories are not only hidden in the traditional way, but they won't show up even if you use `ls -a`. You need to actually `cd` into the apparently absent directory for it to work.
ZFS snapshots start taking virtually no space at all, but grow with time as the snapshot drifts from the present system state. For that reason, keeping a snapshot of the very first moment of your system can take up significant space. Depending on your storage resources, you might eventually decide to destroy this snapshot:
```sh
zfs destroy -r zroot/ROOT/void@baseline
```
You may also want to list your current snapshots. While typically you can use `zfs list -t snap`, I tend to use the following command in order to get more relevant output:
```sh
zfs list -t snap -o creation,name,used,written,referenced,refcompressratio -S creation
```
Finally, you might want to rename a snapshot:
```sh
zfs rename -r zroot/ROOT/void@baseline @day0
```
Combined, these commands can get you as far as an automatic, rolling snapshot system. Say, for instance you add the following to `rc.local`:
```sh
zfs destroy -r zroot/ROOT/void@fallbackBoot
zfs rename -r zroot/ROOT/void@previousBoot @fallbackBoot
zfs rename -r zroot/ROOT/void@currentBoot @previousBoot
zfs snapshot -r zroot/ROOT/void@currentBoot
```
This would give you a per-boot snapshot trail to rely on.
The `zfs-snapshot(8)` man page provides a similar example for daily snapshots. Considering how simple the zfs CLI is, scripting several snapshot schemes can be quite easy, be them per boot, daily, or even every so many minutes using cron. Because ZFS snapshots grow as they drift from the present state, rotating them is optimal when storage space is a concern.
That's it! I hope this was helpful to you in either learning about ZFS or about Void installations with Root on ZFS.
----
_Originally written June 2nd, 2024_