Or: burgled-batteries isn't dead or forgotten, I've just been busy.

One of the downsides of liberally relying on CFFI internals is that changes to those internals can easily result in breakage, and some of the cffi-libffi changes did so. It took me entirely too long to get around to it, but I've finally updated burgled-batteries so it will actually run against CFFI in Quicklisp. Actually moving to the new style of (:struct *) and (:pointer (:struct *)) identifiers remains to be done, so there are a fair number of style warnings to ignore, but at least it will run.

I've also moved burgled-batteries to git. The official repo URL has not changed (it remains http://repo.kepibu.org/burgled-batteries), however there is also a github mirror, which may be moderately more useful if you'd like to browse the source or changes without cloning the repo, as it will undoubtedly be a while before I've got time to set up gitweb on my own host and get it functioning seamlessly in parallel with darcsweb.

Conveniently timed to my previous entry I recently upgraded my laptop to Debian Wheezy. This involved redoing my backup boot drive to contain bootloader updates, so I can detail the process I used.

Partition the USB drive

Use whatever partition manager you're comfortable with. cfdisk, fdisk, gparted, whatever.

# cfdisk /dev/sdb

If you want to use the USB stick on Windows normally, note that Windows will only see the first partition of a thumbdrive. This is great for hiding the fact it's a bootable drive!

# fdisk -lu /dev/sdb
...
Sector size (logical/physical): 512 bytes / 512 bytes
...
DeviceBootStartEndBlocksIdSystem
/dev/sdb18064142598157125876bW95 FAT32
/dev/sdb2*142598161524057549038083Linux

Don't start the first partition at the very beginning. Here I've got it started about 4k in. This gap is important: grub will install itself into the gap--if there isn't enough room, grub won't install.

You'll also notice that I've allocated 512MB to what will become /boot (sdb2). This is serious overkill, but also means I don't have to be particularly cautious about uninstalling old kernel versions to avoid running out of room.

Format the Partitions

Naturally, we should format these partitions:

# mkfs -t vfat /dev/sdb1
# mkfs -t ext3 /dev/sdb2

Install grub

Then mount our soon-to-be /boot drive into /boot (if you're familiar with grub-install, you can mount it elsewhere):

# mount /dev/sdb2 /boot

And install grub:

# grub-install /dev/sdb

Naturally, your next step should be to test that it boots. And maybe even test that it appears as a normal thumbdrive on a Windows computer.

When Doing a Fresh Install

NB: This is from-memory. I have not done this recently.

If you're doing a fresh install, partition the USB drive from another computer. Make sure the thumbdrive is plugged in during the install process, and when configuring drive partitions and directory locations, simply select /dev/sdb2 (or whichever is appropriate for the USB drive's second partition) as the device on to which to put /boot.

In order to protect any sensitive data on my work laptop, I use full-drive encryption. To aid recovery in case of theft, it normally boots to a honeypot installation of Windows with Prey installed. To boot into Linux, one must use a USB boot disk[1] which contains the contents of /boot.

Once in a while, it is necessary to upgrade the kernel. I don't do this very often, so it seems like the sort of process which should be documented.

  1. Mount /boot read-write: `mount -o rw /boot`
    I generally have /boot mounted read-only, in part because I don't usually have the thumbdrive plugged in (I don't boot very often, after all), and to ensure I don't accidentally make changes to it without being prepared to undergo this full process.
  2. Install kernel updates: `sudo aptitude full-upgrade`
  3. Reboot. Pray it works.
  4. Insert backup boot disk. (Just in case the thumbdrive on my keychain goes bad or gets lost.)
  5. Copy files from the updated boot disk to the backup: `rsync -av /boot /media/usb2`
  6. Remove the original boot disk. This will help prevent unfortunate mistakes.
  7. Alter grub.cfg of backup boot disk to refer to the proper UUID: `sudo sed -i s/$UUID_OF_BOOT/$UUID_OF_BACKUP/ grub/grub.cfg`
    `blkid` comes in handy for finding the relevant UUIDs.
  8. Reboot. Pray it works.

Assuming both boot disks successfully boot the machine with the updated kernel, congratulations! You have successfully updated the kernel!

[1] It's not quite as much a waste of a thumbdrive as you might think. The sticks have a FAT partition of ~90% or so of the advertised capacity, so they can still be used to transfer files between computers or for data storage.

If you happen to be lax in upgrading software, you might have an older version of magit where if M-x magit-status is allowed to initialize a git repository where none was before, it has a tendency to create said repository in the directory '$HOME/repo/~/repo'[1].

If this happens, and one wishes to remove that annoying and non-useful '~' directory, do not, I repeat, do not run the command:

rm -r ~

That is bad. Remember shell expansion! You need to quote the tilde:

rm -r '~'

But also note that even the latter should not be done within eshell, as it seems to be intent on expanding the tilde anyway. Use a real shell.

Also, always do `ls $dir` before you do `rm $dir`, just to double-check what you're deleting. Even if you're sure, check anyway.

Because otherwise, you might accidentally delete your home directory.

On the bright side, I can now confirm my backups work.

[1] see bug 383

I recently renewed my driver's license. There were a few changes from the last time I did it, and they aren't really for the better.

First, they now require removal of glasses, hats, and human expression from your picture, to aid the facial recognition software used. While I offered a mild objection to removing my glasses and having a blank expression, it regrettably did not occur to me to state my objection to the usage of facial recognition software at all until after I was done.

Wish I had, though. For several reason: first, because I do object to the government using facial recognition software on my pictures, or really storing any biometric data on me at all; and second because I want to know if there's a process to handle such objections. Obviously the DMV is not the place to effect change, but knowing if there are procedures in place for objections would at least give me a place to start.

Well, I had always planned on moving out of state eventually, anyway. I guess I'll add "DMV uses facial recognition software" to the list of reasons to leave, and the list of things to check for any place I might otherwise be inclined to move to.

Second, they no longer provide your actual license. Instead, they provide a temporary paper license and mail the real one. So now, instead of potentially being lifted by someone showing their face who would have to look similar enough to fool the person giving it to you, your license can be lifted anonymously by someone within the postal system, or anyone with access to your mailbox. This is apparently so they can take time to more carefully verify your identity to prevent identity theft, so the fact it makes licenses easier to steal is hilarious.

Third, unless you specifically object, signing up for a license now automatically enrolls you into the selective service database if you're eligible. While I object to the very existence of that database, auto-enrollment makes vastly more sense than the manual enrollment that was supposedly mandated when I was within the eligible age range.

It gets harder and harder to keep a low data profile. Le sigh.