As described in the Kernel doc, https://www.kernel.org/doc/Documentation/x86/early-microcode.txt, it is possible to combine 2 CPIO archives together into a single initramfs, simply by cat’ing them (see link above for details on the how/why).
But I ran into an issue while extracting it : only 1 of the archive would be extracted by the cpio command. How to extract the other one ?

Let’s do it manually.

How To

First, the issue :

Trying to extract Fedora 21’s initramfs (isolinux/initrd0.img), there was clearly something wrong :

[cedric@laptop f21]$ file initrd0.img
initrd0.img: ASCII cpio archive (SVR4 with no CRC)
[cedric@laptop f21]$ mkdir initrd0
[cedric@laptop f21]$ cd initrd0/
[cedric@laptop initrd0]$ cpio -idv < ../initrd0.img
1251 blocks
[cedric@laptop initrd0]$ du -sh .
648K    .
[cedric@laptop initrd0]$ du -sh ../initrd0.img
37M     ../initrd0.img

There’s clearly data missing here :
1) that initramfs would not be sufficient to boot (there’s no init!)
2) we have about 36.5M of data missing!

How to get around

After a quick search, I didn’t find help to retrieve the remaining data, so I decided to go manually.

From the output, we know that the first archive is 648K extracted, and the archive is 1251 blocks (no compression was used for this archive). Thus we can guess that the block size is 512 bytes (1251 x 512 is close to 648K).
Let’s see what’s after that.

Note : 1251 x 512 = 640,512 = 0x9C600

[cedric@laptop f21]$ hexdump -C initrd0.img | less
0009c430  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0009c600  1f 8b 08 00 09 77 7f 54  02 03 ec 59 09 54 13 57  |.....w.T...Y.T.W|
0009c610  f7 7f 6f 08 18 10 34 20  2a 82 d8 80 04 41 10 92  |..o...4 *....A..|

2 good news there :
1) offset 0x9c600 looks like the begining of something
2) “1f 8b” at offset 0 is the magic type for “gzip compressed data” (37\213 in octal) :

[cedric@laptop initrd0]$ grep "gzip compressed data" /usr/share/misc/magic
0       string          37\213        gzip compressed data

So now we just need to extract that gzip data out, and that will probably contain our actual initramfs :

[cedric@laptop f21]$ mkdir initrd1
[cedric@laptop f21]$ cd initrd1
[cedric@laptop initrd1]$ dd if=../initrd0.img of=initrd1.img bs=1b skip=1251
72966+1 records in
72966+1 records out
37359079 bytes (37 MB) copied, 0.151864 s, 246 MB/s
[cedric@laptop initrd1]$ file initrd1.img
initrd1.img: gzip compressed data, last modified: Wed Dec  3 21:48:09 2014, max compression, from Unix
[cedric@laptop initrd1]$ zcat initrd1.img | cpio -idv
138243 blocks
[cedric@laptop initrd1]$ du -sh .
109M    .

… Now that sounds more right : we have a real initramfs, and the sizes are better.


How would you feel in your external hard drive disappeared. Think about it : all data available to anyone. Encrypt it!
Now modern Linux distribution makes it so easy you do not have any excuses.
Note : Unfortunately, the method is probably not portable (I actually never tried)

How To

Insert the drive and get its /dev file. In the example below, it is going to be /dev/sdb2. Currently, there is nothing on this partition.

  1. Create the LUKS header, with a password
    # cryptsetup luksFormat /dev/sdb2

    This will overwrite data on /dev/sdb2 irrevocably.

    Are you sure? (Type uppercase yes): YES
    Enter LUKS passphrase:
    Verify passphrase:

  2. Open the device, I am calling the decrypted block device external (/dev/mapper/external), but it can be any name
    # cryptsetup luksOpen /dev/sdb2 external
    Enter passphrase for /dev/sdb2:
  3. Put some filesystem on that (ext4 in my case)
    # mkfs.ext4 /dev/mapper/external
    mke2fs 1.41.14 (22-Dec-2010)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    10870784 inodes, 43452678 blocks
    2172633 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=4294967296
    1327 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

    Writing inode tables: done
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done

    This filesystem will be automatically checked every 20 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.

  4. Close the connection, for a clean unplug
    # cryptsetup luksClose  /dev/mapper/external
  5. Then unplug the device. Replug it, and magically, a password will be asked in order to mouint it! (works on my Fedora15 + KDE)

