iPod on Ubuntu

The iPod apparently just turned 10 today. Happy birthday iPod!

As it happens, both my kids have an iPod now, together with a docking station that enables them to listen to all of their music whenever they have a chance. Living in the future is fun! I have fond memories of piling up cassettes containing copies of the greatest albums ever, gathered here and there from friends. Blank tapes were quite expensive so we bought them in Germany where they did not levy the copy tax. I owned maybe 100 tapes in total, maybe 150 albums, the equivalent of a half-Gb today. My sons have each 32 times this on a device that fits their small pockets, without talking about the huge difference in terms of sound quality.

Anyway, my 14-year old has a desktop PC running Ubuntu and I wanted him to be completely independent with his iPod. Turns out he cannot.

Plugging the iPod into Ubuntu works fine: a popup indicates you have plugged a music device, the icon even looks like an iPod, and if you click away you end up starting Banshee or Rhythmbox or whatever you chose to handle music on that desktop.

Things start getting ugly when you add music to the device. Files are transferred and definitely stored there but the iPod does not recognize any of it as music, only “unknown data”. I tried re-formatting the device from scratch on Ubuntu but it failed. I had to re-format it twice again after that: first time on a Mac, which created a Mac filesystem on the iPod that was not recognized on Ubuntu (fffffffuuuuuuuuuuuu), and then on a Windows PC running iTunes to re-generate a Windows filesystem Ubuntu can work with.

Still no love. Whatever I put on the iPod is only visible to Ubuntu. I tried Banshee, Rhythmbox and a couple others to no avail. Back to square one.

I know there must be solutions out there: re-format the iPods with a Linux firmware or help the guys reverse-engineer the latest iPod filesystems for open-source support, but I am just tired with this. I just wanted my son to be independent with his music and ended up spending a whole evening just messing around, piling up experiments and wasting my time Googling my way around.

There is no technical reason why things should be this way. This completely artificial lock-in into iTunes is just ridiculous. I do not know yet which portable music player I will purchase next but something tells me it won’t be from Apple.

Config file hell

xkcd 963 nailed it once again. How much fun is it to have to open one of the zillion Unix config files on your Debian box and start tweaking until it finally works? The graph could just as well show “Time since I last opened wpa_supplicant.conf”, or “/etc/network/interfaces”, “fontconfig”, “httpd.conf”, or “crontab”.

Unix is famous for its configurability. Unfortunately it has never offered a single convenient base library to support configuration file parsing. Every little piece of software had to design its own format, generate its own syntax rules (which complexity mostly depend on the programmer’s talent for parser writing), and force you to learn yet another language that will take you hours to understand and minutes to forget. Examples:

crontab

Seems the syntax for crontab files is just a bit beyond what my brain can absorb. I have set millions of cron jobs in my life and still cannot write one without copy/paste from an existing file.

sudoers

The associated man page does not just describe a set of options, it goes as far as defining a full-fledged language by providing a formal BNF grammar, as if end-users were yacc compilers. It even features significant whitespace. Yummy.

procmailrc

Before we had spam filters, procmail was the only wall between a sane inbox and a wave of unsollicited messages. But there was a heavy price to pay: learn how to write a bug-free procmailrc with no way to test it except to send yourself half a million fake e-mails until you got it right. I still have a couple of procmailrc templates somewhere just in case I ever have to get into this again.

sendmail.cf

Sendmail.cf will probably earn the gold medal of the most obscure, un-debuggable, impossible to write and just frankly insane configuration file there ever was. It is now mentioned in the Geneva convention about the non-proliferation of mental-illness-inducing configuration formats. But let us not be too harsh. Without it we would not have had the case of the 500-mile email and a lot less horror stories to tell our children.

Hopefully things are getting better. Now that we have XML we can tear away the last shreds of hope of ever understanding how to configure a piece of software by editing a file. And if you are really vicious, you could go as far as creating an XML-like config file format that cannot be validated.

I once had a problem, then I discovered XML, and then I had two problems.

Seagate dockstar rescue tips

Seagate dockstar freeagent

