Full disk encryption with Arch Linux footnotes

Pavel Kogan has an excellent guide to install Arch Linux with full disk encryption. I’ve taken the liberty of copying the instructions, adding a couple tweaks:

  1. Boot the Arch Linux installation medium.
  2. Run these commands (You may want to use different sizes for swap and root volumes):
    parted -s /dev/sda mklabel msdos
    parted -s /dev/sda mkpart primary 2048s 100%
    parted -s /dev/sda set 1 boot on
    cryptsetup luksFormat /dev/sda1
    cryptsetup luksOpen /dev/sda1 lvm
    pvcreate /dev/mapper/lvm
    vgcreate vg /dev/mapper/lvm
    lvcreate -L 4G vg -n swap
    lvcreate -L 15G vg -n root
    lvcreate -l +100%FREE vg -n home
    mkswap -L swap /dev/mapper/vg-swap
    mkfs.ext4 /dev/mapper/vg-root
    mkfs.ext4 /dev/mapper/vg-home
    mount /dev/mapper/vg-root /mnt
    mkdir /mnt/home
    mount /dev/mapper/vg-home /mnt/home
  3. Go through the software installation steps of the installation guide, skipping the Initramfs and Boot loader steps.
  4. Install GRUB: pacman --sync --noconfirm grub
  5. In /etc/mkinitcpio.conf:
    • Change the line starting with FILES= to FILES="/crypto_keyfile.bin"
    • On the line starting with HOOKS= add lvm2 encrypt just before filesystems.
  6. Find the UUID of /dev/sda1 by running basename "$(find -L /dev/disk/by-uuid -samefile /dev/sda1)"
  7. In /etc/default/grub:
    • Change the line starting with GRUB_CMDLINE_LINUX= to GRUB_CMDLINE_LINUX="cryptdevice=UUID=[UUID]:lvm", replacing [UUID] with your own.
    • Add a line with GRUB_ENABLE_CRYPTODISK=y
  8. Run these commands:
    dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
    cryptsetup luksAddKey /dev/sda1 /crypto_keyfile.bin
    chmod 000 /crypto_keyfile.bin
    chmod -R 700 /boot
    mkinitcpio -p linux
    grub-mkconfig -o /boot/grub/grub.cfg
    grub-install --target=i386-pc /dev/sda
  9. If necessary, set up your BIOS to allow booting in CSM mode.

It also required me to enter the password using a QWERTY keymap. The instructions to add an alternative keymap to GRUB are rather involved, but I’ll try to write them up if I go through with it.

Advertisements

Ubuntu phone fundraiser

Canonical has started a fundraiser to develop an Ubuntu/Android phone. There’s a 600 USD early bird tier for one day to get the phone itself, and afterwards it’s a massive 830 USD.

As someone who was extatic at the Ubuntu progress in 2007 through 2009, but foaming at the mouth at their massive “not invented here” syndrome ever since, I don’t think I’ll be pledging anything for this. For example, the dual boot feature. They say they already have the Ubuntu desktop integration working on Android, so you’ll be able to use it immediately. Great, let’s do that. “Then shortly after launch we’ll push out a free software update that adds this desktop integration to Ubuntu mobile as well.” So we’ll have a functioning Android phone with Ubuntu desktop integration from the get go, and then we’ll have to start using Ubuntu natively instead of Android later? You want users to learn to use two GUIs which do the same thing to use one phone? (Actually three, unless the Ubuntu desktop works exactly like native Ubuntu, and assuming anyone who buys this is already familiar with Ubuntu.) Now that’s usability fail. How about either Android or Ubuntu? Sounds more like someone thinks Ubuntu isn’t quite ready for handhelds yet, and they want the users to beta test before reinventing the wheel once again.

cvs2git2svn

After discovering Ohloh, cleaning up and publishing repositories of yore seemed like a good idea. One of them was established back in the CVS newbie days, and contained lots of external binaries – Not the kind of thing you want to version control. Having used CVS, Subversion and Git (in that order), there was only one choice: Interactive rebase with Git. Also, the software was created while at CERN, so it should continue to be hosted there. And they had started a Subversion service in the meantime, so it was time to upgrade as well.

