Month: May 2011

Project Neon 2011-05 summary

So here’s the first post of hopefully monthly summaries of what’s happening in the KDE trunk daily builds for Kubuntu a.k.a Project Neon.
Those that don’t know yet what Project Neon is should read Michal’s introductory post.

An important notice up front:
We will stop providing builds for maverick as of June 2nd. Everyone that wants to use KDE trunk should update. We’ll start providing builds for oneiric the same day.

A note to all Kubuntu users that want to try 4.7: Due to the new release layout from the KDE team the official 4.7 packages won’t be available before beta2 at least. For those that still want to try it: Try Project Neon! Our packages will provide you with 4.7 at least until 4.7RC1.

Updates for users:

– The apport hook actually became useful so we would appreciate it if you could use apport if you find a bug that’s our fault. Bugs in KDE still go to the KDE Bugzilla.
– The neon-clean script from project-neon-utils now removes packages by default instead of purging them. Use –purge if you want the packages purged.
– The XDG_CONFIG_HOME environment variable is set by default now on login. This doesn’t seem to cause any problems anymore and completes the user configuration separation.
– The neonbuid script got an –upgrade option so you can easily upgrade your neon pbuilder image to your current release.
– Rohan Garg started working on a project-neon-calligra package.
– The packages don’t build tests anymore. They break too often with our linker settings in Kubuntu making builds fail that would work fine otherwise.

Team stuff:

– I added a to lp:project-neon so there’s an easy way to get all of the teams branches now. Creates checkouts of all packaging branches by default.
– I outsourced some of the packaging settings to pkg-project-neon-tools so changing the build environment will be easier in the future when necessary.

If you have questions or just want to tell us how you are using Project Neon feel free to leave us a note on IRC in

Project Neon


Btrfs in natty

After having followed the btrfs features and implementation progress for a while and following the btrfs integration done in natty I wanted to see how far the filesystem has progressed so far.

Note that while I consider btrfs usable, it’s still experimental and has it’s issues, so don’t cry if you don’t have backups of your data! (I do). It’s also a good idea to subscribe to the linux-btrfs malining list and join

Cool things:


One of the main points that attracted me to btrfs was the transparent compression, since that’s something what most other linux filesystems are missing.

Btrfs has supported gzip as compression for a while and 2.6.38 added lzo support to it (the mount option is compress=lzo), so I went and tried both.
The results were pretty much as I had read on the net: Phoronix, LWN.
Lzo uses almost no cpu time here and does give some space improvements, so unless you need the CPU time, I would probably use it by default wherever possible.
In the end I settled with gzip/zlib compression on both my EeePC 1000H and my Thinkpad T510. It does make the EeePC a bit slower a bit but I’m happy to have more disk space, on my Thinkpad it’s barely noticible.

One currently annoying thing is that you can’t really recompress data on an uncompressed FS once you mount it with compress. It should be possible with the defrag command, but that’s currently a bit tricky to use. This affects the installation process, as ubiquity doesn’t let you specify custom mount options, thankfully someone had a workaround for that already which is basically letting ubiquity run the partitioning, and once the partition is created, run:

sudo mount -o remount,compress /dev/sda1 /target

and voilá, all data will be compressed during the installation, after that just adjust the mount option in fstab and you’re set.
My Kubuntu 11.04 64-bit installation used only 1.6GB disk space after installation. 🙂


Really cool feature, esp. since I never really got around learning how to use LVM, ubiquity doesn’t support LVM, and in natty some work was done to integrate snapshotting into apt so we’ll have the possiblity to roll-back upgrades sometime in the future! Main point there is that ubiquity creates a @ (root) and @home subvolume by default if you choose btrfs for root in the advanced partitioning dialog in natty.

Using that, creating a snapshot of root is pretty trivial:

sudo mount /dev/sda1 /mnt

sudo btrfs subvolume snapshot /mnt/@ /mnt/@_snap

mounting /dev/sda1 without a subvol= option will mount the actual FS, so you can see the root subolume that’s usually invisible. Now you create a snapshot of root – @_snap – which behaves like any other subvolume except that it shares data with @.

Now while that is easy, actually using the new subvolume as root and throwing the changes to @ away took me a few trashed VMs to figure out, so here goes:

sudo mount /dev/sda1 /mnt

edit /mnt/@_snap/etc/fstab so it mounts @_snap as /,

reboot and change the kernel entry at the grub prompt so it uses the kernel and initramfs from @_snap, and set it to use @_snap as root. Once you’ve booted run

sudo update-grub

which will make sure grub.cfg now has the kernel entries from @_snap, now run

sudo grub-install /dev/sda

If you forget to do that, grub’s $prefix will stll show to (hd0,msdos1)/@/boot/grub, which we don’t want (see blow).
Now you can get rid of your old rootfs if you want to free some disk space:

sudo btrfs subvolume delete /mnt/@

now, if you didn’t run grub-install, $prefix would point still point to the deleted subvolume resulting in a “file not found” error and a grub rescue> prompt, so don’t forget that. (It’s what happened to me at least)

So, while making a snapshot is easy, you should know what you do if you plan to actually use it. The integration with update-manager and grub is planned to be improved in oneiric so this will get easier.

Some (currently) not so cool things (that you should know):


the btrfsck utility that’s currently shipped is pretty much useless, as it can’t actually fix any errors it finds, only report them. Also, it runs really slow on boot (8s on my thinkpad, 30 on my EeePC), so you usually want to delete the /sbin/fsck.btrfs symlink. A working btrfsck has been promised for a long time, though in February someone said the release is imminent, let’s hope for the best.


while btrfs supports TRIM, you don’t really want to use it currently, there’s a bug that resulted in every fsync() call taking over a second on my system. Now consider that dpkg calls fsync() several times per package and you can imagine the performance.


grub2 in natty doesn’t have lzo support, so you don’t want to use that for root currently without a seperate boot partition.


while btrfs already has some defragmentation support, the command only runs on files, not directories, so you need some shell magic to defragment the whole FS.

Launchpad bug 774217

not the fault of btrfs but it bit me on my eeePC when Installed without a boot partition.


Btrfs Homepage