Bootable Fedora USB stick with encrypted home partition – part 1

In this tutorial we will repartition a USB stick and install Fedora on it allowing it to be used:

  • As encrypted storage with any modern Linux system
  • As a bootable USB stick running Fedora and using an encrypted home partition
  • To copy files to/from other computers, including those running non-Linux operating systems (this bit uses an unencrypted partition).

The basic idea is to split the disc into two partitions, Boot and Vault.

Boot is a FAT partition that interoperates well with non-Linux operating systems. The FAT partition will also contain, as files, the bootloader, read only compressed file system image and “overlay” image that allows us to amend the main filesystem. It is the compression that makes this scheme attractive. A very rich development workstation (including eclipse and lots of header packages) weighs in at less than 2GB. The other big advantage of basing things on the live images is that all the logic to stop temporary (and log) files writing out to the USB media is ready and working out of the box. This keeps down the wear on the media.

Note: The read-only compressed file system comes from the Fedora “Live” media. Thus the images easily available are the live CD and the live DVD published by the Fedora project. However it is possible to use the Fedora tools to custom roll your own live media.

The Vault is an encrypted home partition where the user files (including audio/video streams) can be stored. It is also automounted, subject to password, on any modern Linux system allowing it to be used for encrypted file exchange.

Recommended partition sizes

This is just a rough guide since its up to you to decide what you’ll be using the bootable stick for.

For a 4GB USB stick a 3GB FAT partition leaving a 1GB encrypted partition would be fairly flexible and allow big files to be transferred to a non-Linux operating system. Consider using a CD sized live image and a relatively small overlay partition (300MB or so).

For a 8GB USB stick, either a 4GB/4GB or a 5GB/3GB division would make sense. With a 5GB/3GB split then the DVD sized live image is possible together with a generous home area and the capacity to transfer large files.

For 16GB media I like to have a very big encrypted area so I can keep lots of audio/video material on the encrypted partition. For me a 6GB/10GB split gives me exactly what I want. A 2GB live image together with a generous overlay partition (1GB) so I can easilt install extra software whilst travelling if I need to.

I seldom use non-Linux operating systems these days so these recommendations assume I can use the encrypted partition for file transfer. If the primary thing you use the USB stick for is file transfer to non-Linux operating systems then perhaps you want to just pick a relatively small size for the encrypted partition (say 1GB) and give all the rest to the boot partition.

Putting it into practice

After inserting the USB media it is likely to be auto-mounted by the OS. Therefore the first thing we need to do it identify the media and unmount it. I recommend using the command line for this. Many GUI “eject” commands do more than just unmount the file system, they also do a USB shutdown that makes it impossible to use the media until you unplug and replug it (at which point it auto mounts again). Here we use mount to list the mounted devices and hunt for the device mounted on either /media or /run/media/<username>/ and then use the device name on the left to do the unmount. Remember the device name (below it is /dev/sdb1) since we’ll need that later.

[root@lobster ~]# mount
 proc on /proc type proc (rw,relatime)
 sysfs on /sys type sysfs (rw,relatime)
 /dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
 /dev/sdb1 on /run/media/drt/9A63-9772 type vfat
 [root@lobster ~]# umount /dev/sdb1

Now we need to repartition the USB media to create seperate Boot and Vault partitions. THIS WILL ERASE EVERYTHING ON THE DISC. Here we use parted and the argument is the device name from above (/dev/sdb1) with the numeric part and the end shaved off (/dev/sdb).

Note: The following examples are taken from my own system where I’m setting up a 16GB USB stick with a 6GB/10GB split.

[root@lobster ~]# parted /dev/sdb
 GNU Parted 3.0
 Using /dev/sdb
 Welcome to GNU Parted! Type 'help' to view a list of commands.
 (parted) p
 Model: SanDisk Cruzer Fit (scsi)
 Disk /dev/sdb: 16.0GB
 Sector size (logical/physical): 512B/512B
 Partition Table: msdos
 Disk Flags:
Number Start End Size Type File system Flags
 1 16.4kB 16.0GB 16.0GB primary fat32 lba

Remove the original partition:

