The Jack-of-all-trades Ubuntu Installation (Part 1)
A wish-list for the features of my Ubuntu installation would look like this:
- Has system-wide encryption (LUKS)
- Has logical volume management
- Can handle modern UEFI bootloaders
- Can combine one small and fast 128G SSD and one large ans slow HDD into a pool to create a logical hybrid drive
- Offers dual-boot for Windows (preferably from GRUB)
Another nice-to-have feature would be a file system that allows to take snap shots or has some kind of versioning implemented so that we can revert to a previous state in case of the “usual calamities” (botched system upgrades etc.). We leave that point out because none of the sources I consulted for the first 5 features addressed snap shots. While LVM seems to have snap shot functionality, it looks to me that versioning, rollbacks and snap shots primarily boil down to the file system choice. As we are going to stick to the tried and trusted ext4 file system whenever possible, we will have to go without snap shots and versioning.
What other people already suggested
There are quite a couple of tutorials and blog posts in which people describe how they achieved to set up their Linux installations in way that at least a subset of our desired features can be achieved. Here’s a list of references which were really useful for me:
| Reference | Included features, Pros | Missing features, Cons |
|---|---|---|
| b_laoshi on askubuntu.com | LVM, LUKS, UEFI | Dual boot implicitly mentioned (“other partions – existing OSs: we don’t care about these) but not elaborated. SSD caching and FS versioning missing |
| Mike Kasberg | LVM, LUKS, Dual Boot Win, UEFI | No SSD-caching, FS versioning |
| Lukas Werkmeister | LVM, LUKS, bcache caching (UEFI) based on Arch Linux | Dual Boot, instructions for CLI based installation not applicable to Debian based distros, FS versioning |
| labbots on github | LVM, LUKS, detailed instructions on UEFI boot partitions | Dual Boot, SSD-caching, FS versioning |
| Arne Rantzen on rantzen.net | LVM, LUKS, UEFI, caching with bcache, instructions based on elementaryOS | FS versioning |
The stone that kills most birds with a single throw is the solution offered Arne Rantzen which is based on a posting by solsTiCe on askubuntu.com. Unfortunately this post has been taken offline, so it’s only available on the Wayback Machine. Just in case the archived version also vanishes one day, here’s a backed up PDF version.
Preliminary Considerations
It is interesting to compare in which way the implementations listed in the table above differed. The main differences I discovered among their approaches are:
UEFI or Legacy Bios?
As we want to add a boot option for Windows 11, we are forced to install everything inside an UEFI framework. Arne Rantzen demonstrates his installation procedure based on Legacy BIOS but adds some remarks what to observe in case UEFI is used.
LUKS inside LVM or LVM inside LUKS?
Arne Rantzen’s solution is to
- first create a virtual hybrid drive from an SSD and a HDD,
- then encrypt the whole hybrid drive with LUKS and afterwards
- set up the LVM inside LUKS.
Other approaches (such as the one by Werkmeister goes the other way round and puts a LUKS container inside an LVM structure – but that did not work for me (maybe because I am unfamiliar with Arch Linux CLI installs).
lvm caching or bcache?
To obtain a virtual hybrid drive that caches the most frequently accessed data in a fast SSD partition and directs rarely accessed data onto the cheap but slow HDD we can either use LVM’s built-in caching functionality or the separate bcache package.
From what I found on the net, there have been several reports on irrecoverable loss of data in connection with bcache but none with LVM caching. Furthermore, bcache is no longer actively maintained by its developers and has not received any updates for years while the whole LVM suite can boast continuos developments and updates.
The advantage of bcache is that it offers (slightly) faster read/write performance than lvm cache. Furthermore, it was developed with a particular focus to preventing wear decay on SSD drives. While harnessing a fast SSD and a slow/large/cheap HDD into a virtual hybrid drive was one of multiple applications for lvm cache pools, it was the one and central design scenario for bcache. Last but not least, bcache is said to be easier to set up – which I can vigorously confirm in the sense that none of my lvm cache set ups worked but the bcache approach as shown by Arne Rantzen worked like a charm at the first attempt.
Therefore I will have to go with bcache – although I would have preferred a solution based on LVM given that it’s not EOL software and there have not been any reports regarding catastrophic data losses.
To swap or not to swap?
Traditionally, swap memory had two functions: First, to act as a (dead slow) overflow buffer to store RAM data in case your RAM memory is exhausted. This feature of swap still comes from the days when RAM was scarce and expensive and you were king of the hood because you ran a machine with 1 GB RAM while all your peers could barely afford machines with 256 MB.
A second function of swap space is to dump the whole RAM content when you send your system into hibernation. Once the content has been written to the swap space RAM can be disconnected from power. When the system is woken up again, the HDD content is written back into RAM and the machine state that was there when it went into hibernation is exactly restored.
Now you will probably have discovered already that RAM has become ridiculously cheap and is there in abundancy. My workstation features 24 GB of RAM and even with running virtual machines, I never came close to running out of RAM. As for the hibernation: This feature has disappeared completely from the Desktop menus of leading distributions. Both Windows and Linux distributions now only have a ‘Suspend’ mode which dumps the system state into RAM (not onto HDD/swap). So no need for a swap partition either.
So my decision is to go completely without a swap partition. This also has the advantage that I do not have to worry about questions like: Can I be sure that my swap space does not contain unencrypted data? How do I have to set up swap to ensure it’s encrypted? Can I be sure that there are no bugs or exploits that allow to bypass swap encryption?
Let’s start to install…
With all these premediations completed, let’s start to install. Here’s the link to the installation notes.