Posts Tagged 'hardy heron'

Playing with Windows 7 beta in Ubuntu Hardy

…using kvm, that is. But wait, you say, why come from freedom and subject ourselves to this:

Wait, what??

Wait, what??

The thing is, after reading that the SABDFL himself seems to like the recently released Windows 7 beta 1, I somehow felt compelled to try it out, too. Like Shuttleworth points out, it’s nice to have some competition, and of course it doesn’t make sense not to be aware of what that competition looks like.

While I won’t have time in the next few weeks to play with this beta a lot, now was the time to download it, because MS are taking it offline on 10 February. You’re provided with an activation key for the installer, and the installed system remains accessible until sometime in August. In case you’re getting curious too, the download page is here – note that the iso to download is rather substantial at 2.5GB. To avoid too complicated issues, I opted for the 32-bit version.

On the Guest Support Status page on the kvm wiki I found an entry stating that Windows 7 has been tested on the amd64 architecture, with kvm-62. Guess what? That happens to be exactly the version of kvm that’s in the Hardy repositories. It’s actually been a while since I installed kvm (note that kvm needs hardware support in your CPU and your BIOS by the way, otherwise look up qemu, but I’m not sure if you want to run something big like this in that case), but off the top of my head you can install it in Hardy (please correct me if I’m forgetting anything crucial) by a simple

sudo aptitude install kvm
sudo adduser username kvm #replace username

and then a reboot (well, you could go without rebooting and then modprobing etc, but this is the brief version…). The adduser line allows you to use kvm as a normal user. As always, I’d like to add that you should know what you’re doing when running with root privileges (sudo), and at the very least read the man pages to any commands pasted from some random guy’s blog… there, I said it again.

The kvm wiki entry also lists the settings with which Windows 7 was tested; there’s one issue here and that is that the usb-options to kvm don’t work on Hardy. So, omitting those, we can install with the following two lines:

qemu-img create -f qcow2 win7.img 15G
kvm -localtime -std-vga -m 2048 -cdrom win7.iso -boot d win7.img

I think I’ll skip explaining the switches – seriously, read the man pages. Well, actually, the kvm man page doesn’t contain much, so look at the one for qemu instead. Obviously, you can drop the -cdrom and -boot options on subsequent runs.

The installation ran buttery-smooth here, but then I’m a bit spoiled with an Intel T8100 CPU and 4GB of RAM. Anyway, I think it was mostly a disk-performance limited affair (it’s all on an encrypted LVM volume on a slow laptop harddisk…), but still I was looking at a completely installed and also fully patched system (yes, kvm/qemu takes care of passing-through your network connection) within 45 minutes. At this point, the disk image takes up 5.1GB of space.

Finally, although I took umpteen screenshots during installation, I now decided I won’t put them up here; partly because I might get shot by the users of (“Hello all, I’m the new guy who just joined, and I’m plastering your RSS readers with Windows screenshots… ;)”), partly because the web is flooded with Windows 7 screenshots already, and partly because I’m hoping you’ll try it out for yourself. Have fun!

Edit: it seems I haven’t been keeping track of my friends’ feeds properly. Shawn wrote about this already over a week ago. Also, he did post his screenshots…


Skype on Ubuntu 8.04 amd64

I know, I need to play a bit more with Ekiga and other VOIP tools. But for now I really just wanted to quickly fire up Skype, and with Ubuntu Hardy it has become quite a bit simpler than before to install it (the 32bit executable that is) on an amd64 system.

Mistrusting as I am, I didn’t at first believe that it could be as simple as this Ubuntu Forums How-To promises. Basically it says you need just three commands (and to give away the conclusion – it’s true!):

sudo apt-get install ia32-libs lib32asound2
wget -O skype-install.deb
sudo dpkg -i --force-all skype-install.deb

Now I’m fine with the first two; obviously, you need the skype package, and you’ll need some basic 32bit libraries to run it with. But “–force-all” is a bit drastic, and I really wanted to know what warnings and errors I’d be missing out on. So let’s see:

$ sudo dpkg -i skype-debian_2.0.0.68-1_i386.deb
dpkg: error processing skype-debian_2.0.0.68-1_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
Errors were encountered while processing:

