geek + red sox + cooking = peter ryan

At some point after I completed my Feisty to Gutsy upgrade I discovered that whenever I ran a perl module (whether it was when I was reinstalling vmware or running aptitude) I received the following warning:


perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


I ran across the following ubuntu forum thread and executed the following two commands to clean up the broken locale:


sudo locale-gen
sudo dpkg-reconfigure locales


That resolved the issue and the perl warnings disappeared when I ran aptitude again as a smoke test. I am not sure what could have caused this corruption as the thread is dated. The issue might not be gutsy upgrade related but it is likely the culprit as I have done little on my machine in terms of config changes beyond it.

I completed the upgrade from feisty fawn (4.10) to gutsy gibbon (7.10) over the weekend. There were a few issues - the upgrade hung during the installation of a package and I had to resume it manually using dpkg. This was not really much of a big deal - the same thing happened when I upgraded from edgy.

However today I was sliding my mouse over the KDE Power Manager and I noticed that the CPU Frequency only displayed one processor. Given my Dell D620 came equipped with a duo core processor I took immediate notice. Inspecting /proc/cpuinfo revealed the issue wasn’t with the PowerManager but rather in the CPU detection being performed by the kernel.

It turned out that during the upgrade a 386 kernel was installed and made the default. The 386 kernel lacks duo support (I believe) based on a few things I read on the topic. I rebooted into the generic kernel and the Power Manager displayed the two processors.

After determining that was the problem I removed the 386 kernel from my system which fixed my system to use the correct generic kernel as that was the next one on the list.

I am not sure why the upgrade process nixed the cpu detection but given the ease of the fix not something I will dwell on much. It could have been caused by my interrupted upgrade, the fact my kernel had been patched for vmware, or something wrong with the upgrade process itself.