This is the tale of my attempts, eventually successful, to setup Mythbuntu on a newly purchased HP slimline desktop s5280t.

Hardware

This is the decription of the machine: it's HP Slimline s5300. It comes with a quad-core CPU, 6GB of RAM and 640GB, but that doesn't matter for MythTV. What matters is the following list of devices:

• Tuner card: Hauppauge WinTV-HVR1255
• Remote control: TSGH-IR01 (the IR receiver plugs into the tuner card in what looks like a simple jack)
• Video Card: Nvidia G210 with HDMI
• Samsung LCD TV with DVI input (among others)

Setup

The initial Mythbuntu setup was uneventful. I installed Karmic from scratch without issue.

During installation, a few MythTV setup screens are proposed to do the initial configuration (tuner card, SchedulesDirect subsciption, channel lineup, ...). That went equally well except for the remote control:  none of the devices in the list matched mine.

Anyways, the setup completed and I could start MythTV. I must say I was pleasantly surprised, the UI came up and using the keyboard, I could actually "watch TV". There were a few annoying details, like the size of the UI that doesn't exactly match the size of the TV screen and a very slim noise band at the top of the image on 4:3 channels. But the major issues were of different kind:

• no sound
• no remote

Sound problem

The image comes from the video card through the HDMI port and I was hoping the sound would come out of the analog sound output of the computer and to the analog sound input of the TV. That's how it was working on my previous MythTV installation (Gentoo + Acer machine). The DVI input of the TV is supposed to work in concert with the analog sound input right next to it, but in this case it didn't: strangely, sound is coming out of the analog sound port but the TV ignores it.

After a little digging, I found that the TV can actually receive sound through HDMI. At least that's what it tells the video card when it sends its firmware signature (EDID) to the video card. The video card, naive as it is, believes it and replies to the TV that it's going to do just that. The TV is happy, it turns off the analog sound input and listens on HDMI.

Unfortunately, that's all too sophisticated for the Nvidia driver of the video card (version 185 by default by I also tried 190 to no avail). The nvidia driver doesn't know how to process sound coming from the motherboard. But it does know how to send sound to the TV and that's what it does, it sends an all blank soundtrack  to the TV.

The solution is on this page: Converting analog sound to HDMI. It consists in modifying the EDID information submitted by the TV and remove the bits about receiving sound through HDMI. The updated EDID must then be saved into xorg.conf. The video card will subsequently read the EDID from there instead of getting it from the TV and will stop telling the TV that sound is coming through HDMI which will cause the TV to listen on the analog input.

That worked like a charm for me (after a couple of reboots).

Remote troubles

Hauppauge 1250 IR receiver

The remote control that HP sent with the computer is designed for Windows Media Center Edition which led me to believe it fell into the "mceusb" category of remotes that can be used with LIRC and MythTV. But I was mistaken, the IR receiver is not a USB device, instead it plugs in directly into the tuner card (Hauppauge 1250).

Again, the issue here is with too recent hardware and outdated drivers: the driver for the Hauppauge tuner card doesn't recognize the IR receiver and completely ignores it. There's no fix as of yet. That's too bad because this remote control looked pretty solid compared to all the remotes that can be bought online.

The full explanation can be found on MythTV wiki.

USB Remote Control

I then went to buy that wireless PC remote I found on Amazon. It seemed standard enough and I was hoping I could use the other remote described above on the new IR receiver. It didn't work as planned. The first thing that is supposed to happen when plugging in a USB IR receiver is to have LIRC detect the device (should show up in dmesg) and that should be immediately followed by the device appearing under /dev with the name /dev/lirc0.

I got LIRC to detect something:

Nov 22 14:18:35 ibiza kernel: [   15.507820] lirc_dev: IR Remote Control driver registered, major 61
Nov 22 14:18:35 ibiza kernel: [   15.592792] lirc_mceusb: Windows Media Center Edition USB IR Transceiver driver for LIRC 1.90
Nov 22 14:18:35 ibiza kernel: [   15.592826] usbcore: registered new interface driver lirc_mceusb

but nothing showed up as /dev/lirc0. The testing LIRC tool 'irw' was not mute, some garbage got printed but not at all what's supposed to be printed.

In fact, even though LIRC didn't recognize the IR receiver, I could use the remote to do some basic operations: the up, down, left and right keys were doing exactly what is expected from the arrow keys of a regular keyboard. So I could use it to do the most basic navigation operations on the MythTV menus. Interesting but not good enough.