Unsurprising. But instead of now forcing everything, let’s just force it to accept the architecture:

$ sudo dpkg -i --force-architecture skype-debian_2.0.0.68-1_i386.deb
dpkg - warning, overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
Selecting previously deselected package skype.
(Reading database ... 103178 files and directories currently installed.)
Unpacking skype (from skype-debian_2.0.0.68-1_i386.deb) ...
dpkg: dependency problems prevent configuration of skype:
 skype depends on libqt4-core (>= 4.2.1); however:
  Package libqt4-core is not installed.
 skype depends on libqt4-gui (>= 4.2.1); however:
  Package libqt4-gui is not installed.
dpkg: error processing skype (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:

Right. I thought this was a static build? Why does it depend on that QT stuff?

Anyway, this is where I realised that when you set –force-architecture dpkg still tells you what objections it would have had otherwise. So we may as well –force-all and get on with it:

$ sudo dpkg -i --force-all skype-debian_2.0.0.68-1_i386.deb
dpkg - warning, overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
(Reading database ... 103313 files and directories currently installed.)
Preparing to replace skype (using skype-debian_2.0.0.68-1_i386.deb) ...
Unpacking replacement skype ...
dpkg: skype: dependency problems, but configuring anyway as you request:
 skype depends on libqt4-core (>= 4.2.1); however:
  Package libqt4-core is not installed.
 skype depends on libqt4-gui (>= 4.2.1); however:
  Package libqt4-gui is not installed.
Setting up skype ( ...

Configuration file `/etc/dbus-1/system.d/skype.conf', does not exist on system.
Installing new config file as you request.

If I had been more trusting, that would have worked straight away… Interestingly, Skype looks and works just fine despite the missing QT libs (well yeah, that’s what a static build is for). Who configured those package dependencies??

Eight tips for a robust Ubuntu Hardy installation

It’s been a while since I wrote stuff here – ironically I thought it was cool to get my own domain name, and then I ended up having too much fun on the GNU/Linux blog I also started. This should actually also go on the other blog, but I really wanted to write something here :)

Besides, the more Ubuntu buzz on blogs, the better, right? With the release of Ubuntu 8.04 this week, it couldn’t be a better time.

About these tips

If you’re new to the GNU/Linux operating system, this may not be for you. Nothing I’m mentioning here is complicated in any way, but it sort of assumes you’re reasonably comfortable finding your way around in Ubuntu. Instead, you may want to check out the Ubuntu website and, if you’re looking for help, the Ubuntu Forums.

The tips I’m listing here are a personal collection of things that I think might make your Ubuntu system that little bit more robust. That’s not only in a security or stability sense: I’m also thinking about protecting my system from my own tweaking and fiddling around (which you’ll inevitably do if you want to learn new things).

The tips here are most simple to act on at installation time, so I’ve sort of turned this into an installation advice list. Quite a few pointers here point back to my own writing of this week, for which I apologise. My middle name is not Narcissus, but those pieces needed a good overview to connect them, and this is it.


1. Check hardware compatibility before you start – this is still a big problem for all free-software operating systems. By now, it’s no longer a problem the developers can really help: all hardware could be made compatible if some manufacturers weren’t so secretive about the devices they make. As a sad result, the Ubuntu Forums are full of reports on (mostly) hardware compatibility problems.

No general recommendations here, but you’ll want to be prepared. If your wifi chip vendor is an ***, it’s helpful to know which packages and other files you need to have at hand. A few pointers: HardwareSupport on the Ubuntu wiki pages, TuxMobil,

2. Download a disc image using BitTorrent – it takes some persistence to find the page with the torrent links for Hardy if you start from the Ubuntu frontpage. I presume they don’t want to confuse new users. Of course, using the torrents takes some load off the main servers, helps some people, and (best of all) it’s likely faster too (especially now, just after the release date).

If you’re interested in the tips in the next section, you’ll want the alternate installer disc image.


Almost all choices you make during installation are revertible later on. I mean, you can always change your username, clock settings (local or UTC time?), which packages you want. One thing is a bit more tricky to change later, and that’s partitioning your disk(s). The alternate installer gives you some neat extra partitioning options which I want to highlight here.

3. Logical Volume Management – creating your file systems as LVM logical volumes gives you a lot more flexibility. The LVM HOWTO has a section “Benefits of Logical Volume Management on a Small System” which however doesn’t mention one of its cooler features: snapshots. LVM snapshots allow you to keep an image of your file system frozen at some point in time.

That will be useful for at least one thing: six months from now, you can take a snapshot of your root file system, upgrade to Ubuntu 8.10, and if it didn’t work well (proprietary video and wifi drivers seem to have regressions to no end), you still have a working 8.04 snapshot you can boot to use until you fixed the upgrade.

The other useful application for the home user: it’s easier to create consistent backups from a snapshot. Now, while you’re at it, I’d combine LVM with…

4. Disk encryption – reusing the rationale from this post: “if someone steals your laptop, you’ll worry a lot less about them getting access to your email and other important accounts (think browser cookies…). In case you’re wondering why the user login won’t protect you: anyone with physical access to the machine – like a thief – can just reboot and start in single-user mode, thereby getting root user privileges. Not so with an encrypted disk”.

Be sure to make frequent backups though – recovering data from an encrypted disk can be hard.


5. Set up version control on your configuration files – before you stroll off to your favourite geek forum and take advice from everyone and their dog to alter all kinds of stuff in configuration files under /etc, you might want to ensure that you can always get back what it said originally. Don’t get me wrong, I also try risky stuff people I’ve never met recommend to me, but I really like to keep track of those actions, too. So here you go: version control on /etc using Bazaar. As explained there, version control gives you some cool flexibility that a simple backup wouldn’t.

6. Installing additional packages: use aptitude – actually that’s not really what I want to recommend. There are quite a few APT front-ends and it’s worth checking out several, especially if you’ve never looked beyond Synaptic. So check out a few, and then decide that you like aptitude :)

Aptitude runs in a console, and has both a direct command line mode and an interactive mode. Its killer feature for me: it tracks which packages were only installed as dependencies of a package you really chose. So if you ever tell it to remove that package, it will remove its dependencies, too.

Here’s a more elaborate discussion of the tool’s merits.

7. Keep non-repo software under /usr/local – just one more quote of my own writing (promised!): “To ensure that the package manager doesn’t interfere with software you installed “manually” (i.e. not through dpkg, apt-get, aptitude, synaptic, …), there’s an article in the Filesystem Hierarchy Standard that says everything you install manually should go into /usr/local (or /opt, actually) and not directly into /usr.”

If you want to make it easier for yourself to enforce that policy, without reading every line of every install script you use, you might like to check out that post. It’s about installing software on /usr/local without full root privileges.

8. Secure your web browser – with properly set user permissions, should you now bother with such things as a firewall and a virus scanner on your desktop (laptop) machine? Probably not. (Although I wonder if everybody is sudoing all the time, won’t somebody exploit that at some point? How high are the chances that a malicious script that’s trying to use sudo hits you while a sudo session that you started is still open? Not sure how that would work, but then I’m not a seasoned malware designer).

A lot of executable code that you rake in as a normal user is stuff coming through your web browser: scripts on web pages, but also (Firefox) browser plug-ins. Malicious code in those can only destroy stuff that you have write permission for, and can only collect information that you have read permission for (which is typically most of other users’ data!), so decide if you think that’s still worrying. A good start for securing Firefox is this overview at Ubuntu Forums.

Wrap up

That’s all I could produce in my spare time this week… hope it’s useful. I’d love to hear if it is. Commenting here does not require you to leave any contact details (hint!). Thanks for reading.

First thing to do on a fresh Ubuntu Hardy installation

Edit – although of course I love to have some readership for this post, I should say that you might want to check out this cooler solution instead: etckeeper is a package that was designed to do all the stuff I’m describing here… thanks to Daniel for his comment!

Well, to be absolutely honest, it was the second thing I did. The first thing after installing was fixing the wifi drivers. But straight away after that, I set up version control on the configuration files in /etc. Basically, that stops you from making a mess out of your configuration files. Sounds good?

Thanks to the guys at Canonical (who are also the ones backing Ubuntu), version control has become easier than ever: with Bazaar it is so easy to set up that I basically have version control for anything I’m working on nowadays. If you know about revision control already, probably you see the use of it and could skip the rest of this post… or you could stick around and see how effortless things become with Bazaar (bzr).

Edit – probably superfluous, but just another word of warning: don’t do anything just because I did. There’s a lot of sudoing going on below here, so you could do damage to your system. Don’t trust a random blogger. Read the man pages, read the online documentation.


Before I show how to set it up, let’s see how you’d use it. Every time you’ve made significant changes to /etc (let’s say you installed new packages, or created new users, or reconfigured your acpi-support settings, or anything), you create a “checkpoint”, or in version control lingo: you commit a revision. That could be as simple as two lines in a terminal (and I’m sure you can get a GUI for this too):

cd /etc
sudo bzr commit -m "short comment on what you've done"

Well, actually, if you had installed new software you might not know what had changed. So you’d have a few more lines:

cd /etc
sudo bzr status #tells you which files are new or have been changed
sudo bzr diff filename #tells which lines in "filename" were just added/removed
sudo bzr add . #puts any new files under version control
sudo bzr commit -m "short comment on what you've done" #sets a checkpoint

Still, not too scary, I’d say? Later, you can review what you changed before:

cd /etc
sudo bzr log #shows comments, date, and version numbers of committed revisions

You can go back to any revision now, say e.g. to number 3:

cd /etc
sudo bzr revert -r 3 #sends state of /etc back to revision 3

Here’s the real kicker though: you can also revert changes within specific files, between any two revisions. That is, you don’t have to send the whole file back to it’s old state, bzr can just remove/reinsert the lines that you’re interested in and leave all other (later!) changes to the file intact. This is what really makes revision control more powerful than plain and simple file backup.

An example: you’ve changed /etc/X11/xorg.conf to use the proprietary fglrx video driver. You removed all the tweaks you had put in before for the open-source driver. This change was part of revision 4. Some days later, you put in all kinds of tweaks for your synaptics touchpad. That was revision 9. Yet some time later, you added wacom tablet settings. Revision 15. But now, you decide you want your open-source driver back… If you’d restore the backup, you’d lose your synaptics and wacom settings. With bzr, this is how you do it:

cd /etc
sudo bzr merge -r 4..3 ./X11/xorg.conf
sudo bzr diff #shows the changes, just to check if it was ok
sudo bzr commit -m "went back to the open-source driver by undoing rev4"

That’s it. Really. Effortless. All your fancy tweaks for the video driver have now been put back in place, but the changes you made for the input devices have not been removed. (In case you’re interested: the bzr user guide calls this reverse cherry-picking).

Stating the obvious

This is of course useful for a lot more things than just /etc. Revision control works well on anything that looks like text. Have a look at the files in your ~/.gconf directory: they’re in xml format. Now if you tweak the looks of your Gnome desktop and applications, bzr can track what changes you made. And restore older settings later.

Setting it up

Installing bzr is of course as easy as

sudo aptitude install bzr

…or apt-get if you want to be old-skool ;) Now, I had a look around the net to see if anyone else used bzr for this, and found this – frankly, that’s pretty much what I’m about to type up here. I’ll give it a spin of my own but I’ll also skip a few bits here, like how to back up your bzr repository and how to send yourself messages in case you forgot to commit your changes to the repository – so see for those parts.

Bringing everything in /etc under version control is as simple as

cd /etc
sudo bzr init #creates a version control repository under /etc/.bzr
sudo chmod go-rwx .bzr #only root may see it
sudo bzr add . #adds everything in /etc to it
sudo bzr commit -m "freshly installed state of Hardy"

You need to use superuser permissions here because you’re not allowed to read everything as a normal user (think /etc/shadow and such). As you’re storing those sensitive files in the bzr repository, you don’t want anyone to read it, hence the chmod. As a result of this chmod, you will now always need to use sudo – otherwise bzr cant access .bzr/.
Now, bzr by default is set to skip some files, for example something like apt/sources.list~ is a previous version of apt/sources.list and will get skipped because of the tilde. Of course you want to check that bzr doesn’t accidentally skip anything important, so

sudo bzr ignored #prints all skipped files

If you see any file there that you did want to add, you can add it by explicitly typing

sudo bzr add sources.list~ #you don't want that, but it's an example

Basically, your /etc directory is now under version control. You can very easily check for changes with

cd /etc
sudo bzr status

as I said before, and if you’ve installed new software and new files appear in /etc, you can now do

sudo bzr add . #adds all the new files
sudo bzr commit -m "installed awesome new package"

A few more things you should note

There may be some files that you actually don’t want or need to put version control on. You can create an ignore-list for those files, so that bzr will skip them when you say “add .”. Guess what the command is?

sudo bzr ignore ./mtab #bzr will ignore mtab from now on

This actually creates a file /etc/.bzrignore with “./mtab” in it. The leading ./ means you only want to ignore /etc/mtab, not any mtab found somewhere under /etc.

Now, you actually already added mtab in the section above, so there’s no point ignoring it now – it’s already under version control. To take something out of revision control:

sudo bzr remove --keep mtab

Here, –keep means that you don’t want to delete mtab. Otherwise, bzr might think you want to get rid of the file, while you just want to take it out of revision control. So far, I have done this on four files: ./mtab, ./adjtime, ./resolv.conf, ./ – these are all files that get generated automatically and are changed by the system (on a standard Hardy install, resolv.conf gets changed by network-manager). After running “remove –keep” on them, you’ve got something to commit again: removing is a change, too.

Second thing. If you installed bzr and immediately used it as superuser, something will be funny in your home directory now: the ~/.bazaar directory will be owned by root. If you use bzr on other things later on, without sudoing, that will generate errors. So

sudo chown -R yourname:yourname ~/.bazaar

In this .bazaar directory you will find a file .bazaar/ignore which specifies the patterns that are ignored by default (like the tilde). Change it as you like.

Finally, if you want to be more verbose in your commit messages, you can leave out the -m and the comment, and bzr will open an editor for you. Type your essay, then save and exit to complete the commit. But by now I’m really just telling you stuff you could read in the Bazaar User Guide – an excellent piece of documentation. Have lots of fun!

PS: if you’re a control freak like me (hey, you’ve read this dreadful piece all the way down), you may also like the previous post on strictly separating repo and non-repo software.

Staffdo: my handicapped version of sudo

As I’ve said before, package management is the coolest feature in any GNU/Linux distro. Prime example are the dpkg/apt tools that are used in most Debian-based distros. Repository software has been tried and tested, and package management ensures that that software Just Works. Now of course, that’s not something you’d want to mess up.

To ensure that the package manager doesn’t interfere with software you installed “manually” (i.e. not through dpkg, apt-get, aptitude, synaptic, …), there’s an article in the Filesystem Hierarchy Standard that says everything you install manually should go into /usr/local (or /opt, actually) and not directly into /usr. Usually you can easily configure a software installer by setting something like “prefix=/usr/local” somewhere.

That’s half the story: you don’t want to install stuff manually and have the package manager overwrite half of it later. The other half of the story is that there’s often a reason why that stuff wasn’t available in the package repository – most likely it’s not as thoroughly tested yet. I want to protect the main system files from alpha-quality software.

Anecdotal: I installed a piece of beta software once that thought it was ok to temporarily replace /bin/bash by something else. Because the script was too simple, it didn’t properly change it back. At the next boot, everything was obviously broken, and for a day I had no idea how to fix it, because I wasn’t aware in the first place that that installer had gone anywhere near /bin. It could do so silently because I called the installer through sudo….

On Debian, there’s a “staff” group (I discovered that on this page) that has privileges that solve the problem: members of staff can install files under /usr/local but not anywhere else. It’s also there on Ubuntu (I just installed Hardy Heron, see previous posts), although it doesn’t show up in the gnome menu that deals with groups. You can see it though in /etc/group. Unlike on plain vanilla Debian, /usr/local however doesn’t have staff group-ownership set.

Here’s what I did (note – it’s what I did, not what you should do – don’t trust a random blogger! – read the man pages for all of the following commands):

sudo adduser staffer #you can enter any password you like, because...
sudo passwd -l staffer #disables the password, just like for the root account
sudo adduser staffer staff #adds staffer to the staff group
sudo chown -R root:staff /usr/local #set group-ownership like on Debian
sudo chmod g+w /usr/local/* #make writeable for staff members
sudo chmod -R g+s /usr/local #setgid

Note that the last two lines work for me because I’m on a freshly installed Ubuntu Hardy, where /usr/local is still practically empty. If it’s not empty, this may set the setgid bit on some files, rather than on the directories only. I’m not sure if that’s a good thing (opinions welcome!). Now when you try this

cd /usr/local
touch testfile #error because you don't have write permission
sudo -u staffer touch testfile #no error
sudo -u staffer rm testfile
cd /usr
sudo -u staffer touch testfile #error

That’s it, basically. So now, you can install to /usr/local as staffer instead of as root, and you’ll get an error message when the installer at hand is trying to be naughty, writing to somewhere else. What’s this “staffdo” in the title of this post about then? Well, to make things look neat, I added

alias staffdo='sudo -u staffer'

to my .bashrc file. And you read all the way down this page to find out… hope it wasn’t disappointing!

Installing Ubuntu 8.04 with full disk encryption

“Update”: it’s been ages since this was first posted, but I still use a system that’s configured as described below. The hardware under it has changed, and it’s seen some distribution upgrades, but I’m quite happy with this old disk layout. It’s good news then, that Ahmad, Niels, and Matt report that you can still do the same on Ubuntu 10.04 LTS. Thanks guys, means I still don’t have to write anything new!

This is a brief walk-through of installing Ubuntu Hardy Heron (I used the release candidate, see the previous post) with a LUKS encrypted LVM partition, and preparing it for snapshot backup (explained below). You will need the “alternate” installer for this (ie. not the “desktop” Live CD).

A couple of months ago I did the same thing for my other machine using the Debian 4.0 (Etch) installer and as far as I can remember it was exactly the same procedure. At the time I was planning to run this installation again in a virtual machine and take screenshots, but actually it is really simple (cheers to the team that wrote the installer!) and if you’re attempting this you probably don’t appreciate such hand-holding anyway. So I didn’t bother to make neat virtual-machine screenshots, but to lighten up the text I did put in some crufty digital-camera screenshots here and there.

Why would you want this?

For a home user like me, I think it makes most sense to have this on a laptop. While even strong encryption can’t guarantee that no one will ever read your data, the real-world scenario is of course that you don’t really have anything to hide. Encryption is rather an extra convenience: if someone steals your laptop, you’ll worry a lot less about them getting access to your email and other important accounts (think browser cookies…). In case you’re wondering why the user login won’t protect you: anyone with physical access to the machine – like a thief – can just reboot and start in single-user mode, thereby getting root user privileges. Not so with an encrypted disk.

An objection here is that your CPU will have to do some extra crypto-exercise whenever you read or write to disk, and that will cost some battery life. I haven’t quantitated this but it doesn’t seem to make a huge difference (sorry, that’s a worthless statement indeed). I didn’t notice any slowdown either, using a 1.8GHz Turion64 (more worthless subjectiveness).

What about the LVM stuff? The whole logical volume management thing was mainly designed to give you flexible storage options (eg. add a hard disk and simply expand your existing partitions onto it), and of course that’s not really important for a home user. Heh, in a laptop you’re certainly not very likely to add a new disk. However there’s one feature of LVM that I think is useful to us: snapshots. An LVM snapshot gives special access to your file system as if frozen at some point in time. That means you can run a backup using the snapshot and you can continue working at the same time, without worrying that the backup will catch files in some inconsistent state because you were writing to them.

That’s not a big advantage, because it’s not a big problem most of the time. But as it’s so easy to set up now, why not do it? One downside I can see is that it makes it a bit trickier to access your file system from a recovery disk. Any recovery tool understands plain ext3 partitions (even MS Windows can access those), but if you want to open an (encrypted) LVM partition you might need to check the feature page of the recovery tool, and jump through a few more hoops. In the end, of course, you set this up to enable snapshot backups – so you shouldn’t need recovery tools to begin with ;)

Enough talking, let’s get on with it

Ubuntu installer boot menu

All rise please :)

What follows below is really confusing, because everything is referred to as a “partition”. The traditional partitions on your physical hard disk are called partitions, but then inside your encrypted volume you’ll also create an LVM partition, and as far as the installer is concerned the logical volumes you’ll create inside the LVM are also called partitions. There’s probably a more formal lingo for this but I don’t know it. Besides, calling all these things partitions also shows the elegance and transparancy of the system: despite the fancy stuff all your encrypted logical volumes eventually appear to be plain partitions.

One more note: on my laptop, I had to disable the frame buffer (see yesterday’s post). The crufty camera shots below may look slightly different than what you’ll get served.

Ok, so you have the alternate install cd. Boot it and answer some basic stuff (keyboard layout etc) until you get to the disk partitioner. The partitioner has an automatic option “set up encrypted LVM”, which uses the entire disk, creates a small unencrypted boot partition, fills the rest of the disk with an encrypted LVM partition, and creates two volumes within it: one for swap space and one that holds your root file system.

For our purposes, we’ll have to opt out of the automatic option: it doesn’t leave free space for snapshots, and I also really prefer a separate volume for /home. Manual partitioning it is, then.

We start with creating a plain partition to mount as /boot later. I think 100MB has always been more than enough for that, but the automatic partitioner took 250MB: good if you want to be on the safe side. All you need to do is specify the mount point – the standard options for an ext3 file system are fine I think.

I took one big partition to cover the rest of the disk. Here, we choose to use it as “physical volume for encryption”. Again, all the standard dm-crypt options are just fine as far as I’m concerned. But never trust a lame blogger: you can read more about your choices in the Debian Installation manual – currently, section covers encrypted volume options. After that, you’re “Done setting up the partition”.

/boot and crypto volume

The partitions overview by now

At this point, the main partitioner menu becomes a little bit unintuitive (it’s just a layout problem really): the option to Configure encrypted volumes appears at the top, where you may not expect it because you’ve been configuring partitions in the lines below. This prompts you to commit your partition changes and wait for the secure erase of the partition to be encrypted (this fills the partition with random bits and takes quite a while). When that’s done, you’ll need to choose a passphrase that unlocks the partition.

You’ll be typing this passphrase quite often (unless you suspend rather than hibernate or shut-down most of the time – note that disk encryption doesn’t protect your suspended system in any way) so my advice is not to pick something too secure ;) If you want to be fancy, you can later create a key file to unlock the system disk using a USB key. Here’s a description that works for Debian Etch; I didn’t try on Ubuntu Hardy yet, but I believe there have been alterations to the boot process which may change the details slightly.

encrypted volume

Note the new entry

Now, when you get back to the main partitioner menu, “Encrypted volume” should show up as a new disk. There’s one partition inside it, marked #1, which we’ll use as “physical volume for LVM”. Back in the main menu, again a new option appears at the top – Configure the logical volume manager.

Create a volume group, using your one LVM partition (this seems a bit silly in this context but it would make sense if we had many disks to manage). Now you can create logical volumes within that volume group. I took a generous 10GB to configure as / later, a 1GB swap partition (note: take more if you have more RAM installed and want to write a hibernation file to it), and most of the rest of the disk to mount as /home later. At this point I left a few GB free to be able to create snapshot volumes later.

LVM configuration

The LVM config menu

LVM configuration

Configuration details: note the bit of free space left. Volume names are arbitrary.

You don’t need much space for a snapshot volume: it only stores reverse changes of your main file system from the time point where you created the snapshot. Unless you leave your snapshot around for days, “a few GB” is in fact far too much. If you’re getting curious how the snapshot backups will work, see this guide from the LVM HOWTO.

with logical volumes now

Back in the main menu…

So now you’re finished configuring LVM, and you get back to the main partitioner menu. It’s really crowded now: the LVM logical volumes show up as separate disks in addition to the physical disks and the encrypted volume. This is where you configure the partitions on the logical volumes, which are again marked #1. I’m only deviating from the default options in one case: for /home I chose to reserve 0% reserved blocks – I don’t think a full /home can bring the system down (but correct me if I’m wrong! update: it seems I am, see this comment below).

What else? Nothing. Scroll all the way down to find the “Finish partitioning” option and wait while your system gets installed. Unlike with the “desktop” installer you don’t have a live system that allows you to browse the internet while the install is running, so bring out your knitting kit now… (you’ll have to do speed-knitting though, the installer is pretty fast).

How simple was that? I’d say: another cheer for the installer team!

Ubuntu 8.04 RC AMD64 on a HP nx6125 laptop

The release candidate for Hardy Heron runs ok on this machine. See below for the few extra pointers needed to get it set up.

In case you have found this page, presumably through a search engine query, you will probably know that this particular laptop has had rather a bit more than its fair share of trouble running GNU/Linux. Nonetheless I’ve been happily running Ubuntu 5.10, 6.06, and 7.04 on it – well, maybe not always happily: a bad choice of video driver at some point ran the chipset pretty warm. I wondered why the battery ran down so quickly, but when after a week the coating on the palm rest came peeling off I realised something was wrong… it’s still working though. It looks awful, and it’s been in service with power supply problems, but it’s alive. That is, I have no excuse to get something else…

Until now I had always left the stock installation of Win XP available as a second boot option, because I needed it for presentations (external video), and to run Suunto Training Manager. This time I decided that I didn’t need the Suunto nonsense anymore and that I should just bite the bullet and struggle until the external VGA works.

So… a clean install using the AMD64 release candidate disc. I used the alternate installer because I wanted to play with LUKS encryption (more on this in the next few days, I hope), and found that it really only needs very little “help” to run despite this particularly bad choice of hardware.

Here’s what you need to do extra:

  • Before attempting the install, download the Windows XP drivers for the Broadcom wifi card (my machine has a bcm4318 rev02 chip) from Hewlett-Packard. That seems the most logical place to get them… The exe file HP provides is a bit inconvenient, but it’s actually really just a cab archive. So get cabextract, too (this link gets you an official package for hardy, to be used at bullet point three).
  • At the installer boot menu, hit F6 and add “fb=false noapic nolapic” to the kernel options. Actually the latter two are optional since the newer kernels seem to detect the buggy APIC by themselves. You do need to disable the frame buffer or the installer will just give you a blank screen (just to repeat: I’m using the alternate installer).
  • After installation, log into your fresh system and install ndiswrapper-common and ndiswrapper-utils, which are both on the install disc (perfect!) under pool/main/n/ndiswrapper. So install cabextract, unpack the HP driver archive, and install it with something like “sudo ndiswrapper -i bcmwl5.inf” (and of course don’t take my word for it, read man ndiswrapper!). Almost done: now you need to do what this guy says. Actually, on my machine there was no b44 or b43legacy driver so in my case I reduced the script to three lines: remove the b43 module, remove the ssb module (don’t know what that’s for, to be honest), plug in the ndiswrapper module.
  • That’s it. Really, that’s it!! With just the disabled frame buffer and the ndiswrapper wifi everything seems to work. I don’t have hardware accelerated graphics but if I cared I wouldn’t have had this laptop (and probably I could install the ATi proprietary driver). I still have to check the external VGA. The other significant stuff runs just fine: wifi reception is perfect, suspend and hibernate work, the volume and screen brightness buttons… and the CPU fan seems to spin up properly even after a hibernation.

I’m not being cynical here: I’m seriously happy that it’s now so simple to get this buggy hardware running the latest and greatest software. Will save me some money for some time to come.

Why ndiswrapper, you ask? I tried the new b43 driver too (if you still want to try it: you’ll find an error message on tty1 that tells you where to get the right version of the firmware), and while the b43 driver does recognise the wifi card, it never lets me connect to a network. I thought this might be due to the combination with Bluetooth, so I disabled that in the BIOS, but still had no luck with it. Oh well, ndiswrapper is a very decent solution until I’ve earned me a laptop with proper driver support (Dell anyone?).

edit: I just hooked up a monitor, and the external VGA works, out of the box! You don’t even need to restart X for it. I’m really not going to bother with the proprietary ATi driver now. This is so cool. I think I’ll wake up a house mate to share the joy… oh wait, working VGA-out was never a problem on most Windows setups, so uh, maybe they won’t understand :P