Ubuntu Maverick Meerkat (10.10) … an update

Those that follow my blog may be aware that I have been trying out the upcoming Ubuntu release, Maverick Meerkat, since Alpha 1. With the Beta release just around the corner, as can be seen in the Release Schedule, I figured it is time for an update.

This Ubuntu release has been running, IMHO, very stable since the Alpha 1. Although I am very well aware that breakage is part of these early releases I have never been without a working release since I started trying this release. Besides the issue with the Intel graphics driver which forced me to use the bleeding edge Xorg initially, as indicated in my earlier referenced blog post, I have always had a working environment.

Somewhere between the Alpha 2 and Alpha 3 release I switched back from the bleeding edge Xorg to the “default” Ubuntu environment and since then I have a working Xorg with the regular Ubuntu Xorg as well. So that issue seems to have been fixed, at least for my graphics card.

Surely there have been issues … a KernelOops error in the 2.6.35-16 kernel but that was encountered quickly. If I can believe what was written in the related bug report, #620810, even fixed by Linus himself:

Marking as triaged due to the level of upstream knowledge of this bug already (Linus posted a patch himself)

Are there any noticable and visual changes? Not really, at least not to my knowledge. What I have noticed is a visual change in the Software Center. It now does have a “Featured” and “What’s New” section that refreshes ever so often. Plus there are some “pshychedelic” orange spots added to the background.

Maverick - Software Center and Background

Of course there are also changes not so visable. More information about that can be found on the Ubuntu Wiki. And, as can be expected there are also some issues to be ironed out. The ones that I have encountered myself are only few. Besides the earlier mentioned KernelOops error I have noticed that lshw, a lightweight hardware information gui, does freeze my computer as described in bug #614008.

Additionally there is an issue with the PolicyKit. Everytime you want to shutdown or restart you computer it is “blocked” by the fact that the Policykit is not responding.

Maverick - Policykit Error

This has also been identified, see bug #623819, and is hopefully sorted out before the Beta release.

UPDATE Aug, 31, 2010: Yesterday’s upgrade fixed the above issue.

Concluding: This release has in general been running steady since the Alpha 1 release and has not caused — yet — any severe breakages resulting in a non functioning environment. It’s performance, even on a nowadays considered low memory system as I have (only 512 Mb), is IMHO very good and it is very efficient on using these resources.

Although this is not an LTS release I have had fewer issues with this release than I have (had) with the official LTS release which is the current release (Lucid Lynx). I am looking forward to seeing this release go into Beta and into it’s final version. For now it is the “production release” on my desktop.

A new location

Why?

Why the move to a new location? Ah well, it’s my holiday and the weather gives a feeling that autumn really has come early this year. So what else can you do …. ;)

Nah … that is not the main reason. The main reason is that the location on which I used to have my blog is closing down. I could elaborate on this, but the owner explained it very well on his own blog in his post: “LxH is closing down“.

Once I heard about this I was faced with the decision to either also move my blog or to discontinue it all together. Well, I guess the outcome of that decision is clear by now. I decided to move the entire blog, which I must say was quite an easy process thanks to the “import-export” facility of the WordPress Blog software. Even attachments (images and so on) where transferred from the old to the new location.

One thing that could not be transferred was the theme I used. I have settled for the K2-Lite theme for now, but this may change further down the road. Firstly I simply wanted to have the blog up and running again. So don’t panic if all may look different when you visit next time.  :D

And now?

Like the owner of LxH I also have been struggling with time and priorities and every once in a while you simply have to sit back and review whether you have them all correct. That is also why the number of blog posts I make can vary quite a lot. Sometimes I just have more spare time on my hands than in other periods.

Basically with the move that will not change. When I have time and/or when I think I have something to blog about I will continue to do so. Basically still driven by the same as I was when my blog was hosted at LxH.

Thanks to LxH

