Monthly Archives: October 2012

Booting Linux on a 3TB disk with grub2

I recently purchased a 3TB disk for my home server.
All disks of size 2TB and above cannot be partitioned using the standard fdisk tool. They require a GPT partition table.
First of all install parted and gnu-fdisk (an fdisk replacement based on libparted):

apt-get install parted gnu-fdisk

Assuming the 3TB disk is sda, run:

parted /dev/sda
mklabel gpt

Skip over to tl;dr if you are not interested in the details:

When using a GPT partition table, grub2 requires a small dedicated partition at the beginning of the disk. It will use the first 2 MB of this partition to store core.img.
This is explained with a cryptic statement in the manual of grub2:

GRUB2 in BIOS-GPT configuration requires a BIOS Boot Partition to embed its core.img in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table).
For a BIOS-GPT configuration, create a 2 MiB partition using cgdisk or GNU Parted with no filesystem. The location of the partition in the partition table does not matter but it should be within the first 2 TiB region of the disk. It is advisable to put it somewhere in the beginning of the disk before the /boot partition. Set the partition type to “EF02” in cgdisk or set bios_grub on in GNU Parted.

Create a small partition (a BIOS Boot Partition) at the beginning of the disk and don’t format it. You can use:

unit s
mkpart biosboot 8192 16383
set 1 bios_grub on

There is a very important reason for choosing 16383 as the end of the BIOS Boot Partition.
The next partition will start at sector 16384 and 16384 is a multiple of 4096.

Why is it important to choose a multiple of 8 as the beginning sector of the partition?
Newer hard drives utilize a 4KB sector internally, but they announce a sector size of 512 bytes to the operating system.
It’s very important therefore to make every partition start at a multiple of 4096. This way the 512 bytes block used by the operating system will always be aligned to the 4KB block actually used by disk.
If you fail to do so, whenever the operating disk will need to read 4x 512 byte blocks, it’ll actually read 3x 4KB blocks, thus transferring 3 times more data than it actually needed.
If the 512 byte blocks are aligned to the 4KB blocks, it’d have transferred just those 4KB.


Alpine x305s vs iTunes

I recently purchased a new headunit for my car audio entertainment. The choice fell on an Alpine x305s model.
It belongs to the “media receiver” category: it can play music files from USB drives and iPods, but not CDs. It has no moving mechanic parts and therefore it’s less likely to break with intense use.

I mostly use it with a 32GB Sandisk USB Cruzer blade drive formatted as FAT32.

It works just fine and browsing the directories is really fast, even when loading thousands of files on the USB drive (the Kendwood headunit that I bought back in 2006 was much slower).

The headunit can read both MP3 and M4A/MP4/AAC-LC files. I copied my whole iTunes Library on the USB drive and tried to play it on the Alpine X305s. Unfortunately for many files I got the infamous “Unsupported file format” error.
I decided to examine these files to find out what they have in common and discover a possible common cause for the problem. It turned out that all these files had an encoding bitrate greater than 320Kbps. I searched the headunit manual and indeed the max supported bitrate for M4A files is 320Kbps.

Apparently at least half of the albums that you can buy on iTunes have a bitrate greater than 320Kbps.

If you are not tech-savvy you might just want to convert these files to MP3 using iTunes and be done with it.

If you are a true audiophile and would like to keep the files in MP4/M4A format then keep on reading.
I put together a simple bash script that you can use on MacOSX/Linux/BSD to find and convert m4a files with a bitrate greater than 320Kbps to 320Kbps.
I assume that you have ffmpeg installed on your machine. It’s available in macports, apt, yum.

TEMPFILE=”$(mktemp /tmp/temp-XXXXXXX).m4a”

if ! [ -d “$BASEDIR” ]; then
echo Syntax: $0 /path
exit 1


for i in $(find $BASEDIR -size +5M -type f -name ‘*.m4a’);do
IFS=” ”
BITRATE=$(ffmpeg -i “$i” 2>&1|grep Duration|grep bitrate|cut -d ‘ ‘ -f 8)
echo $i has bitrate $BITRATE
if [ “$BITRATE” -gt “320” ]; then
ffmpeg -v 5 -y -i “$i” -acodec libfaac -ac 2 -ab 320k \
-map_metadata 0 $TEMPFILE
mv $TEMPFILE “$i”

I recommend working on a copy of your iTunes library and not the original files.
Depending on your installed version of ffmpeg, you might need to adjust the BITRATE= line to extract the value of the bitrate from “ffmpeg -i file.m4a” output.

After running the script against the m4a files on my USB thumb drive, I was able to play all the files on my x305s!