After lots of googling, I finally realized that the remote was in fact recognized as a keyboard and a mouse by the system. That's bad news because that means I won't be able to use the other remote with that receiver. Anyways, this is called an HID remote and LIRC has a driver for that, it's called "devinput". That Archlinux wiki page has the lircd.conf file to be used with such a device. I found only later that dmesg was showing the HID device:

Nov 22 16:48:42 ibiza kernel: [    3.247892] input: HID 073a:2230 as /devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input3
Nov 22 16:48:42 ibiza kernel: [    3.247957] generic-usb 0003:073A:2230.0001: input,hidraw0: USB HID v1.10 Keyboard [HID 073a:2230] on usb-0000:00:1d.1-1/input0
Nov 22 16:48:42 ibiza kernel: [    3.247968] usbcore: registered new interface driver usbhid
Nov 22 16:48:42 ibiza kernel: [    3.247970] usbhid: v2.6:USB HID core driver

First you have to find under which name the device was mapped:

# ll /dev/input/by-id/
0 lrwxrwxrwx 1 root root 9 Nov 22 14:18 usb-073a_2230-event-mouse -> ../event6
0 lrwxrwxrwx 1 root root 9 Nov 22 14:18 usb-073a_2230-mouse -> ../mouse2

Or you can just list all the "event" devices:

# cat /proc/bus/input/devices 
...
I: Bus=0003 Vendor=073a Product=2230 Version=0110
N: Name="HID 073a:2230"
P: Phys=usb-0000:00:1d.1-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input6
U: Uniq=
H: Handlers=kbd mouse1 event6
B: EV=10001f
B: KEY=837fff002c3027 bf00444400000000 fffffffffffff 10c040a27c007 ffa67bfad941dfff febeffdfffefffff fffffffffffffffe
B: REL=343
B: ABS=100030000
B: MSC=10
...

Knowing the /dev/input /event number you can then test it with:

lircd -n -d /dev/input/event6 -H dev/input lircd.conf  

Create a /usr/share/lirc/remotes/hid/lircd.conf.hid file with the data from the Archlinux page and update /etc/lirc/lircd.conf with that patch. Also update /etc/lirc/hardware.conf with the device name (/dev/input/event6) and driver name (devinput).

MythTV will now work with the remote.

No post in a long time but it's not that I've been lazy. In fact, I've been working hard. Here's what I have been doing, hopefully, some of you will find this useful.

For a long time, I have been updating my ubuntu machines through the update-manager or aptitude. Both tools naturally show the list of packages that are updated and I immediately proceed to start the update. But an hour later, I would ask myself, what the hell just got updated? And I know of no tools that can give me a straight answer to that question.

So I decided to take things into my own hands and I developed a website to track changes in Ubuntu distributions. This website is called www.ubuntuupdates.org.

The main page has the list of all package updates per release, most recent first, the emergency level of the change, the repository where it was released and the description of what changed. That list is updated hourly.

Each package also has its own page that includes
- description of the package
- version history
- changelog
- bugs fixes for each new version

If you're interested in finding stats on the number of updates per day, check out the dashboard.

You can also search for any package and see what the latest version available in each release and what repository it's leaving in (main, universe, multiverse, backports).

Again it's www.ubuntuupdates.org. Enjoy!
 

Since Jaunty was released, most computers with Intel GPU have suffered from dismall video performances. It's not only about videos, it's also about browsing the web with Firefox, scrolling through pages is slow, sometimes blocks, and compiz effects suffer from occasional flashes.

This fix is for the AAO D150 which is equipped with Intel 945GM.

# lspci  | grep 945
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I tried several things. I started experimenting with the instructions at Jaunty Intel Graphics Performances Guide (safe solution) but it didn't help, if anything it got worse.

Then I reverted to the regular driver (aptitude was of great help here, I used "aptitude remove xserver-xorg-video-intel" and it kindly offered me to downgrade to the regular jaunty version instead of completely removing the package).

I found that page that explains how to revert to version 2.4 of the driver.  The instructions in the article work just fine and after restarting X, the video performances are back to normal. In short:

Add to /etc/apt-sources.list:

deb http://ppa.launchpad.net/siretart/ppa/ubuntu jaunty main

Add the server key:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xce90d8983e731f79

Install the 2.4 package:

sudo aptitude install xserver-xorg-video-intel-2.4

Restart X and you're done.

