A couple months ago I wrote about my early experiences running my os off of a usb flash drive. If you haven’t read that, go do so and come back.
Since then I’ve bumped into a few things worth writing about. Here goes:
At some point I screwed up the bootloader (syslinux), such that selecting a menu item just caused a brief flash (like the menu redrawing, slowly), and didn’t actually boot anything. I kinda freaked at this point, was afraid I’d killed the flash drive, and went back to using internal storage for a few weeks. This was something I’d been prepared for since the beginning, so I had recent backups.
It turns out I was wrong, the drive was fine. I ended up reinstalling and using it again, and now I have…
Full Disk Encryption
Frankly, the idea of possibly losing this thing, and have there be a
drive out there for someone to find with that much data about me is
scary. When I reinstalled, I decided to protect myself from this, via
LUKS. I more or less did this, with very little
modification. Again, the device needs to be specified via UUID, since
other ways of identifying it may change from one machine to another. For
/etc/fstab, this only really affects the
/dev/mapper/cryptroot, so the raw partition doesn’t appear in
fstab at all. We still to tell the kernel about all this via its
command line arguments. The relevant ones for me are:
In addition to the arguments that would be there anyway for normal reasons.
So I set all of this up using my laptop as the installation machine. (As
an aside, the
arch-install-scripts package works just as well from an
installed system as it does the live media.) When I then booted the
system on my laptop everything was fine. I hit a snag with my desktop
When you use full disk encryption, you need some way of decrypting the file system during boot. Typically (and in my case), this requires entering a password. This, in turn, requires a keyboard. Mine wasn’t responding.
I played with a few things trying to figure this out, including moving
things around in
/etc/mkinitcpio.conf, and double checking
keyboard hook was included. Then I thought to try the
fallback image, which worked.
In a typical Archlinux setup, there are two initial ram disks sitting
/boot, a standard one and a “fallback”, each of which have entries
in the bootloader menu. The difference is what kernel modules are
included in them. When the default initrd is generated, the system tries
to detect which devices are actually on the machine, and only include
modules that are needed to boot the system. Supposedly this improves
boot time somewhat, since there are fewer things to probe.
The fallback image makes no such attempt; if it is asked to include keyboard support, it includes support for all possible keyboards - not just the integrated one in my laptop, but also usb keyboards for example.
The problem should now be obvious. The solution was simply removing the
“autodetect” hook from
/etc/mkinitcpio.conf. This means that both initrds
are effectively the same, incidentally.
While I was redoing the installation, I put a couple more things in tmpfs, specifically:
/var/tmp, for the same reason as
/tmp, though this doesn’t seem to be the default on arch for some reason, whereas it is for
/tmp. I’ll have to look into why.
$HOME/.cache, Just for my own user account. The main thing that ends up being stored here is my web browser’s cache, which really doesn’t need to be persisted to disk.
One might think putting things in tmpfs is a good performance trick, but if there’s a real impact I haven’t noticed it. This actually isn’t all that surprising - even if your data is persisted to disk, the kernel will still keep a copy in memory for performance reasons, so as long as the disk cache is reasonably intelligent, this shouldn’t make a difference.
IO has always been the big performance concern with this setup. In my previous post I had mentioned that it was certainly usable, but now I’ve added another layer to the storage in my system (encryption). How has this affected things?
It’s a little worse, but still usable, and for most things the difference isn’t any more noticeable. Notmuch takes noticeably longer than it did without the encryption, though not enough to really impact usability.
The one new issue that is a bit annoying is that I’ll occasionally get random stalls, where, for example, a shell will take 4-5 seconds to open. These aren’t frequent enough to be a serious problem, just a little annoying.
These little stalls haven’t affected anything I do that would really be disrupted by them. Things like watching video, listening to music, and other soft real-time tasks still work like a charm. Large compile jobs seem to be sufficiently CPU bound that this still isn’t the bottleneck, which I expected but was still a bit surprised to actually see.
A few times since I wrote the original post, I’ve booted up on a machine with Windows installed on the internal storage. This causes one issue, namely, the clock is set to local time. All of my other machines have the hardware clock set to UTC, and the OS expects this. So the clock is wrong on these machines. I haven’t found a proper solution yet, and it’s only been a minor annoyance thus far.
I’m still in a state of slight disbelief at how well all of this has worked.