The installer still doesn’t support LVM. To be able to install Ubuntu on my LVM partitions I had to follow the steps described in one of my previous posts.

Previously I installed the i386 bit version of distributions on my laptop although it is a x86_64 system. But this time I went for the amd64 version.

You can check if you really have a 64bit processor by checking if there is a “lm” flag for your processor:
$ cat /proc/cpuinfo | grep lm

Using the 64bit version gave some problems, but they are all fixed now:

thunderbird-lightning

The lightning plugin you can download from the add-ons site of thunderbird is the i386 version which doesn’t work with a x86_64 thunderbird. Ubuntu provides a lightning package but this contains some old version. Luckily you can find the x86_64 xpi here: http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.9/contrib/linux-x86_64/

sun javaws

The sun javaws isn’t available for x86_64. The openJDK version is available but not all java applications work with that Java WebStart. You can manually install the i386 version of sun-java6-bin:
sudo apt-get install ia32-sun-java6-bin
You can now find the working javaws in following directory: /usr/lib/jvm/ia32-java-6-sun-1.6.0.10/bin/javaws

BTW … Fedora 10 will be released in 18 days

One of the big annoyancies I noticed during the installation was that it didn’t recognize my lvm partitions. And I really need that, as my home and root partition are on lvm and I didn’t want to repartition my complete drive.

Luckily I found some explanation for lvm support during the installation. This is the summary of the actions you need to perform.

Become the root user:
ubuntu@ubuntu:~$ sudo -i

Load the dm-mod module:
root@ubuntu:~# modprobe dm-mod

Install the lvm2 package on the live system:
root@ubuntu:~# apt-get install lvm2

Activate the logical volumes of your volumegroup
root@ubuntu:~# lvchange -a y <volgroup name>

At this moment you can perform a normal installation, your existing logical volumes will be recognized and can be used during installation.
After the complete installation process you have to install lvm support for you new installation.

Mount the partitions of your new installation:
root@ubuntu:~# mount /dev/volgroup/root /mnt
root@ubuntu:~# mount /dev/sda1 /mnt/boot
root@ubuntu:~# mount -o bind /dev /mnt/dev

Chroot into your new installation:
root@ubuntu:~# chroot /mnt

Install the lvm2 package:
root@ubuntu:~# apt-get install lvm2

You can now exit your chroot environment and reboot your machine. If everything is OK, you can boot your fresh ubuntu installation.

[johan@laptop ~]$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -nr|head
201 ls
108 ssh
108 cd
98 sh
81 su
29 vi
24 rpm
24 ping
23 rm
20 mv

[johan@workstation ~]$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -nr|head
149 ls
128 cd
125 cvs
93 diff
71 echo
54 ssh
45 for
28 mkdir
26 md5sum
24 reset

My previous post of my Top 10 used commands was more than 1 year ago.

As one of my desktops was still running Fedora 7 it was time to upgrade to the current stable Fedora, Fedora 8.

On the Fedora wiki you can find a list of instructions to upgrade your machine using yum. It will list the general actions but also the execptions for each upgrade.
You can find these instructions here: http://fedoraproject.org/wiki/YumUpgradeFaq

The upgrade went very smooth, but isn’t recommended for non-technical users as it all happens on the command line.
For those non-technical users a graphical user interface which guides you through the complete process would be very handy (Ubuntu has it already, don’t know if it is available in Fedora 8/9).
I prefer the upgrade with yum as I want to know what my machine is doing.

When I started Firefox for the first time everything looked extreme big (user interface and content). This was caused by a bad autodetected dpi setting. Manually changing it to 96dpi solved the problem.
Bug 394103 in the mozilla bugzilla describes the problem and how you can solve it.

Some time later, when I upgraded some packages (including Firefox), i had a problem with the address bar. I could enter the url but pressing enter won’t bring me to the website. Pressing the green arrow on the right side of the url did.
Some upgrades later it still wasn’t fixed, it was even worse. Entering some text in the address bar was impossible and thus making Firefox useless. It was time to find the cause and solve the issue.