My Seagate dockstar freeagent (shortnamed: dock) has recently received a brand new hard disk to cope with my large data needs. dock has been serving me so well over the past months that I decided to entrust the new disk with the complete operating system (Debian) and let it run from there. Little did I know that the brand new hard disk would fail miserably one week later, taking away my only copy of Debian for dockstar. Now I do you unbrick these things again? I spent a couple of nights hunting for information and performing experiments so will document that and leave it here in case it may be useful to someone else.

The boot system

Dockstar is an ARM-based micro-computer with a very interesting feature: the whole boot system resides in flash memory. No grub, no LILO, no messing around with the boot sector every time you upgrade the kernel. Only problem is: out of the box the default dockstar only tries to boot its own PogoPlug system and nothing else. First thing you want to do is replace your stock flash boot by his.

Update uBoot on your Dockstar

In my case I happened to have fried the default Pogoplug installation on dock. I believe this happened when I mounted the flash partition from Debian as jffs2 filesystems. For some reason this corrupted everything on partitions /dev/mtd[123] and I could not recover them from old backups. Fortunately I did not try to mount /dev/mtd0, which is probably what saved Jeff’s boot sequence.

Another excellent point for the dockstar boot sequence is the Marvell bootloader installed in ROM on the device (this one cannot be fried). This is by far the most powerful and user-friendly boot system I have ever seen. You can get the OS from any connected device, from the network, over tftp, you name it. Commands are nicely documented and it is a pleasure to navigate. The only point is: if you want to have a chance to catch the boot sequence while the machine is loading, you need to connect a JTAG cable as there is no video card onboard. Quite unfriendly. The other solution is to ask the boot software to communicate with another machine on the same network. This is achieved by setting a few configuration variables and is completely described here:

Use netconsole to troubleshoot uBoot without a serial cable

You will see incoming console text and will be able to take over the boot sequence from a simple netcat. I cannot recommend enough that you do this before anything bad happens; finding a JTAG cable in the middle of the night is not always easy. Once you have configured dock for netconsole and made sure you use Jeff’s boot system, you should be on the safe side.

Rescue systems

Just in case you end up with no bootable drive as I did, you may want to keep a couple of files handy. Johannes explained on Jeff’s forum how to boot from tftp in this post:

Rescue system for use with USB stick and tftp

I would also recommend to go one step beyond and replace your PogoPlug installation by a real rescue system. Jeff again offers a complete downloadable system that will make sure your dockstar always boots on something even with no network (and netconsole) or USB drives attached.

Recovery system ready for use

Installing Debian

The easiest way to prepare a hard disk for Debian on the ARM-based Dockstar is to boot from it into a minimal system, hook up the destination hard drive and bootstrap Debian from there using debootstrap. This is exactly what Jeff put together on this page:

Run Linux on your Dockstar

Theoretically you could prepare the same hard drive from a very standard PC but debootstrap unfortunately does not support (yet) cross-platform installation. The only way to do that from an x86 or x64 PC would be to run an ARM emulator and run debootstrap from there, using your hard drive as a target. I tried using qemu in ARM mode but got some weird errors and gave up after many tries. If you want to avoid having to become an expert about cross-compilation, better make sure you can boot your dockstar and run the install from there.

As a beautiful side-effect: if you ever decide to move the dockstar Debian to another disk, no need for dd and gparted magic. A simple ‘cp -ar’ can do the trick since you do not have to deal with boot software on the boot sector or such things.

Executive summary

• Do not mount /dev/mtd* under a running Debian. This fscked my flash partitions and restoring with dd proved useless
• Flash your /dev/mtd0 with Jeff’s replacement. Do it now!
• Activate netconsole so you can take over from another PC on the same network
• Replace your default PogoPlug with a real rescue system

Putting the boot loader/manager in flash is a brilliant idea, I wish standard PCs had moved to such an option earlier. The Marvell bootloader is especially versatile with a surprisingly rich online help and excellent capabilities. The booting part is often neglectd by hardware vendors but it proves to make the difference between an expensive plastic brick and usable hardware.

A million thanks to Jeff Doozan for making his knowledge available and accessible!