Joe's Random Ramblings

I've had a NAS (Network Attached Storage) box for years. I've been using a 1-TB RAID 1 setup for it. That 1 TB got used up. 99% full.
Since the manufacturer, D-Link, doesn't sell this particular model anymore, they haven't updated the firmware in years. Their firmware limits the disk size to 2 TB.
I thought I'd have to buy a new NAS device to be future-safe for bigger storage media.
But, I recently became aware of an Open Source firmware for these D-Link NAS boxes, called Alt-F. Alt-F supports disks up to 4 TB.
I installed ALt-F on my D-Link NAS last weekend. It worked without problems right out of the box.
So, on Monday, I ordered 2 4-TB SATA drives to put in the NAS. They arrived today. Put them into the box, selecting RAID1, and off we go.
I am right now transferring data from my 1 TB drive to the new 4 TB disk array, having connected one of the 1 TB disks to my Linux box.
I initially had some minor issues with mounting the old drive, because it's one disk out of a Linux Software RAID.
As it turns out, Linux detects the drive as a RAID drive, and creates a /dev/mdx entry, but doesn't really tell you about it. And it doesn't let you mount it, either, because it's only one disk from the RAID.
The technical desciption:
After googling a bit, I found that a 'cat /proc/mdstat' shows you if Linux detected the drive. If I close the /dev/md127 device that Linux gave me on bootup, with mdadm -S /dev/md127, I can then use mdadm --assemble --force on the device, and then I can mount it normally as an ext3 partition. That was all I needed to be able to copy files from the old drive to the new drives in the NAS. Even with a GBit network connection, it takes a while to transfer 1 TB...
This is what df reports right now:

Filesystem                    Type            1M-blocks    Used Available Use% Mounted on
/dev/md0                      ext3              936374M 918270M    18104M  99% /mnt/hd
192.168.2.110:/mnt/md0/       nfs              3754944M  57527M  3697401M   2% /mnt/nas

This probably has happened to a lot of people:
You think you have backed up your files with tar, but when disaster strikes, and you need to restore the files, you find that your tar archive is corrupted...
This happened to me this weekend, and seeing the dreaded "bzip2: Data integrity error when decompressing" error (the tar file was compressed with bzip2,) I had pretty much resigned myself to an hour or two of hex editing to skip the damages files and stitch the tar file back together...

But the Internet to the rescue
It turns out somebody already did the hard work, and has a handy Perl script on his website to find the next file header in the tar archive.
So, all that needed to be done was to run the Perl script and then tail to skip the broken parts. The details are on the aforementioned website.
I had the good files out of the tarfile in a few minutes. This is why I love Open Source

Update: the author of the Perl script I used now has made available an even easier tool: repair corrupt tar archives ? the better way.

In light of all the idiotic and illegal NSA snooping, I decided to do full-disk encryption on my Nexus 7 tablet and my Nexus 4 phone. That works all great. This should keep the criminals at NSA, as well as the TSA and Border Patrol out of my devices. My computers at home have had full-disk encryption for a while already...

Anyway, in a side-effect, the CyanogenMod updater, as well as the Clockworkmod recovery, don't know how to handle the encrypted data partition, so installing a CyanogenMod update fails.
Of course, the command line is always helpful...
So, here is how to upgrade CyanogenMod with an encrypted device:

1. Connect the phone to your computer using a USB cable
2. If you haven't already, install the 'android-tools' package
3. Download the CyanogenMod archive you want to install, from get.cm.
4. Reboot your phone into recovery mode.
5. Once recovery is up, select "Install zip from sideload". Note: This is with the Clockworkmod Recovery, your recovery may have different options.
6. On your computer, type "adb sideload <the_downloaded_cm_archive>", e.g., "adb sideload cm-10.1-20130706-NIGHTLY-grouper.zip"

That's it. Works like a charm.

BTW, it is also a possibility to use TeamWin's recovery. TWRP can unencrypt the data partition, unlike Clockworkmod.

Update: Since writing this post, I have switched to TWRP and use that on all my devices.
One slight issue with the disk encryption is that by default, the encryption key is the same as the unlock PIN or password. Usually, the unlock PIN or password is pretty short, since it is entered several times during the day.
There are programs in the Google Play Store that separate the disk encryption password from the unlock PIN or password. An example is the CryptFS Password Manager. I highly recommend using that or similar tools (or the command line) to use a strong password for the full-disk encryption.

Another update: With CM12, a couple of devices, e.g., the OnePlus One, which is by now my main phone, use hardware encryption, with a proprietary library. TWRP doesn't yet work with that, so it is not possible to decrypt the /data partition in TWRP. adb sideload works, because in CM12, the sideloaded file is saved to /sideload, which is on the root partition.
Another update: TWRP from version 2.8.6.1 handles decryption on the OnePlus One, and possibly on other modern devices.

Essentially a "so long and thanks for all the fish".
Further development on Thunderbird is coming to a halt.

20 years ago today, Linus Torvalds posted the first message about this new operating system he was writing.
Linux has come a very long way from these humble beginnings.
Nowadays, it powers everything from phones (Android) to mainframes. Whole companies rely on Linux, and probably wouldn't exist in their current form if it wasn't for Linux (e.g., Google.)
Thanks, Linus Torvalds, for this awesome OS.