Oneiric first drive

Ok, I finally got a few minutes to start testing Oneiric Beta 1 on my HP Elitebook 8440p.  Since it is the computer that I use on my daily job, I preferred to launch it using a USB key and not to jeopardize my Natty’s working installation.

It is not by lack of faith toward my fellow developers, but rather because I would hate to be unable to serve our customers following known bugs being applied to my gear. So here are my first thought. I will follow up by visiting the “known bug” section to see if the things that I encountered have already been fixed.

And since I’m using a live USB setup, my first test is on the packages found on the Beta1 DVD image. I didn’t get to run an update to get fresher packages yet.


My first great pleasure is to realize that I no longer have to rely on the Nvidia proprietary drivers to get started. Of course, I only get access to Unity 2D, but at least I have an environment that is very similar to the 3D version (I really can’t see the difference). But I’m not a big user of animations and things like that. Another great thing is that I only had to go to the “Display” section, activate my second 19″ screen, put the appropriate screen definition and the second display started to work.

One thing though : the Dash menu which used to appear on the far left of the leftmost screen in Natty (normal behavior) now appears on the left of the laptop’s screen (my 2nd screen is at the left of the laptop) so the Dash selection area is in the middle of my workspace.


Wireless works out of the box, but this is nothing new. Same with the built-in webcam. As I already indicated, Dual-screen is also working out of the box, but apparently without the 3D acceleration.

User Interface

The first thing I noticed after typing the “Super” key and typing “term” to get a CLI environment is that, after hitting <TAB> to select the terminal Icon, I no longer have a graphical return (i.e. the icon doesn’t get highlighted). It still seems to work as if I hit <Return>, the terminal does get launched. Maybe a side effect of using Unity 2D.

As with the Dash menu, the lens do appear on the right screen (laptop screen) unlike with Natty. One thing that is no longer working is the workspace switcher. Clicking on it in the Dash does display all four workspaces, but when I select any workspace, it always brings me back to the first one. Might be some wrong setup.


So far, I have had a few crashes (software library, Compiz manager) but most things seem to work. The software library crashes have forced me to drop back to CLI to get things installed. UbuntuOne works flawlessly

It is now time to go back to my daytime job, which is fixing our customer’s  problems. Hopefully, I’ll have some more time to explore Oneiric before it ships out. But I really like my first impression.

Publié dans Ubuntu Desktop | Laisser un commentaire

Live from my phone

The fun of being a geek is to find silly things to do, like to try to blog from an Android phone.

Well, using the power of the open source (wordpress & Android) looks like it will be easier then expected (aside from the virtual keyboard that makes typing a bit tedious).

Kind of nice…


Publié dans Fun, Technical | Laisser un commentaire

Remember that day ?

Not that it is very a original post, but it was 20 years ago.

Linus Benedict Torvalds
View profile
More options Aug 26 1991, 8:12 am

Hello everybody out there using minix –

I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I’d like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I’ll get something practical within a few months, and
I’d like to know what features most people would want. Any suggestions
are welcome, but I won’t promise I’ll implement them 🙂

