Nautilus 3.6 is inane

I haven’t posted here for a while. Usually because my google searches turn up the answers pretty quickly, so I don’t feel the need to add anything additional via this blog.

Nautilus 3.6 on 13.04 is inane! They have gotten rid of drop down menus as far as I can tell.

While trying to figure out how to connect to a file share via the file explorer – a completely reasonable and supposedly simple task – I discovered that it was no longer easily possible on the 13.04 file explorer. I lot of hunting and I finally discovered a post that gave me the magic keyboard combination in order to open a file location dialog: CTRL-L.

Once I had this is was relatively easily to connect to the remote server I wanted. After that right-click add bookmark is your friend.

It’s really stupid when the backend can still do things, but the power of the front end is reduced.

Edit: Sigh… It is worse that I thought. Dropping tree view is a particularly egregious crime.

Comments off

Lucid libvirt

Lucid does not seem to work well with libvirt/kvm, there are several bugs that seem to be fixed in Maverick but not in Lucid.

From syslog:

error : qemuSetupCgroup:1955 : Unable to create cgroup for DOMAIN: No such file or directory
error : qemuRemoveCgroup:2045 : internal error Unable to find cgroup for DOMAIN#012

Re: [libvirt] FYI, “Unable to create cgroup for …”

This is a bug in systemd. It periodically scans all mounted cgroups
and deletes any directories which don’t contain any attached processes.
Needless to say this breaks libvirt, and possibly other apps, which
don’t expect 3rd parties to be deleting their directories.

https://bugzilla.redhat.com/show_bug.cgi?id=678555

Best solution for this that I’ve found on lucid is: Bug 696218 – Unable to create cgroup: No such file or directory

I was able to solve it by modifying the configuration in the file
/etc/libvirt/qemu.conf:

 cgroup_controllers = [ ]

setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu

=== modified file 'apparmor.d/abstractions/libvirt-qemu'
--- apparmor.d/abstractions/libvirt-qemu 2010-04-30 15:33:20 +0000
+++ apparmor.d/abstractions/libvirt-qemu 2010-05-12 17:26:56 +0000
@@ -8,6 +8,8 @@
   capability dac_override,
   capability dac_read_search,
   capability chown,
+ capability setgid,
+ capability setuid,

Libvirt/kvm permissions/ownership issue on upgrade from Karmic to Lucid and error: operation failed: failed to retrieve chardev info in qemu with ‘indev’

libvirtError: internal error unable to start guest: libvir: QEMU
error : cannot set ownership

or

 error: operation failed: failed to retrieve chardev info in qemu with 'indev'

Add the following to /etc/libvirt/qemu.conf:

# The user ID for QEMU processes run by the system instance
#user = "libvirt-qemu"
user = "root"

# The group ID for QEMU processes run by the system instance
group = "kvm"

map serial port throws “chardev: opening backend “tty” failed”

There seems to be a problem with the apparmor profile of libvirt (see bug #54579). After adding the line to /etc/apparmor.d/abstractions/libvirt-qemu and reloading the profile it worked for me.

/dev/ttyS* rw,

Few other links:

Comments off

kvm vs qemu-kvm vs kvm-kmod

Ubuntu recently change their package names for kvm.  This comment posted on qemu-0.11.0 Released provides an explanation:

qemu-kvm includes features and fixes from upstream qemu and so takes its naming scheme from upstream qemu. You can think of it as qemu optimized for kvm. Note too that qemu-kvm does not include the kernel module but only the userspace and considered to be stable.

kvm-xx on the other hand is the development branch of kvm and not considered to be stable. It’s naming scheme is arbitrary and it also takes features from upstream qemu.

kvm-kmod is different to kvm-xx. You can think of kvm-kmod as a subset of the kvm-xx. KVM-xx = userspace + kernel where kvm-kmod is the kernel part of it and qemu-kvm is the userspace part (the guest process itself). You can apply the kvm-kmod to any distro version or linux version.. it’s just the kernel driver. However, without the userspace part, you can’t do much with it.

Comments off

Jaunty and md

Not to disrespect Ubuntu, but Jaunty must be the worse release they have made in a long time. Whether it be an unusable desktop because of a poor kernel – upgrading to 2.6.30 is a good idea – or just poor packaging – md overwriting the mdadm.conf file? WTF?  See here and here for the workaround lists, and here to fix the md issue.

Karmic is getting good reviews. Lets hope its an easy upgrade and sets the scene for an amazing 10.4 release.

Comments off

kvm disk performance with different backends

Here  some results from testing I did in August 2009 on  KVM with the three different disk image drivers. First a single disk system running Ubuntu x64 9.04:

Read the rest of this entry »

Comments off

Ubuntu 9.04 Desktop

Just did an install of the 9.04 desktop. Very clean. Intend to do some testing with kvm, virtual box and win4lin.

Comments off

From Professional VMware blog, here is another method to fix your lost Ethernet device on Ubuntu.

Another method of doing this, is to edit the ‘persistent-net-generator.rules’ file to include something similar to:

# ignore VMware virtual interfaces
ATTR{address}==”00:0c:29:*”, GOTO=”persistent_net_generator_end”

Comments off

linux-image-virtual with ESX

According to this thread, if you need to use the linux-image-virtual package on ubuntu then it only supports the “bus logic” scsi controller with ESX.

Comments off

Install Ubuntu via USB

The device pictured is a 16GB SanDisk CruzerUS...
Image via Wikipedia

I tried several methods last night including Unetbootin, and this is the one that worked best.

Basically copy the ISO on the USB root directory, add vmlinuz and initrd.gz from main/installer-i386/current/images/hd-media/. Then add syslinux.cfg with:

default vmlinuz
append initrd=initrd.gz

If you have boot problems you might also need to run install-mbr /dev/sda from the mbr package.

Reblog this post [with Zemanta]

Comments (1)

Ubuntu and djbdns

I keep smacking into this issue. So a couple notes to myself for future reference.

Before install touch /etc/inittab and afterwards add this to /etc/event.d/svscan:

start on runlevel 3
start on runlevel 4
start on runlevel 5

stop on runlevel 0
stop on runlevel 1
stop on runlevel 6

respawn
exec /usr/bin/svscanboot

Comments off