I do want to make use of this opportunity to thank Rich and all other “hardcore” members for the past period. It has been educational in many ways. Learned a lot about Linux, got to know some new people with which I really hope to stay in touch and in the process have tried to, albeit a little, give back to the Linux community at the same time.

To my readers

To all that have visited me at my “old” home and to all that are visiting me at my new location. I do hope that you still are able to find what you were looking for. I will try and continue to inform you with my experiences and hopefully it will be useful to you all.

Anyway … thanks for visiting!

VMware Remote Console (VMRC) on Fedora 13

In my blog post about using VMware Server 2.0.2 on Fedora 13 I indicated the issues that I had with getting the console working in the web interface. Which may very well be a Firefox issue since I encountered the same with Ubuntu. One of the workarounds was to only use the web interface for setting certain items (like permissions) or creating new VMs and use the VMRC to run the VMs. I figured that if this works for Ubuntu, it should also work for Fedora. This blog post is about how I got the VMRC working in Fedora 13.

The script to start the remote console, start-VMware-console.sh, came with the patch that is required to install VMware Server 2.0.2 however … it did not work for me (neither in Ubuntu nor in Fedora). So as a basis I started out with the modified script I used for Ubuntu (see my comment on the Ubuntu blog post).

One issue I ran into was the fact that permissions were not set correctly for several files to enable the use of the VMRC. To set these, you need to find the directory where the files are located. Easiest way to do this is by means of the following command (due to the “strange named” subdirectory) in a terminal:

find "$HOME/.mozilla/firefox" -name vmware-vmrc -type f | tail -1

Next go to the plugins directory, which is the result of the above command until the text “vmware-vmrc”, by means of the cd command. In this directory are several files that start with vmware but that are not (yet) executable. Change these to executable with the command:

chmod 755 vmware-*

Now go into the subdirectory lib (cd ./lib) and change the permissions of the wrapper files with the command:

chmod 755 wrappr-*

Now go back into the plugins directory (cd ..) and make all files in the bin directory executable with the command:

chmod -R 744 ./bin/

Finally the script to start the VMRC needed to be altered. Find below a copy of the script that I use now:

#!/bin/bash
################################################## #############################
#
# Call VMWare Server's Remote Console in a clean GTK setup.
################################################## #############################
#

# Clean GTK setup for VMWare

export VMWARE_USE_SHIPPED_GTK=yes
export GDK_NATIVE_WINDOWS=true

# Find console executable in Firefox plugins.
vmrc="$(find "$HOME/.mozilla/firefox" -name vmware-vmrc -type f | tail -1)"
[ -x "$vmrc" ] || exit 1

VMLIB=$(dirname "$vmrc")
VMLIB=$(dirname "$VMLIB")/lib

export  LD_LIBRARY_PATH=$VMLIB/libexpat.so.0:$VMLIB/libsexymm.so.2
:$VMLIB/libview.so.2:$VMLIB/libvmwarebase.so.0
:$VMLIB/libvmwareui.so.0:$VMLIB/libgvmom.so.0:$VMLIB/libsexy.so.2

set -x
cd "$(dirname "$vmrc")" && "$vmrc" -h localhost:8333

NOTE: I have added some breaks in the “export LD_LIBRARY_PATH” statement to make the entire line visible. These may need to be removed to get a proper working script.

Now you can start the VMRC using the above script or — and that is what I did — create a new item on the panel to start the script. When you start the VMRC the first thing you need to do is login and connect.

Fedora 13 - VMRC - Connect

Once you are connected you can choose from the VMs that you have available. In my case there is just one.

Fedora 13 - VMRC - Choose VM

When you click the “Open” button the VM will start up (if not yet started) and the console will appear.

Fedora 13 - VMRC - Running VM

The menu items are quite self explanatory and by using the VMRC I worked around the entire issue currently caused by the fact that for some reason the console does not allow to connect in the latest Firefox version (3.6 and beyond).

Next Page »


Categories

My recent tweets