(parted) rm 1

Make a 6GB FAT partition to act as the boot partition, a 10GB encrypted partition and double check things by printing the partition table:

 (parted) mkpart primary fat32 16.4kB 6.0GB
 Warning: The resulting partition is not properly aligned for best performance.
 Ignore/Cancel? i
 (parted) mkpart primary ext2 6.0GB 16GB
 (parted) print
 Model: SanDisk Cruzer Fit (scsi)
 Disk /dev/sdb: 16.0GB
 Sector size (logical/physical): 512B/512B
 Partition Table: msdos
 Disk Flags:
Number Start End Size Type File system Flags
 1 16.4kB 6000MB 6000MB primary fat32 lba
 2 6001MB 16.0GB 10.0GB primary
(parted) quit
 Information: You may need to update /etc/fstab.

Now is a good time to unplug the media, just to make sure that the kernel adopts the new partition table. This is paranoid but, hey, unplugging a USB stick isn’t so hard now is it?

Having done that, the automounter might end up decided to mount the old filesystem (not caring that half of it is now missing). However because the file system has changed size we must make a new one in order to be save.

Firstly we format the boot partition:

[root@lobster ~]# umount /dev/sdb1
 [root@lobster ~]# mkfs.vfat -F 32 -n LIVE /dev/sdb1
 mkfs.vfat 3.0.12 (29 Oct 2011)
 [root@lobster ~]#

Having done that we now need to create an encrypted ext4 partition ready to use as the home area (and for Linux to Linux file transfers):

[root@lobster ~]# cryptsetup --verify-passphrase luksFormat /dev/sdb2
 This will overwrite data on /dev/sdb2 irrevocably.
Are you sure? (Type uppercase yes): YES
 Enter LUKS passphrase:
 Verify passphrase:
 [root@lobster ~]# cryptsetup luksOpen /dev/sdb2 tmp
 Enter passphrase for /dev/sdb2:
 [root@lobster ~]# mkfs.ext4 -L Vault -m 0 /dev/mapper/tmp
 mke2fs 1.42.3 (14-May-2012)
 Filesystem label=Vault
 OS type: Linux
 Block size=4096 (log=2)
 Fragment size=4096 (log=2)
 Stride=0 blocks, Stripe width=0 blocks
 610800 inodes, 2442752 blocks
 0 blocks (0.00%) reserved for the super user
 First data block=0
 Maximum filesystem blocks=2503999488
 75 block groups
 32768 blocks per group, 32768 fragments per group
 8144 inodes per group
 Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
 Writing inode tables: done
 Creating journal (32768 blocks): done
 Writing superblocks and filesystem accounting information: done
[root@lobster ~]# cryptsetup luksClose tmp
[root@lobster ~]#

Again this is paranoia but just to make sure everything writes out before we unplug I like to run a:

[root@lobster ~]# sync

That’s it. The USB stick is ready. You can confirm this by hot-plugging one last time and you should be prompted to enter your password by the auto mounter.

We’re now half way there. The disk is all ready to run liveusb-creator to install the bootable operating system. After that there’s one last trick to get the live operating system to mount the encrypted home partition automatically and we’re all set.

I’ll tell you about all that in another post!


tintdrum – tintamp’s junior stablemate

For some time now I’ve been playing with constructing my own digital modeller.

By and large I’ve deliberately kept the scope of the project to be a make a practice tool (rather than a studio effect) in order to try an keep things achievable. The ultimate aim is to make a device that you use like an amPlug (or iRig for iPhone) to practice with. More exactly it is a battery operated “thing” that allows you practice without any wires except those joining the guitar to your ears.

I’m working in phases of very limited scope so that I can lose interest in the project whilst still having achieved something and there’s still a long way to go before I can call it a modeller. Nevertheless since Christmas I’ve been able to move from playing with software in the PC to playing with something real.

STM32F4-Discovery running an early version of tintdrum
The above is my recently acquired STM32F4-Discovery board running tintdrum, a fixed function groove machine designed to use like a metronome but with a stronger groove. The idea is that this type of drum machine is a vital component of a digital practice tool so tintamp will definitely have to have one when its finished. However it is actually useful enough to be a separate thing in its own right. Something I can put in a box and call “done”