Important update: The official Firefox-3.5 is now available in the universe repositories. You don't need to do any of the following, just "apt-get install firefox-3.5". No need for any ubuntu-mozilla-* line in /etc/apt/sources.list.

To uninstall firefox-3.5 that was setup using ubuntu-mozilla-*, follow the removal instructions below.

After digging around a little bit more, I found that there was another, safer, repository for Jaunty with firefox 3.5: ubuntu-mozilla-security.

For those of you who don't want the daily updates of firefox, which will deliver experimental releases on occasions, you should use the security repository instead of ubuntu-mozilla-daily.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7EBC211F

Add the following line at the bottom of /etc/apt/sources.list:
deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu jaunty main

sudo apt-get update
sudo apt-get install firefox-3.5 firefox-3.5-gnome-support

If had already installed firefox-3.5 from the daily repository and you want to switch to the security one, you first need to remove the ubuntu-mozilla-daily line from /etc/apt/sources.list and remove firefox-3.5 that came from that repository:

sudo apt-get remove firefox-3.5 xulrunner-1.9.1-gnome-support xulrunner-1.9.1

Only after that you should run "apt-get install firefox-3.5 firefox-3.5-gnome-support ".

Important update: The official Firefox-3.5 is now available in the universe repositories. You don't need to do any of the following, just "apt-get install firefox-3.5". No need for any ubuntu-mozilla-* line in /etc/apt/sources.list.

To uninstall firefox-3.5 that was setup using ubuntu-mozilla-*, follow the instructions at ubuntu-mozilla-security.

Only follow the instructions below if you want to be on the bleeding edge.

Firefox 3.5 was officially released yesterday and it brings significant improvements in terms of speed, tab management and support of HTML5. Ubuntu does not automatically propose the upgrade so you need to help the system find the newer packages. Let's start by listing the least effective ways of getting those packages.

Installing from Canonical repositories

When searching inside of Synaptic Package Manager or using apt-cache, you are going to find firefox-3.5. Unfortunately, it's been there since the release of Jaunty and it has not been updated since then. At the moment, only the beta 4 for is available and believe me you don't want it.

$ apt-cache showpkg firefox-3.5
Package: firefox-3.5
Versions:
3.5~b4~hg20090330r24021+nobinonly-0ubuntu1 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_jaunty_universe_binary-i386_Packages)
 Description Language:
                 File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_jaunty_universe_binary-i386_Packages
                  MD5: b670b07084b5a79b912d14c4307acda4

Installing from mozilla.org

That's a better option. The process is the following:

1. download the .tar.bz2 file
2. uncompress it under ~/firefox
3. make sure no other instance is already running
4. start firefox 3.5 by running "~/firefox/firefox"

It works fine but there are several problems with this approach:

• It completely shortcircuits the package manager which means that you will have to install future updates independently of the rest of the system.
• When Ubuntu gets upgraded, it's very likely this firefox installation will stop working as it depends on libraries that will have changed version.
• This firefox installation will the same ~/.mozilla directory to store your personal settings as the Ubuntu version of Firefox (3.0.11 as of today). Confusion and pain will inevitably follow. Unfortunately the last installation option described below has that same disadvantage.

Now the better solution.

Setting up the ubuntu-mozilla-daily repository

You can add to your system a repository maintained by the mozilla developers.

Add the following line at the bottom of /etc/apt/sources.list:

deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main

Let Ubuntu know the identification key of this repository:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 247510BE

Refresh your system cache:

sudo apt-get update

Now, same as with the first option, the package that you want is firefox-3.5. The difference is that now, the version available is the right one.

$ apt-cache showpkg firefox-3.5
Package: firefox-3.5
Versions:
3.5.1~hg20090629r26036+nobinonly-0ubuntu2~umd1~jaunty (/var/lib/apt/lists/ppa.launchpad.net_ubuntu-mozilla-daily_ppa_ubuntu_dists_jaunty_main_binary-i386_Packages)
 Description Language:
                 File: /var/lib/apt/lists/ppa.launchpad.net_ubuntu-mozilla-daily_ppa_ubuntu_dists_jaunty_main_binary-i386_Packages
                  MD5: b670b07084b5a79b912d14c4307acda4

You need to setup this package, latex-xft-fonts and also firefox-3.5-gnome-support

$ apt-get install firefox-3.5 firefox-3.5-gnome-support latex-xft-fonts