Quick note that may help some persons :

Lately, I have installed Fedora 15, with KDE as default Desktop Manager, of course. Weirdly, all the GTK applications (Firefox, Gpodder, Rhythmbox, etc.) were really ugly… So I checked what was going wrong, and below is the result of my study.

By the description of the situation, something was obviously wrong with the GTK rendering in my KDE environment.

GTK, like Qt, is going to load up a theme, at application start-up. In order to bring a “KDE” feeling into GTK apps (and thus keeping homogeneity in a KDE environment), there are some Qt-like designs. 2 of them are qtcurve-gtk2 and oxygen-gtk.

The choice of the theme is done via ~/.gtkrc-2.0-kde4. What probably happened is that, in previous Fedora versions, the default was probably oxygen-gtk, and it now defaults to qtcurve-gtk2. But, while installing Fedora 15, I kept my home folder. My ~/.gtkrc-2.0-kde4 was defaulting to the Oxygen theme, but the package was not installed. Therefore, there was no theme, and it was ugly. After making the required changes, everything is much better 🙂

Therefore, the following steps restored a normal behaviour :

  1. install qtcurve-gtk2
  2. Verify that the ~/.gtkrc-2.0-kde4 has the following content :

Of course, it is also possible to use oxygen theme if you set the theme to “oxygen-gtk”. For further info, see the example from the oxygen-gtk documentation (/usr/share/doc/oxygen-gtk-1.0.5/README)

Notes :

  1. I have no idea which one is better, and additional theme may be available too.
  2. Until yesterday, I had no idea how theme worked, I am a complete newb’ in the subject. I apologize for any thing incorrect in the description above.
  3. That caught my interest, I ll definitely look deeper in the subject at a later point.


As far as I know, there is no GUI tool to manage encryption keys. One may think that it is static. Actually no, if you go by the low level command line tool, you can manage up to 8 keys.
For example, you can :

  • Have several strong passwords if you share your machine (1 per user)
  • Delete a key that has been compromised, etc.

The tool

crypsetup uses the Linux Unified Key Setup (LUKS) format. Wikipedia will provide a short LUKS introduction : http://en.wikipedia.org/wiki/LUKS
The man page, and the –help option will provide all the options you may need : confirm that a block is encrypted, add / remove keys, or dump / backup the data. Is very straightforward, and can be done online (no need to unmount the volume).

Adding a new key : luksAddKey

Example :
[root@vm14 ~]# cryptsetup isLuks /dev/vda2
[root@vm14 ~]# echo $?
0 [to confirm that vda2 is the LUKS device]
[root@vm14 ~]# cryptsetup luksAddKey /dev/vda2
Enter any passphrase: [enter any existing key first, to authenticate]
Enter new passphrase for key slot:
Verify passphrase:

… And this is it. Now there is another key that can decrypt the block device. You can use any existing passphrase to decrypt. You can of course delete passphrase as well.


Several years ago, my neighbour’s laptop got stolen. More than the monetary loss, he was affected by his private data going in the wild. Laptops can contain password, bank details and all other sorts of private data.

Since then, I always encrypted my personal data. You probably do the same, unless you are the U.K.  government or you want to tell us a Defcon story.

Software encryption solutions

All major Linux distributions should offer encryption from installation.
On Fedora, cryptsetup is being used. It’s a device-mapper plugin and therefore works on the block device layer (it takes a block device to store speudo-random data and presents another block device with readable data).

What to encrypt

Now comes a crucial question : what needs to be encrypted ?
One can think that encrypting /home is safe enough, while keeping read/write performance for the rest of the drives. I do prefer encrypting the whole tree (except from /boot, required for getting the kernel & initramfs).
Think about it : /root, /etc, /tmp, /var, the swap, may also contain sensitive data (passwords, private keys, pictures, etc.). To my mind, performance is secondary, and a patch adds multi-CPU support in kernel 2.6.38.
Therefore, I encrypt the full physical volume (the sda2 partition for example).

To come next

Introduction to LUKS. managing encryption keys

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can alway preview any post or edit you before you share it to the world.