successful attempt with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010. i changed a few of the settings below during my install to use ext4 on the boot and / partitions. i also adjusted my partition size to only encrypt my aptosid LVM partition for / and swap, as i want to chainload other systems on my other partitions. this successful attempt i let the bootloader write to the mbr (default choice) making the grub of aptosid the 1st choice during system start up.

*failed attempts when chainloading and the "partition" option is selected for the bootloader mbr option section of the installer.

successful install, aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde 64bit. chainloading with multiple hd's and choosing the correct hd in the mbr option(sda,sdb,sdc, or sdd depending on how many you have) This choice does not write to the main mbr unless you are installing on the hd where the main mbr is,but you can change bios boot order to boot from the installed hd.

Securing your data is not only relevant for laptop users, but should be the default for every installation (my opinion). Everbody has some sensible data on his harddisk, may it be passwords, confidential documents, pictures, emails, downloaded copyrighted stuff, whatever. If your computer gets stolen, or if you get busted by the police (why should you?), it would be all open to the offender. That's what we are trying to prevent here, by encrypting just about everything on your harddisk, so that nobody without the passphrase can get a clue, what's on it. This method even ensures, that you can savely hibernate your computer, because the swap-partition is an encrypted volume as well.

The Debian installer (which is also used by Ubuntu & Co) already has a nice option to perform an installation with full harddisk encryption, which means just a small unencrypted /boot partition, and everything else on an encrypted LUKS partition. Unfortunately aptosid is not using the Debian installer, and since it's a LiveCD?, some manual work is required to get to the same result.

This article is about installing aptosid onto an empty harddisk, so be sure, that there is no data on it, that you still need, because it will get DELETED! DO NOT FOLLOW THESE INSTRUCTIONS, IF YOU HAVE A MULTIBOOT ENVIRONMENT, OR ANYTHING ELSE ON YOUR HARDDISK, THAT MATTERS TO YOU!

If you want to chainload other operating systems this method can also be used to encrypt the aptosid installation only. But certain commands below should be changed carefully to install and apply changes to the correct partitions. If aptosid is NOT your first installed system on your hard drive or if you want to save information on other partitions, then you should skip the "Wiping disk and filling with random data" section, and move on to "setting partitions". To check your current partition scheme open a terminal and enter the following commands:

su
fdisk -l

If you are chainloading you will also need to decide which system to write to the mbr of the bootloader and make any needed changes to the bootloader using the installer during installation.

Warning: THESE METHODS WILL WIPE ALL DATA ON A HARDRIVE! ALL THE DATA IT CONTAINS WILL BE LOST! IF YOU DO NOT WANT THAT, THEN SKIP TO THE "SETTING PARTITIONS" SECTION! IF YOU ARE USING MULTIPLE HARD DRIVES YOU SHOULD PHYSICALLY UNPLUG THE HARD DRIVES YOU DONT WANT TO GET OVERWRITTEN TO PREVENT ANY UNWANTED DATA LOSS DURING WIPING. AFTER THE WIPING PROCESS YOU CAN PLUG THEM BACK INTO YOUR COMPUTER TO GET YOUR BOOTLOADER RIGHT.

At first we should ensure, that absolutely nothing useful can be found on your harddisk, by overwriting the entire disk with random data. Depending on the capacity of your drive, this can take a very long time (on my laptop it took about 4 1/2 hours for a 60 GB harddisk)!

Warning: AT THIS POINT, ALL STORED DATA ON THE HARDDRIVE WILL BE LOST FOREVER!

dd if=/dev/urandom of=/dev/sda bs=10MB

If you want to check the progress, open another root-terminal and enter:

Using a single pass of shred should be fine for common users. You can choose as many passes as you like, but passes 1,13, and 25 write random data. A single pass will take about 1-2 hours depending on your hardware. To use a single pass of shred open a terminal, switch to root, and enter the following command:

Remark:
Choose your passphrase wisely, because if you ever should forget it, you are doomed!
Choose a sufficient long password as well (16+) and use many different characters (special chars, capitals etc)!
A LUKS encrypted partition has 8 key slots, which means you can have more than one passphrase to unlock the encrypted container, and you can change your passphrase afterwards (by first adding another one, and then deleting the former one), which is recommended from time to time. Please have a look at the manpage (man cryptsetup) for more details.

FIXME: Is this still true?
Additionally: do not encrypt partitions over 1TB, since the aes-xts-plain security guarantee deteriorates as more data is encrypted with the same key.

Next comes the creation of the LVM physical volume, volume group and volumes onto the encrypted container:

This creates a logical volume for swap with 3 GB (= /dev/!cryptVG/swap), and allocates the remaining free space to the logical volume for our / (= /dev/!cryptVG/root). Since I want to use hibernation, and my laptop has 2 GB RAM, I think, 3 GB for swap is a good number, and since it is all contained in one encrypted physical partition, The point for splitting up / into more separate logical volumes is increased security and preventing your system of growing out of space, the con is that you have choose wisely the space you allocate. But using a separate partition for /var is also used sometimes on production servers. A more practical case for a general case is having a separate partition to put the data that matters all in same place which allow for simple backup, if you want to be able to have a copy on you, consider using a virtual drive (a simple file used as a loop device.

The final step of our preparations is to create the filesystems on the logical volumes, create the necessary mountpoints, and mount our new / and /boot partitions:

In the second tab (Partitioning), have a look, if /dev/!sda1 shows up in the device-list. If not (like it was in my case), start gparted by clicking on "Execute", quit it without changing anything, and /dev/!sda1 should be shown now.

You only need to unselect "format with ext3", and select /boot as mountpoint for /dev/!sda1.

Then configure the settings in the other tabs, and finally start the installation.

If the Installer doesnt recognize the crypt partitions, start gparted through the 'execute' button, reinstall the Installer or manually include the mountpoints in /root/.sidconfig

Remark: The keyboard might be mapped as 'qwerty' (US standard). So, if you get an error like: "cryptsetup failed, bad password or option?" have a look at this keyboard picture∞ and find the corresponding keys for your password.

BIOS: Use a setup password, and configure the first boot device to be your boot-harddrive.
GRUB: Set a grub password to protect your grub menu.
CRYPTSETUP: Change your passphrase for the LUKS encrypted container from time to time (have a look at man cryptsetup).

Keep in mind: Anyone with physical access to your harddrive can make changes to your /boot partition (like sniffing your password the next time you boot).
Remark: One could install /boot on an USB stick ...

If your encrypted machine nevertheless should not boot for any reason, simply boot from the aptosid LiveCD?, open a root-console, and mount your encrypted filesystem manually the following way, to be able to correct the problem:

Now you have full access to your installation again, and you can chroot into /media/aptosid, if needed (especially necessary, if you need to make changes to the file /etc/initramfs-tools/conf.d/cryptroot and regenerate the initrd-image).

Replace [UUID of your /dev/!sda2] with the actual UUID of your /dev/!sda2.

press "ctrl x" to save,then y,then enter

Remark: It is not possible, to boot this kind of installation without that file being added to the initrd-image in the next step, but strangely when doing such an installation with the Debian installer on Debian or *Ubuntu, this file is not present. I could not find out, how the Debian installer handles that matter differently. If anybody knows more about this, please leave a comment in the forum thread (see at the end of this page).