Random Hubble Desktop Wallpaper

As I settle into my new Arch workstation, I find myself going through all the little nesting behaviors that any user would demonstrate. Only it's a little more challenging this time around, because instead of a user-coddling operating system like Windows or Ubuntu, I'm using Arch Linux. And instead of using a familiar desktop environment like Gnome, I'm using KDE 4.8. So the most basic of things provides an opportunity for learning. For example, I spent a good 30 minutes trying to figure out how to set up the screensaver the other day. It's easy, and very similar to how every other operating system does it; but I just didn't know where to look.

One of my computing goals this year is to stop taking the features and options spoon-fed to me by the desktop environment and instead be willing to step up and exert my own will on the environment. Arch/KDE is a perfect combination for this, because they are both all about basic building blocks and customization. In my previous installation (Ubuntu 10.10), I had a little python script that I grabbed from Christian Stefanescu that will download the NASA image of the day and make it your desktop wallpaper. I still have that script, and I could use it with a few modifications for KDE instead of Gnome. But NASA's image of the day is hardly ever cool things like stars and galaxies, and instead is usually pictures of people smiling for the camera, or close-ups of a really important and boring piece of metal. I want something with some curb appeal.

I looked into a few other daily-image sites, like Alta Ski Area and National Geographic, but they just aren't designed to be wallpapers - the resolution is too small to look good at 2048x1152, and they're frequently in portrait-mode, which looks terrible on my widescreen monitor. Of course, Murphy's Law dictates that today when I go look at those sites to get the links above, they both are showing images that would look great as wallpapers. Trust me, they're the exception, not the rule. But I digress.

The official Hubble Site has a bunch of fantastic images in its gallery, but they don't pick one a day for you. There is a main page that shows thumbnails of all the images, a resolution-selection page when you click on a particular image, and finally another page that displays the image inline. I figured I could probably handle this with a Perl script, so I grabbed the HTML::Parser package from CPAN to do the heavy lifting, and did a little reading of its description page. It treats the incoming HTML document like a hierarchical tag system, just like most XML parsers do. I've never used an HTML parser before, but I wouldn't be surprised to learn that this is standard - it makes the most sense. You start by deriving your own class from HTML::Parser, and write start() and end() callbacks. Then as each tag (<div>, <a>, <img>, etc) is opened by the parser, it sends interesting info to the start() callback. When it closes, it calls the end() callback. In this way the entire tree of HTML is traversed, in a depth-first fashion.

Wallpaper Thumbnails

Resolution-selection

2048-wide image

Being a Perl newb as well as an HTML::Parser newb, I did the easiest possible thing, which was to define three different classes - each tailor-made for one of the three pages that were required for finally getting the image. There is no error-checking or customization capability - paths are all hard-coded, and if anything goes wrong the script will probably just crash. But that means my wallpaper won't change for a couple days, or until I have time to investigate -- not exactly life-threatening. This is another example of utility code that simple doesn't warrant any more attention than is necessary to get it running. I finished it in about an hour.

I have this script scheduled to run every day at 4:00 pm, because that's about the time I get home from work and turn on the computer. It makes me happy to see a new wallpaper appear out of nowhere as I'm getting my email and paying bills. And after all, isn't that the point?

Download the source code if you're interested.

Recovering an Unbootable Kernel Image

This is a quick how-to on rebuilding an Arch Linux initramfs image when both the main and fallback images are unbootable. This can happen if something goes wrong during an update to the "linux" package and the problem isn't detected and solved before a reboot. This post draws information from the Arch Wiki articles Change Root and mkinitcpio, as well as an Arch Forum post discussing a path problem causing an unbootable image. All the information necessary to recover is contained within these three links, but I felt that a cookbook would be helpful, especially in the stressful moment when a vital computer is sitting at the limited shell prior to booting the kernel.

This is intended to solve the specific problem when the Arch bootstrap claims it can't find the boot drive, and when it is very unlikely that the hardware is actually having a problem. In my case, I experienced this with regularity on a Virtual Machine, which was not having virtual hardware failure. It turned out to be exactly the problem in the forum post described above, but first I needed to recover the system.

Step 1 - Get It Booted
Your system isn't going to boot on its own: both the primary and fallback boot images are refusing to behave. So go get yourself an Arch ISO and burn it to CD or a USB. If you've already installed Arch, you know how to do this. Or read the Arch Wiki article about it if you've forgotten. Use the download and burn process as an opportunity to take a deep breath - that will help with the remaining steps.

Boot from the ISO, and choose the first option from the ISO's boot menu. But don't start Arch setup. Instead get the network running so you can update with pacman.

# aif -p partial-configuration-network

