Building a home file server with Debian 8.2 (jessie): Part 2

I was able to finish setting up the storage array once I received all three of the new 4TB disk drives.


After racking the new drives I first tried partitioning them using fdisk. I quickly realized fdisk does not support partitions larger than 2TB. So, the next step was to install GNU Parted using apt-get install parted.

Then, I created full 4TB partitions on each drive:

parted -a optimal /dev/sdc
parted -a optimal /dev/sdd
parted -a optimal /dev/sde

This starts parted in an interactive mode using the optimal disk alignment. The commands should be pretty self-explanatory but I basically followed the below tutorial:


The next step was to create a RAID array using the new partitions. This command was the one I used:

mdadm --create --verbose /dev/md1 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sde1

Note, that upon restart I noticed the array was being defined as /dev/md127. To fix this issue I updated mdadm.conf to explicitly define the new array and ran update-initramfs -u. Upon restart the new array comes up correctly as /dev/md1.

See below for the contents of my mdadm.conf.

# mdadm.conf
# Please refer to mdadm.conf(5) for information about this file.
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=e3b2b47d:47b61e06:1464f958:737d6621 name=lin:0
ARRAY /dev/md/1 metadata=1.2 UUID=741d95f5:fafbc130:e1a17128:41d9ed3c name=lin:1


The next step was to use LVM to create a virtual drive on top of the RAID volume. Then, format the new volume using ext4. I chose an initial size of 2TB for this new volume since that’s enough space to accommodate my existing files. This will leave nearly 6TB for later use.

pvcreate /dev/md1
vgcreate vg2 /dev/md1
lvcreate --name storage --size 2T vg2
mkfs.ext4 /dev/vg2/storage


The new volume needs to be mounted so it can be used.

mkdir /mnt/storage
mount /dev/vg2/storage /mnt/storage

I then updated /etc/fstab to mount the volume on reboot.

See below for the contents of my fstab.

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vg1-rootfs  /               ext4    errors=remount-ro 0       1
/dev/mapper/vg2-storage /mnt/storage    ext4    errors=remount-ro 0       0


Now that the volume is mounted I could begin transferring files from my old server. I used rsync for this task.

rsync -rthvv --progress --exclude .AppleDouble --dry-run


At this point everything is working quite well. However, I did notice one oddity.

root@lin:/home/tristan# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/dm-0                229G  1.6G  216G   1% /
udev                      10M     0   10M   0% /dev
tmpfs                    3.1G  9.3M  3.1G   1% /run
tmpfs                    7.8G     0  7.8G   0% /dev/shm
tmpfs                    5.0M     0  5.0M   0% /run/lock
tmpfs                    7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/vg2-storage  2.0T  428G  1.5T  23% /mnt/storage
tmpfs                    1.6G     0  1.6G   0% /run/user/1000

Note the above output from the df -h.

You’ll notice that the first LVM volume, where the system root is installed, is referenced by /dev/dm-0 (short for “device mapper”). However, the second LVM volume is referenced by /dev/mapper/vg2-storage instead of /dev/dm-1 as expected.

Note that /dev/mapper/vg2-storage is simply a link to /dev/dm-1.

root@lin:/home/tristan# ls -al /dev/mapper/
total 0
drwxr-xr-x  2 root root     100 Jan 31 22:40 .
drwxr-xr-x 21 root root    3280 Jan 31 22:40 ..
crw-------  1 root root 10, 236 Jan 31 22:40 control
lrwxrwxrwx  1 root root       7 Jan 31 22:40 vg1-rootfs -> ../dm-0
lrwxrwxrwx  1 root root       7 Jan 31 22:40 vg2-storage -> ../dm-1

I haven’t yet figured out how to resolve this inconsistency.

Part 3 coming soon!

Building a home file server with Debian 8.2 (jessie): Part 1

I’ve been running my own home file server for many years now. I’ve used it for everything from storing old documents and photos to running a Minecraft server for my cousins. With online backup services like Dropbox it’s become less of a necessity but I still like having one around.

My current file server has been aging and is starting to sound a bit wheezy. It was originally built into an old desktop “Mid Tower” ATX sized case. So, time for something smaller and hopefully quieter.

The Build