The board above is running my own drum machine software. You can tell can’t you? Until last week all it was able to do was plug in and it started playing drums via the headphone socket at the bottom… it played a really basic 4/4, kick, snare, kick, snare beat (plus hi-hat)… at exactly 100 beats per minutes… and that’s it.

This week however I’ve been able to extend it to flash an LED on the beat (a vital feature in a practice tool) and also been able to rig up a tap tempo button. This means its starting to feel real. That said I still need to implement controls to change the groove and volume. I’d also like to extend the drum machine code to include humanization to stop is sounding quite so start.

Nevertheless the journey from PC to real hardware has begun. Bon voyage.


The Egmond Project – Update #1

The restoration/reassembly of this lovely old guitar is coming along nicely. I spent a good half hour the other day working methodically though the box of screws, pickups, electrics and hardware until I was sure I know what each screw was for. It turned out to be quite complex jigsaw, made a lot easier when I realized that the screws for the machine heads didn’t actually match (which is why I couldn’t find 16 identical little screws).

I also spent a fair bit of time with the bridge. As you can see on the photo below I needed to sand it down a bit to match the curvature of the guitar.

With the bridge feet set up to avoid damaging the top of the guitar I had all the bits ready to string it up and see what other adjustments might be needed. When I first strung it up I realized I would have to cut slots into the saddle to get the string spacing right (not quite sure how I overlooked that). So finally yesterday I was able to bring the guitar into a playable condition.

First impressions are pretty good. Its fun to play and sounds much more like a double bass than my electric basses. I understand the tapewound strings contribute to this.

At this stage I’m not quite ready to start the rewiring as there remain a few drawbacks. Some of this is just finishing what I started. The truss rode needs a little more tuning now the strings are at tension and I need to shave several mil of the bridge. I need to shave of a little more from the feet, a little from the saddle and then take the rest from the middle section.

The other issue is that the strings don’t quite run parallel to the fretboard.

Most of what you see in the picture above is actually caused by the bridge being incorrectly sited. However there is some play in the neck joint meaning I can pull the neck and bring the strings completely straight. The neck joint has odd single bolt plus one light duty woodscrew construction which I’ve not seen before and I haven’t yet decided whether or not to try and wedge it. I’m going to leave that decision until the bridge is at the right height.

Nevertheless I pleased with the progress so far. It’s bags of fun to play acoustically… looking forward to starting on the electrics.


The Egmond Project – Introduction

After my uncle’s sad, and rather too early, passing away I recently inherited a guitar project. Basically the guitar said something to me from the first photo I saw of it, perhaps because semi-acoustic basses really aren’t very common. It went from a passing whim to a potential project when my dad unearthed a cigar box full of all the guitar hardware that changed the body and neck from being firewood into being a viable project.

So now there is something potentially wonderful in my garage. It just needs a little time spent on it. Everything I’ve got is shown in the picture below, both main bits of guitar together with a cigar case containing all the missing hardware, right down to the strings.

Looking more closely at the box of bits is interesting.

In there are all the bits and bobs that need to be screwed, nailed, wedged and soldered together to bring the guitar back to life: pickups (one of which needs repairing), tail piece, machine heads, circuit components, switches. So far I’ve not thought of anything missing.

I have spent some time trying to work out why the guitar was taken to pieces. Was there something wrong with it? Certainly the bridge overs some clue that I might end up having to do something about the neck.

Those massive grooves really shouldn’t be there. It’s like they were cut to account for a neck that was practically falling off. However I’ve looked very carefully at the joint and I don’t see the problem. When properly tightened it sits at what looks like the right angle and doesn’t want to move much.  I guess I won’t find out until I buy a new bridge and try and bring the strings to tension.

For now I have concluded the guitar was in so many bits because my uncle was planning to refinish it. When someone takes so much of the hardware off it can only really be to get down to the wood! For me that’s terrific news, because it suggests it was playable and will fit back together again!

So there it is… a project. I’m looking forward to it.


A guitar preamp using biquads and a waveshaper