Answer the prompts. If this first step doesn't go well, don't sweat it - it just means you won't have internet access, which probably isn't required anyway.

Step 2 - Take Stock
We need to manually mount all the necessary partitions, and to do that we need to know what they are. If you remember how you partitioned your disk, that's great. But if you don't remember exactly which /dev/sdaX goes where, you'll need to do a little guessing. Luckily, fdisk can help. Note that I've trimmed the output some for brevity. I've also cheated a little and typed in some partitions from gparted because my /dev/sdb uses GPT.

# fdisk -l

Disk /dev/sda: 100.0 GB, 100030242816 bytes
   Device Boot     Start         End      Blocks   Id  System
/dev/sda1   *         63     3903794     1951866   83  Linux
/dev/sda2        3903795   195371567    95733886+  83  Linux


Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
   Device Boot     Start         End      Blocks   Id  System
/dev/sdb1             31 3871748080   3871748047   83 Linux
/dev/sdb2     3871748081 3907029134     35281054   xx Linux-Swap

On my system I have a roughly 2GB bootable ext2 partition on /dev/sda1 and the remainder of the 100GB SSD is ext4. I have a 1.8TB data partition at /dev/sdb1, and my swap file is /dev/sdb2. This is enough information for me to remember that sda2 mounts to / and sdb1 mounts to /caviar but contains the /var directory, which is sym-linked over from sda2.

If fdisk isn't enough to jog your memory, you may need to test-mount and explore a little.

Step 3 - Mount and Prep

Once you know which partitions you need to mount where, get it all mounted under /mnt/arch. Also mount the proc, sys, and dev directories so they'll be available to your chrooted sandbox.

# mount /dev/sda2 /mnt/arch

# mount /dev/sda1 /mnt/arch/boot

# mount /dev/sdb1 /mnt/arch/caviar

# mount -t proc proc /mnt/arch/proc

# mount -t sysfs sys /mnt/arch/sys

# mount -o bind /dev /mnt/arch/dev

In case you need to update with pacman, you'll want network access. If you got the network running in Step 1, copy the resolv.conf down into the chroot world.

# cp -L /etc/resolv.conf /mnt/arch/etc/resolv.conf

Step 4 - Chroot and Fix

Next, jump into your sandbox.

# chroot /mnt/arch /bin/bash

Now that you're here, feel free to poke around in logs to see what might have gone wrong. In my case, I had stupidly run pacman -Syu --noconfirm from a cron job without setting the PATH to include /sbin. As a result, the update script failed to call depmod but then blindly ran mkinitcpio on the incomplete map files, rendering the image stillborn. The depmod result should really be considered during a linux upgrade so that mkinitcpio doesn't trash the boot image, IMHO, but what do I know.

For now, let's assume you have the same problem I did. To resolve it, all I needed to do was the following:

# /sbin/depmod

# mkinitcpio -p linux

As a precaution, I also did a full update with pacman and made sure that everything went smoothly.

# pacman -Syu

All was well, and I was able to reboot into my system again. 

Happy 1986, Part 2

Last month in the Year-a-Month project, I decided to split 1986 into two installments to control costs. This month is the second installment! I was mainly disappointed in the results last month, but I'm happy to say that 1986 has been redeemed.

Accept: Russian Roulette - In December (1985), I pointed out that Accept was starting to sound too much like AC/DC. They cleaned up their act somewhat with this album, returning to a more traditional heavy metal sound for most of the tracks. There are still the occasional low points, like the first part of the title track. But by and large Accept sounds more like Overkill on this album than AC/DC.

Iron Maiden: Somewhere in Time - I'm always happy when I have a chance to add to my Iron Maiden collection, and this album is no exception. Unwilling to follow the 2nd-person romantic lyrical cliche of so many other bands, Iron Maiden uses a great deal of imagery to imply the meaning in their songs, instead of just whipping it out and laying on the table for all to see. I'm no expert, but to me, that's poetry. And it rocks. Win-win.

Megadeth: Peace Sells... But Who's Buying? - Megadeth is a much more technical guitar sound than anyone else this month. It's always nice to have a stand-out, even when the crowd is as good as these other albums are. Mustaine, at this point in his career, is still pretty annoyed with Metallica. So his rage is pretty thick, and that translates into the guitar riffs. In a good way.

Motörhead: Overkill - after trimming out the duds last month, I found myself with too much to order all in one month, but not enough for two months. I have an easy solution to that: a catch-up album with Motörhead! This one is from 1979, and let's face it: it sounds just like every other Motörhead album. If you like road-metal about drinking, drugs, groupies, and sleeping on a bus, then you'll like this album as much as I do.