At this point, there are 2 different versions of Firefox coexisting on the system, 3.0.11 and 3.5.1. When you run "firefox" from the command line or when you select it from the Applications menu, version 3.0.11 is fired up. It might be convenient to make the newer version the default:

$ sudo su
$ cd /usr/bin
$ ll firefox*
lrwxrwxrwx 1 root root 11 2009-06-22 16:45 firefox -> firefox-3.0
lrwxrwxrwx 1 root root 32 2009-06-22 16:45 firefox-3.0 -> ../lib/firefox-3.0.11/firefox.sh
lrwxrwxrwx 1 root root 34 2009-07-01 21:17 firefox-3.5 -> ../lib/firefox-3.5.1pre/firefox.sh
$ rm firefox
$ ln -s firefox-3.5 firefox

The newly installed version is branded "Shiretoko". That's the name used to identify 3.5 during development.

By using this technique, you're guaranteed that Firefox will get updated regularly through the Ubuntu package manager and that compatibility with system libraries will be preserved.

The downside of this is that you will get a little more updates than the average users: fixes to 3.5 will be dropped here first before they are made available to all. As a consequence, it's not impossible that you will be among the first to find regression bugs.

Reference: http://www.asoftsite.org/s9y/archives/160-FAQ-Where-can-I-get-firefox-3.5-for-Ubuntu.html

Update 7/3/2009: safer ubuntu-mozilla-security repository?

Using an SD card to run Ubuntu

The Acer Aspire One 110 is notorious for its small and sluggish SSD disk (SSDPAMM0008G1EA). Firefox is so slow it seems web pages will never finish loading and you'd better not be in a hurry when starting the package manager or setiing up Ubuntu updates. I wanted to find a solution that wouldn't involve tearing the motherboard apart and I found one. It cost me about $40 and a couple of hours of work.

The idea is to use a fast SD card as the primary drive of the laptop by installing Ubuntu on it, the SSD becomes an extra storage device. As you will see below, the SD card shows more balanced performances than the SSD and significantly faster write speeds.

I chose to buy the Transcend 16 GB SDHC Class 6 memory card. Note that it is sold with an USB adapter that comes very handy when installing the OS on the AAO.

Setup

There is just one problem with the setup: the bios on the Acer Aspire One is unable to boot from the SD card. That means that you can't just setup Ubuntu on it and restart. The workaround is to let the laptop boot from the SSD: the bios reads the MBR and starts grub on the SSD. The initrd kernel image is also on the SSD and that kernel is capable of mounting the SD card. Only after this is done can the regular boot process resume and the actual kernel get loaded from the SD card.

I followed the very good installation instructions I found on osnews.com. They are very detailed, I followed them point by point and I didn't run into any issue. Here is a slightly modified list of steps that goes straight to the point:

• Install Ubuntu on the SSD if it's not already there. In my case it was there so I could skip that step. I found the version of linux present on the SSD doesn't really matter, it will just be used for its /boot directory and grub.
• Boot from a USB drive where you can Install Ubuntu from. I used the 9.04 alternate CD. I had plugged it in the USB slot on the right of the AAO and I had the SD card in the USB adapter  on the left of the AAO. It might be possible to just stick the SD card directly on the left SD slot on the left, I think the 9.04 install USB key would be able to find it but I haven't tried and you will need the adapter on step 4 anyway.
• Proceed with the actual installation to the SD card from the USB drive.
• Reboot from the newly installed SD card (inside the USB adapter: there's no way around this for this step). Mount the old SSD on /ssd

mount -t ext2 /dev/sda1 /ssd

• Now you must reconfigure how initrd.img files are generated. The goal here is to include support for the SD card reader in the initrd. Without it, you won't be able to access the card from grub. Edit /etc/initramfs-tools/modules on the SSD card and add those 4 lines:

mmc_core
mmc_block
sdhci
sdhci-pci 

• Regenerate the latest initrd kernel image and copy it inside of the SSD /boot directory.

update-initramfs -u 
cp /boot/initrd.img-2.6.28-12-generic /ssd/boot

• Edit /ssd/boot/grub/menu.lst on the SSD drive. There you will create a grub menu entry that points at a kernel on the SD card. Replace the UUID below with yours.

title           Ubuntu 9.04, kernel 2.6.28-12-generic-SDCard
uuid            5ce02d2f-1fee-4cc5-8c7d-bde5f19b26b8
kernel          /boot/vmlinuz-2.6.28-12-generic root=UUID=5ce02d2f-1fee-4cc5-8c7d-bde5f19b26b8 ro elevator=noop quiet splash
initrd          /boot/initrd.img-2.6.28-12-generic
quiet

Note that the UUID on the "kernel" line is the UUID of the SD card. So in the /boot directory of the SD card, there must be a vmlinuz file that matches the initrd file from the SSD card.

That's it, you can reboot one last time, select  "Ubuntu 9.04, kernel 2.6.28-12-generic-SDCard" from the grub menu and if the gods are with you, you will load the OS from the SD card. At this point you will enjoy an Ubuntu setup that will feel twice as fast as the old one with 3 times more storage space.

Beware: anytime you get a new kernel, by default it's only installed on the SD card but you need it on the SSD drive. So don't forget to copy the new initrd.img to /ssd/boot and to update /ssd/boot/grub/menu.lst whenever needed or you won't be able to use the new kernel.

Disk performance measures

Now that is just a feeling at this point. Here is how to back it with concrete numbers. I found the dd test page very helpful for this experiment. One can easily measure the disk  read speed with hdparm but that ells you nothing about the write speed.

$ hdparm -tT /dev/mmcblk0p1

/dev/mmcblk0p1:
 Timing cached reads:   1144 MB in  2.00 seconds = 572.07 MB/sec
 Timing buffered disk reads:   40 MB in  3.16 seconds =  12.67 MB/sec

So the best way to get both read and write speed is the following:

To measure the sequential write speed, write a large file to disk while measuring the time it takes. Note that the sync command is essential to guarantee all the data gets written instead of staying in some cache. Do not trust the throughput reported by dd, instead divide the size of the file by the duration reported by "time". For example, here is the test on the SD card (it generates a 160 MB file):

$ time sh -c "dd if=/dev/zero of=ddfile count=20000 bs=8k && sync"

20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 13.4757 s, 12.2 MB/s

real    0m18.885s
user    0m0.020s
sys     0m0.640s

To measure the read speed, read the same large file from disk:

$ time dd if=ddfile of=/dev/null bs=8k                
20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 9.96247 s, 16.4 MB/s

real    0m9.974s
user    0m0.016s
sys     0m0.588s

I ran that test on the SD card, on the SSD and on another Acer Aspire One  (AOA 150) with a regular hard disk.

As you can see although the SD read speed is just 60% of the SSD read speed, the write speed is almost 4 times higher on the SD card and for normal usage of a laptop that write speed increase changes everything. It worked so well, I decided to use Gnome on this machine and it appears to go twice as fast as Xfce was going on the SSD. Not that the Acer Apire One got magically turned into a Ferrari but with that SD card, it became a pretty decent Toyota!

Since Jaunty, when Firefox is displayed in full screen (F11), any of the following actions will result in Firefox disappearing for a second and the background desktop image replacing it:

• right click
• alt-tab
• hovering over a link with a tool tip

That happens if compiz is in use and I verified the problem both on machines using Intel and Nvidia video cards.

The fix is easy:

• go to System -> Preferences -> CompizConfig Settings Manager -> General
• uncheck "Unredirect Fullscreen Windows"

I ran into a major issue after upgrading an old Acer Aspire One netbook running Xubuntu to Jaunty. It makes Xfce unusable especially if you have to login/logout or reboot frequently. Fortunately, there is a workaround.

Symptoms

• The xfce desktiop takes minutes to initialize after the login windows. As I login and logout a few more times, the delay increases and goes over an hour.
• Similar symptom when running the update-manager. Starting it up takes minutes/hours, the download and installation of new packages is equally slow and finishing up updates (when update-manager reloads it database) feels like it will never end.
• While I'm waiting the HD light stays solid green. Running pidstat while update-manager is working shows a high number of xfdesktop processes, very high IO activity, crazy context switching and reduced available memory.

Causes

• The Aspire One disk is extyremely slow, any swapping will make the machine slow to a crawl. That's an aggravating factor.
• But what seem to cause the issue is that I have configures Xfce to "Save sessions" on exit. Apparently that causes the same processes (including xfdesktop) to be opened 2x, 4x and more every time an xfce session is started. After a bunch of restarts, the number of started applications is just too high and the AAO can't keep up.

Workaround

In  Xcfe "System Settings"/"Session and Startup", uncheck  "Automatically save sessions on logout". And in the logout confirmation window, be sure to uncheck the "Save sessions" checkbox.

A bug has been filed in launchpad precisely on that problem and it suggests a workaround: Multiple instances of xfdesktop started simultaneously

rm -rf ~/.cache/sessions
rm -rf ~/.config/xfce4/desktop

Then logout and login again. The problem should go away.

For situations where no graphical interface is available or when a remote installation is needed, the command-line distribution upgrade tool of Ubuntu can come very handy.  First you need to make sure the update-manager-core package is present (it probably already is)

sudo apt-get install update-manager-core

Then all you need to do is run

sudo do-release-upgrade

If this command is run from an ssh session I highly recommend to run it inside of screen so that the upgrade won't stop in the middle of nowehere when the ssh connection is lost. And be sure that the ssh connection will be lost at some point during the installation of the packages.

When you get back physical access to the computer, go to the console, 'screen -r' to get the upgrade prompt and answer the questions it still needs an answer for.

Note that this is NOT the recommended way for upgrades. In my case, after getting access back to the computer, towards the end of the installation the display went completely black with no way of recovering it and I had to blindly reboot the machine assuming the upgrade was finished. It turned out the upgrade did actually succeed but I might just have been lucky.

Note: this was tested for the intrepid to jaunty upgrade.

Thanks to sysblogd and lair.moria.org for pointing me into the right direction.

I started installing Jaunty on my computers 2 weeks ago. The first one to get the honor was a new Acer Aspire One. For this one as for the other ones, the install went flawlessly:

• the installer shrunk the windows partition automatically
• wireless was working after install (except on the all Aspire One with the Atheros interface. Not resolved yet because of lack of time but it appears a solution exists: https://bugs.launchpad.net/ubuntu/+bug/350352)
• graphics with 3D compiz effects were all working now using the 180.44 driver that got installed seamlessly.

After the initial  install, I had some troubles...

Troubles with Ext 4

No trouble with ext4 on the new AA1, the conversion worked, nothing to complain about.

It was a very different story on a Dell laptop of mine. The conversion to ext4 succeeded there too, the machine rebooted fine after the conversion, but then I read a post about the need to append  "rootfstype=ext4" to the kernel line in /boot/grub/menu.lst. I decided to go for it. Big mistake.

Now, that was a really stupid idea. I can't say for sure that's what broke it but in any case, the machine would not reboot after that, it would only go to grub console.

I tried reinstalling grub several times:

• boot with a live CD (I used a Jaunty live USB pen that I had)
• go to the grub prompt by simply typing "grub"
• root (hd0, 5)
• setup (hd0)

That rewrites the MBR with a brand new grub (supposedly supporting ext4 since it's 9.04). That didn't help. It wouldn't go past the grub console on startup. No error message is shown. The console sees the partitions, it even sees the files on the partition I want to boot from but it would not boot from it. Trying to 'cat' a file from grub shows only garbage.

I also tried to repair the partition table just in case (using systemrescuecd and Test-Disk). Nothing would help.

Fortunately, when booting from a live CD, I was able to mount the partition where I had my home directory so I could back it all up. I finally resolved to reinstall the system entirely with a full disk repartitioning and reformatting and I restored the home directory from the backup. That all went fine. I had lost a crazy amount of time on that issue though. So my recommendation is to not add that "rootfstype=ext4" to menu.lst. At best it will change nothing, at worst it's going to kill your installation.

Boot time

I measured the boot time before and after the upgrade and reinstallation on that Dell laptop. The startup time is measured between grub and the gdm login page:

• Intrepid: 52s
• Jaunty after upgrade still using ext3 on the main partition: 46s
• Jaunty after upgrade after the ext4 conversion: 46s
• Jaunty after full reinstall from scratch (using ext3): 36s

So, that's not quite what the hype tells us it is, it's merely an 11% boot time improvement from Intrepid to Jaunty and ext4 does not make any difference.

ATI, fglrx and xorg 1.6

Jaunty comes with xorg 1.6 and ATI has not released a unix driver yet that supports it. As a result, 9.04 does use the open source driver called just "ati" on machines using ATI video cards. I was a little reluctant to upgrade on an old desktop with an ATI card because of that. I'm not a Quake player but I didn't want to lose the compiz effects.

But it the end, this open source driver works wonders, the 3D effects appeared just as smooth as on intrepid and the CPU usage actually appeared lower while playing videos. I don't think I will swittch back to the ATI fglrx proprietary driver!