Let’s start this with a confession. This post is nothing more than a summary of an idea I picked up from an eight year old paper. I didn’t even go to the trouble of finding the paper myself but instead found it cited in the source code to guitarix. For that reason this should be quite a short post.

Firstly remember that at the moment tintamp is not really a modeller. It will be, but its not there yet. For now its just a fixed function digital signal processing chain that is “good enough” to allow each stage in the chain to be prototyped and developed further. On the plus side being fixed function makes things very easy to describe.

So the first revision attempt at a tintamp preamp consists of three similarly configured amplification stages based on an approximation of a class A 12AX7 amplifier. The heart of the tube stage is a waveshaper based upon the transfer function of a 12AX7. This is surrounded by three biquad filters that model the effects of the capcitors in the circuit being modelled.

All told it looks something like this (click to enlarge):

Please forgive the poor layout above. I rushing to press “Publish” just a little and I’m not very expert at graphviz just yet. Additionally if you want to see the ideas expressed more lucidly the Virtual Air Guitar folks have already done a very good job, take a look at their paper!


Cabinet simulation using biquad filters

My last post introduced tintamp and described the target hardware for the project. I’ll now fill that out a little bit with a description of one the building blocks from which I plan to construct the initial signal chain. For now the idea is to fairly simplistic DSP techniques from which I can develop and end-to-end signal chain, including an amplifier, tonestack and cabinet simulation. Once there is a complete signal chain then the hardware components needed to connect the delicate guitar signal to the target hardware can be tested. Likewise when more sophisticated software is written we have a benchmark to compare it to. There’s no point in sophistication just for the sake of it.

Ultimately I think only two blocks are needed to build a complete chain, a biquad filter and a waveshaper. On its own the biquad is sufficient to construct simple tonestacks and cabinet simulations while the waveshaper allows us to trivially model non-linear relationships between input and output voltages. A waveshaper is not insufficient to model a real valve’s behaviour for AC signals although it can be combined with a biquad filter that feeds back from its input to its output to add at least some modelling of dynamic behaviour.

So on that basis I coded up these basic building blocks (including a test suite) and set to work. I should at this point express my gratitude to Robert Bristow-Johnson for his Cookbook formulae for audio EQ biquad filter coefficients, all those filters compressed into such an easy to read document saved me an awful lot of work.

So, lets get back on topic and introduce a basic cabinet filter using only biquad filters. My starting point was a trace of the frequency response of the Condor cabsim from runoffgroove. I had no real reason to pick this cabinet response over any other but I happened to stumble across their graph first.

Based on the above graph picked out five biquad filters:

  • A -16dB partial notch filter at 400Hz to get the deep notch
  • A 6dB high boosting shelf filter at 400Hz to get the roller coaster effect
  • A single high pass filter at 60Hz
  • Two low pass filters each at 4000Hz

As of now I haven’t yet graphed the response of this cabinet simulation (although I have listened to it) and currently all the Q values are untuned and set to 0.7 . Tuning these will have a big effect on the mid range since in particular they change the shape of the curve around the notch.

Having got this far I won’t be using the runoffgroove graph as a reference any more. All further tuning will be by ear and, eventually, I’ll create other speaker models using graphs from real speakers. That said it will be while before I start improving the cabsim. At the moment one working cabsim is sufficient to get the rest of the signal chain in place so the focus has to be somewhere else for a while.


The Integer Amplifier

This post is an introduction to tintamp, the integer amplifier. The goal of the tintamp project is to build a free software guitar modeller for low resource computers such as digital music players or modern high performance microcontrollers. The focus on low resource devices defines much of the character of the project from its choice of implementation language to the relatively simplistic, and therefore CPU-friendly, DSP engine. These devices also mandate unusual features such as the no malloc() mode and the use of purely integer arithmetic operations (a.k.a. fixed point) from which the project gets its name.

To provide even more focus and to make it easier to ‘complete’ the project I have picked two platforms to be reference devices. These are the first devices I expect to port tintamp to. Both devices require a little hardware hacking as well as the tintamp software so there will be a substantial element of learning as I go.