Removing and reinstalling the Firefox package didn’t solve it, but it showed there were some problems with xulrunner, a dependency of Firefox. The xulrunner rpm never got installed correctly, it gave following errors during rpm installation:

Error unpacking rpm package xulrunner-1.9-0.beta3.29.nightly20080227.fc9.i386
error: unpacking of archive failed on file /usr/lib/xulrunner-1.9pre/dictionaries: cpio: rename

Searching the Fedora bugzilla for this problem pointed me to bug 433096 which handles this problem. As explained in one of the comments removing and reinstalling xulrunner rpm solved the problem.

I can now enjoy again from my Fedora 9 alpha with Firefox 3 beta!

I’ve recently installed the new Fedora 8, so it is time to check how you can browse you mobile phone with F8.

If you bluetooth adapter is recognized you will see the icon of the “Bluetooth Applet”. Right click on it and you will find the Browse Device… entry. Any bluetooth device in your neighborhood will be listed, choose your phone and connect with it. After pairing (= exchanging passwords for the first time) a Nautilus window will open with the content of your phone.

It is just that easy… That’s really something different than a couple of fedora releases ago.

Thumbs up for the Fedora 8 team!

This problem is explained in the beryl wiki.
The solution is also mentioned there.

Because I’m using java 5 (1.5.0u11 from Sun) the fix is very simple.
I added following line at the end of /etc/bashrc.

export AWT_TOOLKIT=MToolkit

After restarting the X server the java applications works without any problems.

Previously it would do a groupinstall of Base, which results in a total of 300 packages. This is the same amount of packages when it is installed from cd and minimal install is checked.
But this minimal install includes way to much and useless packages like pcmcia, irda, isdn, …
The groupinstall of Core gives a better result. Now only a bit more than 100 packages are installed. Even yum or openssh aren’t installed. So you will have to add some extra packages but at least you’re not stuck with all those unused packages and running services.

The same happens when you kickstart. By default it will install the base and core groups. But again this results in 300 packages. Just mentioning core or not mentioning base in the packages section doesn’t solve the problem.
Luckily there is an, undocumented, option for the packages section. You can pass –nobase if you don’t want to install the complete Base group. But now you will have to mention the Core group or it will install not enough packages.
This is how your packages section in the kickstart file can look like:

% packages --nobase
@ Core
yum
openssh-clients
openssh-server


Fred tested the perl compilation with perlcc together with me. He has summarized the results in his “perl binary”-blog post. At the end he added the pp (Perl Packager) which also compiles perl scripts.

I tested this and at the first sight it worked fine, but at second sight some strange things happened.

The binary I created on my machine (Fedora Core 6) worked fine on my machine but gave a “Floating point exception” on any other machine. When I tested it on an other FC 6 it worked without any problems.
When the binary is created on an other machine it worked on all machines, including mine. I repeated this test with different machines (CentOs, Debian, Suse) and those worked fine. They also worked on the system without perl.

When comparing the binaries compiled on the different system I noticed that libresolv.so.2 shows up in the output of “ldd” only with the FC6 binaries.
When creating a chart of all systems with the check result, I added the glibc version of the system. It appeared that the version differs on the systems. On FC it was a newer version (2.5) then the other hosts (2.3).

I added glibc in my search query on google and I found following warnings on cpan.org:

Linux and other libc-based platforms
* Try to avoid running pp on a bleeding-edge version of the OS
* Older versions with an earlier libc won't work with new ones

This means that perl compilation with pp with the bleading edge version of glibc (2.5) may not work on other systems. If you compile it on a system with a more stable version of glibc, it will work on all systems. (or at least on the systems with the same glibc).

btw: it’s now 20 minutes before the official release which is planned at 14:00 GMT