The thing just works. It does everything we need except maybe picking
arbitrary labels for RAID arrays (and that might even be possible to
work around).

By using a configuration file and setup-storage, we bring ourselves
closer to standardizing and automating the installer.

setup-storage also has the advantage of being idempotent, mostly: I
was able to run and rerun it multiple times from the rescue shell. The
only thing I had to do was to close LUKS devices, if I remember
correctly. But it was much easier to test than a shell script.

Finally, it provides nice features like dumping the fstab, crypttab
and mdadm.conf for us to use. We don't use those just yet.

It also provides a shell script that can be sourced to get various
targets, which we use.

We were assuming the disk setup would, which is counter intuitive.

mostly to note down the parts that will go away

we're still on track though

This is in preparation to communicating to service admins.

The rationale of this is that we want to speed up the upgrade process
and not let the upgrade wait for operator wandering away in another
distraction. Inversely, it allows operators to exactly do other things
instead of just staring at the terminal, waiting for the process to
complete.

This assumes users either like bell noises or have turned them off in
their terminal. In my case, the terminal is set to send a "urgent"
signal to the window manager when it receives a "bell", using this
Xresources configuration:

    URxvt.urgentOnBell:  true
    XTerm*bellIsUrgent:  true
    XTerm*visualBell: false

In i3 with i3status (and py3status), the affected workspace gets a
nice red background, telling me the upgrade is waiting for my input.

This reduces the clutter of recording files left lying around.