Linus (torva…

PS. Yes – it’s free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that’s all I have :-(.

Publié dans Technical | Laisser un commentaire

My very own little wiki

Having a linux based distribution as the operating system on my laptop has many advantages.  One of them is to be able to easily run an apache instance and use my laptop as a local webserver.  This has allowed me to run my very own private mediawiki instance on my laptop and to use it as a note keeping engine.  So the landing page on my web browser looks like this :

Two main advantages of this is that, if I intend to publish some of my notes as a public wiki page, there is minimal effort involved in migrating the data to a public Wiki. Otherwise, I can use the search function to find information on a specific topic, see if I have done things on that subject, etc.

It has been a very useful tool to me and I thought I’d share that experience.

Publié dans Technical, Ubuntu Desktop | Un commentaire

When technology simply works…

In my job as a support engineer, I spend my day trying to fix problem. So it is refreshing when, sometimes, the technology that we’re providing simply works.

Like this morning when I decided to test a total autonomous laptop setup. By that I mean that I will on the road tonight and might need internet access for m y laptop.  So I went ahead and configured my Android HTC Desire to act as a WiFi Hotspot.  Then I switched my laptop’s Wireless connection to the SSID that was broadcast by my phone; it connected right away.

Now since I’ll be in a car, I need to have some kind of headset to avoid street noises. So I powered my bluetooth  earphone that I had previously configured to be recognized by my laptop. I went in the notification area and selected the Bluetooth applet & saw that my earphone was been seen. So I connected it.  Now the only thing that doesn’t totally work as I would expect is that I needed to change the whole sound setup of my laptop to send all input and output to my earphone. I’m expecting to use Twinkle for phone calls, and it is the only way I found to have the earphone work properly. If someone knows how to be more selective and have Twinkle use the Bluetooth earphone, I’m a taker.

But this is not a show stopper.  So I fired up Twinkle, connected to my SIP account and dialed my home phone : Drriiiinngg!!!

So I’m there, with my Android phone connecting me to the Internet, my laptop acting as a telephone, while I still have full laptop functionality. I must say that I’m impressed. Don’t get me wrong : I’ve been using Ubuntu since Hoary, and Debian before that.  But nowaday, with all the great work done on those tools, it make rather complex setups work smoothly.

Bravo !

Publié dans Ubuntu Desktop | Marqué avec | Un commentaire

A new journey with Canonical

As many around me know, I have recently moved to a new job with Canonical.  This journey started quite funnily on April 18th by a Support Sprint event in our Montréal’s office. I say funnily because, while I now lives in France, near Versailles, I was born in northern Québec and I have lived in Montréal for three years before moving to France.

This Sprint week was a great occasion to meet with my new colleagues and to jumpstart my exposure to my new job by learning as much as I could about Natty, both on server and desktop with those responsible for providing top class support to our customers.  But most of all, it was an occasion to meet face to face, to interact with colleagues, learn to know them and understand a bit more about the context of how things are done at Canonical.

Then a little while after coming back home, I got that email from Jono Bacon, encouraging us to do more blogging. Talk about a cultural shock ! For years, I pushed myself into maintaining an internal blog at my prior job, worrying about the possibility that it would be seen as a waste of my time by some manager.  I even seen a few occurrences where very good “internal” bloggers were forced to abandon their blogging activities because of some politically incorrect statement that did not please some high ranking manager.  So being encouraged to go out on the open and talk about what I do, how it is to work here at Canonical, how I think I can help improve our customer’s experience did made my day.

So why did it took me so long to react, to start writing ? Call it paranoia, historical worries, I don’t know. I also wanted to take the opportunity to take out some of the english posts out of my french speaking blog, which required some reworking of my own personal WordPress infrastructure.  But that’s all done now. It’s time to go ahead and start sharing how it is like to “really” be a part of the Open Source effort.

Publié dans Canonical | Laisser un commentaire

crashdc : going Beta

That’s it ! crashdc is now officially beta software.

I just uploaded the 0.6-1 bits on the server which will be the official first fully functional release.

I’m also doing a presentation at Solution Linux 2010 tomorrow at 2pm.

So go ahead and download, test and bring back your results.

Publié dans crashdc | Laisser un commentaire

An example of crashdc output

Quick post to tell you that I have uploaded an example of the output that crashdc produces. It is using the newly developped BASIC mode (output from an ADVANCED mode is too big to post here).

You can view it here :

Publié dans crashdc | Laisser un commentaire

crashdc : An update

It’s been a while since I haven’t posted about crashdc.  Not that nothing happened, just that I didn’t get to it.

First of all, the development tree is now public and you can see it here :

I had to wait for my employer to allow me to contribute crashdc to the public so it took a little while to get done. During that process, I had to produce architectural diagrams that might be of some interest so I am posting them here.

For instance, this diagram shows how crashdc fits into a normal system installed and configured with kdump.  This is the automated way of using crashdc which can also be invoked from the command line.

Architectural diagram of crashdc

Architectural diagram of crashdc

In this one, you will find a high level flowchart of crashdc’s functionalities.

crashdc's flowchart

crashdc's flowchart

It highlights how crashdc works internally.

Currently, the specifics of the command lists (using built-in or custom list) is not implemented. I’m finishing testing of crashdc on all delivered kernels of RHEL5, SLES10 and SLES11 on both i386 and x86_64 before going into this.

Hopefully, I will have something close to ‘beta’ flavor by end of february if my daytime work allows for it. I’ll keep you posted.

Publié dans crashdc | 2 commentaires

crashdc : The architecture

So you might want to know more about how crashdc is organized.  Well here are a few pointers.

crashdc is a shell script that is called from a kdump mechanism which is triggered when a vmcore dump file gets created. The file it creates is named crash-data-{date}.txt Unfortunately (for me), this mechanism is different in all three implementation that crashdc supports :

  • RHEL5   : kdump_post

It can also be run interactively on an existing vmcore to generate the crash-data-{date}.txt file afterward.

I will try to go in a little more details about each of the automated mechanisms. But it is important to know that crashdc itself is identical for all three distributions. The only thing that changes is the run-crashdc-{distro}.sh shell that is executed by each one of those mechanisms.

RHEL5’s kdump_post

This is the most straightforward. When uncommented, the kdump_post variable in /etc/sysconfig/kdump is setup to run the /var/crash/script/ script. This script is in fact a symlink to /usr/bin/ which takes charge of finding vmcore’s location, and to invoke crashdc.

SLES10’s implementation is more complex. When KDUMP_TRANSFER is defined, the command it invokes becomes responsible for reading vmcore’s data out of /proc/vmcore and to store in in a file. Otherwise, it is the save_core shell function from /etc/init.d/kdump that does that.

So /usr/bin/ has an identical copy of the save_core function (yes I copied it) that will copy the vmcore file. The rest of the script does the same thing than for RHEL5, which is to invoke crashdc with the appropriate parameters.

Once again, SLES11’s implementation is different.  When invoked from witihin the kexec environment, the script pointed to by KDUMP_POSTSCRIPT runs in an environment where the / file system is memory resident, and the real disk-based / file system is mounted in /root.  So the /usr/bin/ knows all so it is still able to invoke crashdc correctly.

Those three mechanisms are all KDUMP specific handles. This mean that they run right after a kernel panic, when the KDUMP kernel is running and before a reboot has been done.

Post Reboot processing
Some system administrators might not like the idea that unnecessary processing is done in that context. This is why one last script has been developped : /etc/init.d/crashdc This script can be used when the system reboots to its regular environment to generate the crash-data-{date}.txt file.

With this method, the crash-data-{date}.txt will only get created when the system reboots on the regular kernel.  The current limitation is that it will only process the latest vmcore created in order to avoid extra processing in case of multiple kernel panics.  Yet, there should be an option to manually process all vmcores where crash-data-{date}.txt has not been found.

Right now, this script only exists in my mind so there are chances that it might evolve quite a lot before it gets done.

So I hope that this brief post is clear enough to highlight the main mechanisms used by crashdc.

Publié dans crashdc | Laisser un commentaire