Target 1 – Sansa Clip Zip

From a hardware perspective this is a simple mini-project to convert an off-the-shelf digital music player into a headphone practice amplifier. The digital music player in question is the Sanza Clip Zip made by Sandisk.

From the point of view of this project it has good many things going for it. In particular it has audio inputs that can be tapped into by de-soldering either the built in microphone or FM radio chip. It also has a colour display, a 250MHz ARM9 CPU and,crucially, a mature Rockbox port. The Rockbox port means I can concentrate on the signal processing code without having to work very hard getting the rest of the hardware to work. Even better, these devices are really cheap, so much so that I’m seriously contemplating buying a second one to keep and use for its original purpose.

The only problem with the device is the noise floor. The microphone is probably too noisy too use at all and even with the FM radio’s line in things are only 12dB better. Still, when finished this device will be a headphone practice amp so there’s little need for studio quality effects. It just has to be playable.

The most significant technical limitation of this platform is the absence of FPU making this device is the main motivation for (optionally) using fixed point arithmetic.

Target 2 – STM32F4-Discovery

This time around the mini project it to take a demo board based around a very powerful modern micro controller, combine it with a good quality codec chip and build a digital effects pedal.

The discovery board from STMicroelectronics[1] brings most of the pins of ST’s STM32F4 controller and brings them out to header connectors. This includes the I2S (digital audio) in/out needed to interface it to a codec chip. Alternatively the board has built-in audio output together with a USB on-the-go controller that allows a USB audio device to be connected up.

The STM32F4 is based around a 168MHz ARM Cortex M4 which, although restricted to only the Thumb2 instruction set, does have a floating point unit. Here the big restriction is that being a micro controller there is only 192k of RAM. This will have to be very carefully managed. On the other hand what memory there is should be very fast compared to the CPU so no performance will be wasted with cache misses.

In the interests of full disclosure I should probably mention that I work for STMicroelectronics. However I don’t work in the microcontroller group and I didn’t pick the Discovery board because it was made by ST. I picked it because the board is fast, cheap and has I2S pins. Likewise, however much I ask my manager, I don’t get the board for free; I have to pay for it like anyone else. While disclaiming things I should also add that nothing in this blog comes from my employer. I’m not authorized to speak on their behalf and all opinions expressed here are purely my own.


De-gunking a thirteen year old Coleman stove

We finally decided enough was enough with the behaviour of our aged but much loved/abused Coleman 424 stove. It was kill or cure time! To explain, Coleman petrol stoves really are brilliant. However if you run them for too many years on neglect and unleaded they start to clog up. In the case of our Coleman it has reached the stage where it eats generators for breakfast. They last maybe three days camping before they are as clogged and gummed up as the one they replaced resulting in a anaemic flame with boil times of around twenty minutes, if ever.

However we want to give it a fighting chance so we’ve given it a new generator and given the tank the cleaning it should have had eight years ago.

After examining it we could hear what sounded like sand in the fuel tank. It has certainly never had sand put in it but it has been laid idle for long stretches of time with a full tank of unleaded. Apparently this lines the tank with varnish which then flakes off and clogs the generator.

The Coleman website suggests a long soak in meths for this problem so we duely filled the tank and left it for twenty four hours disturbed only by the odd shake. Then we siphoned the tank, poured the meths back into the bottle and were left with this.


Noting that the jar in the picture above is upside down should give you some idea of just how sticky the sludge in the tank was. Even shaking the jar has little effect. No wonder the generator kept blocking up! I was so pleased with my new sludge I immediately refilled the tank with meths and siphoned it out twice more. After doing this there was nothing to be heard in the bottom of the tank.

We’ve all recently discovered a fuel called Aspen 4T. Its designed for strimmers and other hand held petrol tools. It’s selling point is a much cleaner burn than regular road fuel. It certainly smells better when you run the cooker! Aspen is about twice the price of unleaded or to put it another way between half and a quarter of the price of Coleman fluid. We plan to make it our fuel of choice for our Coleman kit.

So did all this bustle, activity and alternative fuel actually work? We don’t really know yet. We’ll let you know when we get back from our next camping trip.