These instructions should fit for any CERN project, and can easily be modified to fit any repository. The usual warnings apply: YMMV and RTFM.

  1. Set some variables to avoid typing: svn_repo=Repository_name
    svn_user=User_with_edit_access
  2. Install the tools: sudo apt-get install cvs2svn git-core git-svn
  3. Create the cvs2git working directory: cvs2git_wd=$(mktemp -dt cvs2git.XXXXXXXXXX)
  4. Copy the contents of the repository (not a working copy) to the working directory: scp -r $svn_user@lxplus.cern.ch:/afs/cern.ch/project/svn/reps/${svn_repo}/* $cvs2git_wd. Don’t worry if /hooks is not copied – You don’t need it. If you don’t have filesystem access to the repository, you can try cvssuck. Be warned: It’s really slow.
  5. Set cvs2git global options:
    1. zcat /usr/share/doc/cvs2svn/examples/cvs2git-example.options.gz > $cvs2git_wd/cvs2git.options
    2. Modify at least ctx.username and author_transforms in $cvs2git_wd/cvs2git.options.
  6. Make the new Git repository: git_wd=$(mktemp -dt git.XXXXXXXXXX) && git init $git_wd
  7. Convert to Git (repeat for each module):
    1. Modify run_options.set_project in $cvs2git_wd/cvs2git.options
    2. Create Git import files: cd $cvs2git_wd && cvs2git --options=cvs2git.options. If you get any warnings or errors you might have to change the options again.
    3. Import to Git: cd $git_wd && cat $cvs2git_wd/cvs2svn-tmp/git-blob.dat $cvs2git_wd/cvs2svn-tmp/git-dump.dat | git fast-import
  8. Make a backup in case the rest goes hairy.
  9. If you need to (which was kind of the point of this exercise), do an interactive rebase from the first commit: git rebase -i $(git log --format=%H | tail -1).
  10. git-svn needs at least one commit to be in the Subversion repository: svn_wd=$(mktemp -dt svn.XXXXXXXXXX) && svn co --username $svn_user svn+ssh://${svn_user}@svn.cern.ch/reps/${svn_repo} $svn_wd && cd $svn_wd && touch .temp && svn add .temp && svn ci -m "git-svn dummy commit"
  11. Convert to Subversion:
    1. Prepare git-svn repository: git2svn_wd=$(mktemp -dt git2svn.XXXXXXXXXX) && git svn clone --username $svn_user svn+ssh://${svn_user}@svn.cern.ch/reps/${svn_repo} $git2svn_wd && cd $git2svn_wd
    2. Get Git commits: git fetch $git_wd
    3. Apply Git commits as master branch: git branch tmp $(cut -b-40 .git/FETCH_HEAD) && git tag -am "Last fetch" last tmp && first_commit=$(git log --format=%H | tail -1) && git checkout $first_commit . && git commit -C $first_commit
    4. Apply Git commits: git rebase master tmp && git branch -M tmp master
    5. Check if this works : git svn dcommit --rmdir --find-copies-harder --dry-run
    6. If it does, you’re good to go: git svn dcommit --rmdir --find-copies-harder

If the last step fails, the easiest way to continue is just to remove all commits from the Subversion repository, fix the Git repository, and restart at step 10.

Howto: Timelapse video from photos

It’s amazing what shell tools can do: Flickr accepts HD video (720p, or max 1280×720) up to 30 FPS, so I tried to create one within those limits from the high resolution photos from today’s sunrise. Turns out to be incredibly easy with free tools on Linux:

  1. Resize to 720 pixels height (if your images are still wider than 1280 you’ll have to replace x720 with 1280 (without the “x“): mogrify -resize x720 *
  2. Find the width of the images, and plug that into the following command instead of 1080.
  3. Create the video: mencoder mf://* -mf w=1080:h=720:fps=30:type=jpg -ovc copy -oac copy -o output.avi

The result