Here is the build as spec’d out on PCPartPicker:

  • Case: Lian-Li PC-Q26B Mini ITX Tower Case
  • CPU: Intel Core i3-4170 3.7GHz Dual-Core Processor
  • Motherboard: ASRock H97M-ITX/AC Mini ITX LGA1150 Motherboard
  • Memory: Crucial Ballistix Sport 16GB (2 x 8GB) DDR3-1600 Memory
  • Storage: 2x Western Digital Caviar Blue 250GB 3.5″ 7200RPM Internal Hard Drive
  • Storage: 3x Western Digital Red 4TB 3.5″ 5900RPM Internal Hard Drive
  • Power Supply: SeaSonic X Series 400W 80+ Platinum Certified Fully-Modular Fanless ATX Power Supply

It could be done cheaper but this is a fun project for me so I splurged a little.

After the parts arrived and I’d put everything together it was time to install Debian.

The Installer

First thing was to build a new live USB installer. I grabbed the standard Debian 8.2 (jessie) iso from my nearest mirror (the OSU Open Source Lab). Then I popped a 4GB thumb drive into my Macbook and ran:

diskutil list
diskutil unmountDisk /dev/disk2
sudo dd if=~/Downloads/debian-live-8.2.0-amd64-standard.iso of=/dev/rdisk2 bs=1m


My old file server was running RAID 5 for the storage partition but the Operating System was running on a single disk that could fail at any time. If that had happened it would have been a huge hassle to reinstall and reconfigure everything. I wanted to avoid that possibility this time around by installing Debian to a RAID 1 (mirrored) array.

Installing Debian to a RAID 1 array can be done entirely from the built-in installer. I pretty much followed this guide from the Debian wiki to the letter:

I chose rootfs for my logical volume name. You can ignore the part about lilo at the end.

Note: You can skim the LVM section if you’d like and simply install Debian directly to your RAID volume.

The first boot

After the first successful boot I made sure to run dpkg-reconfigure grub-pc and install grub on both members of /dev/md0, /dev/sda and /dev/sdb, to ensure either drive would be bootable.

Then I went about with my usual configuration.

First I added my laptop’s public key to my user’s ~/.ssh/authorized_keys file so I could access the server remotely without bothering with passwords.

Then I modified the /etc/ssh/sshd_config to disable access for the root user and for password based authentication:

PermitRootLogin no
# ... snip
PasswordAuthentication no

Finally, I wanted to make sure I’d know if one of the members of the RAID array becomes degraded so I needed to make sure e-mail could be sent from the server. To do this I had to configure exim4 to send via Gmail’s SMTP gateway.

This seemed complicated at first glance but proved to be much simpler than it seemed. I basically followed this guide (again from the Debian wiki):

You can ignore the part about /etc/email-addresses.

Also, use the command service exim4 restart instead of invoking the rc.d command directly.

Where it asks for your Gmail password I suggest generating a new App Password specifically for your server.

You can send a test message by:

echo 'This is only a test' | mail -s 'Hello World!'

Since I was in a monitoring mood I also installed smartmontools to monitor the health of the drives. This includes a daemon that will notify you if any SMART errors are detected.

First, install apt-get install smartmontools. Then, edit etc/default/smartmontools and uncomment the line #start_smartd=yes. Finally, restart the service with service smartmontools restart.

The first problem

I wanted to make sure the system would boot in a degraded state if one of the drives failed. To test this, I shut down the system and removed one of the drives. Upon restarting, I was greeted with the following error:

Unable to find LVM volume vg1/rootfs
  Volume group "vg1" not found

… then dumped into the initramfs recovery console (BusyBox).

After a break and some intense Googling I discovered that mdadm was marking the array as inactive on boot instead of starting it in a degraded state as expected. Because the physical volume was not available LVM was throwing a misleading error.

To fix this problem you can run the following from the initramfs recovery console (BusyBox):

mdadm --run /dev/md0
vgchange -a y

Your system should now boot normally from a degraded state.

After booting, I used the command mdadm --manage /dev/md0 --re-add /dev/sdb1 to restore the removed drive to the array.

This issue appears to be a bug in Debian 8.x (jessie) that should be fixed in future versions:

Read part 2.

Getting started with the new Android build system

