Life Without Internal Storage: Status Update

12 Apr 2014

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:

Corrupted Bootloader

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 /boot partition; / is actually /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:

cryptdevice=UUID=17154f1c-3d31-49cd-8cbd-538f3a125890:cryptroot root=/dev/mapper/cryptroot

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 however.

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 HOOKS in /etc/mkinitcpio.conf, and double checking that the 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 in /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.

More Tmpfs

While I was redoing the installation, I put a couple more things in tmpfs, specifically:

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.

Hardware Clocks

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.