As many of you might be aware, the Android Development Tools team is working on a brand new build system. The new system has been in development for a while now, but is being officially announced at Google I/O 2013. The updated build system does away with Ant and moves to the Gradle build automation tool. You can read more about Gradle at The new Android build system is documented on the Android Developer Tools site at

Getting started with the new build system is relatively easy. To get started you’ll need to make sure you have both Maven and Gradle installed.

Install Homebrew

If you’re working on OS X you can make your life a whole lot easier by installing Homebrew. If you don’t already have it installed, you can install it by running the following command from your terminal:

$ ruby -e "$(curl -fsSL"

Install Maven

    $ brew install maven

Install Gradle

As of May, 2013, the new Android build system only supports Gradle versions 1.3/1.4. This means it won’t work with the latest version of Gradle. You’ll have to follow the instructions at to install a prior version of Gradle. Otherwise you could simply install the latest version using Homebrew.

    $ brew install gradle

You can verify you have the correct version of Gradle installed using the following command:

    $ gradle -v

You should see output that looks something like this:

    Gradle 1.3
    Gradle build time: Tuesday, November 20, 2012 11:37:38 AM UTC
    Groovy: 1.8.6
    Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
    Ivy: 2.2.0
    JVM: 1.6.0_45 (Apple Inc. 20.45-b01-451)
    OS: Mac OS X 10.8.3 x86_64

Add a build.gradle to your project

Add the following build.gradle file to the root of your Android project:

Build your project

You should now be able to build your project using the following command:

    $ gradle clean installDebug

Updating your app to support 7-inch tablets

Recently I’ve spent a lot of time thinking about how to optimize our app layouts for 7-inch tablets like the Nexus 7. It’s not an easy process, but a few tricks will make your life a whole lot easier.

As of today, the two most common screen resolutions in the 7-inch category are 1280x800 - WXGA and 1024x600 - WSVGA. Higher-end tablets like the Nexus 7 have a 1280x800 resolution and thus a higher pixel density. Lower-end tablets like the Samsung Galaxy Tab use a 1024x600 resolution and have a lower pixel density.

The Nexus 7 has a pixel density of around 213ppi and technically falls into the unique tvdpi density bucket, but for all intents and purposes you can consider it an hdpi device. Lower-end devices with a 1024x600 resolution have a pixel density of approximately 170ppi and will typically use mdpi assets. I don’t know of any 7-inch devices with an xhdpi pixel density, but I’m sure we’ll see some hit the market soon.

Regardless of the resolution, all 7-inch Android devices fall into the 600dp category. That is, they have a width of 600 density-independent pixels when in portrait orientation. We can use this width to provide alternative resources for these devices.

For starters, if you want to specify a custom layout for 7-inch devices you can simply add a new res/layout-sw600dp directory. Any layouts in this directory will be applied to devices that have a “smallest-width” of “600dp”.

If you don’t want to provide a completely different layout, but want to bump up the size of all your elements slightly you can use the res/values-sw600dp directory. Any resources provided here like dimens.xml or styles.xml will take precedence on devices like the Nexus 7. This way you can have a single layout file that references dimensions or styles that are dynamic based on the device size.

Finally, you might want to provide alternative drawable resources for 7-inch tablets. You can combine the sw600dp resource qualifier with a density qualifier to provide alternative drawables:

  • res/drawable-sw600dp-mdpi
  • res/drawable-sw600dp-hdpi
  • res/drawable-sw600dp-xhdpi

As you can see we’ve simply added the sw600dp qualifier to our typical drawable directories. These resources will be applied to devices of the correct screen density, but only if they are 7-inch tablets or larger.

All of these techniques are also applicable to targeting 10-inch tablets. Simply replace the 600dp width qualifier with 720dp in the case of 10-inch devices.

Further reading

Styling the Android Action Bar title using a custom typeface

Styling the Action Bar in Android can frequently seem difficult, if not impossible. It’s easy to do wrong and hard to do right. However, customizing the Action Bar title with a custom typeface is a surprisingly easy way to spruce up your app design.

There are several posts on Stack Overflow that recommend accomplishing this by leveraging the Action Bar’s custom view feature, or by getting a reference to the title TextView. These solutions are adequate but can lead to infuriating edge cases. We can do better.

You might have come across the TypefaceSpan class, which allows you to style a section of text in a TextView with a monospace or serif font. This is almost what we want to do, but we need to be able to provide our own Typeface instance.

Here’s what a custom TypefaceSpan might look like in use:

    SpannableString s = new SpannableString("My Title");
    s.setSpan(new TypefaceSpan(this, "MyTypeface.otf"), 0, s.length(),
    // Update the action bar title with the TypefaceSpan instance
    ActionBar actionBar = getActionBar();

Notice that we simply create a SpannableString with our desired Action Bar title. We then create a new instance of our custom TypefaceSpan providing it with our Activity context and the typeface name as arguments (so it can load the typeface from our application’s assets directory). The span is set on the entire length of the title (... 0, s.length(), ...). Finally, we pass in the Spannable.SPAN_EXCLUSIVE_EXCLUSIVE flag, which simply indicates that the span should be removed if all of the spanned text is deleted. Here’s what the result might look like:




But what does the custom TypefaceSpan implementation look like? Well, it’s surprisingly simple. I’ve created an example you can use in your own apps. You can get it at Simply copy this class into your application and use it like I’ve indicated above. You can even subclass the custom TypefaceSpan to add additional styles like colors or text shadows.

Fonts Shown

Android TextView with custom Typeface support

Currently Android does not have a native View class that supports defining a custom Typeface in your layout’s XML. After inflating your layout you can obtain a reference to the TextView and call the setTypeface( method from your Java code, but this results in unnecessary duplication of logic and violates the DRY principle. Continue reading

Appcelerator Titanium KrollDict fails to sanitize JSONObject.NULL values

If you’re developing an Appcelerator Titanium module for Android it’s possible that you’ll run into this exception (see bottom of post for full exception trace):

!!! Unable to convert unknown Java object class 'org.json.JSONObject$1' to Js value !!!

It took me a long time to track down the cause of this error, but essentially the issue is in the JNI layer, which passes native Java objects to the Javascript layer does not know how to handle a JSONObject.NULL value. The Titanium wrapper object KrollDict attempts to convert all non-native Java objects into native ones. JSONObject becomes a simple Map, JSONArray becomes an ArrayList and so on. However, the constructor fails to account for instances of the JSONObject.NULL object, which is not a simple primitive.

An easy work around would be to ensure the JSON objects that you’re passing around never have any true JSON null values in them. You can replace them with empty strings, or simply remove the key from the object altogether. This is ultimately the fix we went with. However, a simple two-line patch should solve this issue in the core Titanium code:

From 57868ea5b822468563d4a1be2adb901cce383f11 Mon Sep 17 00:00:00 2001
From: Tristan Waddington <>
Date: Mon, 4 Jun 2012 14:24:15 -0700
Subject: [PATCH] Update the 'fromJSON' method of 'KrollDict' to map the
 'JSONObject.NULL' Object to a real Java null
 android/titanium/src/java/org/appcelerator/kroll/ |    2 ++
 1 file changed, 2 insertions(+)
diff --git a/android/titanium/src/java/org/appcelerator/kroll/ b/android/titanium/src/java/org/appcelerator/kroll/
index da29217..96017d6 100644
--- a/android/titanium/src/java/org/appcelerator/kroll/
+++ b/android/titanium/src/java/org/appcelerator/kroll/
@@ -56,6 +56,8 @@ public static Object fromJSON(Object value) {
 					values[i] = fromJSON(array.get(i));
 				return values;
+			} else if (value == JSONObject.NULL) {
+				return null;
 		} catch (JSONException e) {
 			Log.e(TAG, "Error parsing JSON", e);

I submitted a pull request to the titanium_mobile repository on GitHub, but all contributors are required to sign a Contributor License Agreement (CLA). Not a big deal, but I don’t expect to ever submit another patch to this project, so I’m not inclined to spend a day getting their dev environment bootstrapped and sign my life away for a two-line bug fix (yes, I wrote a passive-aggressive blog post instead).

Unfortunately, they don’t even seem interested in accepting the patch as a simple bug report so someone else can fix it:

If you’re trying to build a platform that’s meant to be developer focused, willful disinterest is not the best response. If you’re curious, here’s the raw patch file and the full exception: