When "justified" is not justified

While using Microsoft Office, "justified" alignment is not properly implemented.

System-wide accessible gems

As I was configuring my system for my friend's rails project, I found that when I install gems are root, they are available only to the root user and system-wide. When I install something as root, I expect it to be accessible system-wide. So, I dug into the issue and found that it was happening so because /etc/gemrc was configured to install gems for root user only. Getting system-wide installation of gems was achieved by commenting out the following line in /etc/gemrc

gem: --user-install

Now, instead of getting installed in /root/.gem/ruby/1.9.1/gems/ gems were installed to /usr/lib/ruby/gems/1.9.1/gems/ and were available to all users. Previously installed gems had to be uninstalled and re-installed so that they were available to all users.

Boot message: Unable to register miscdev on minor = 130

On my new Arch linux installation I was getting a line saying "Unable to register miscdev on minor=130 (err=-16)". In /var/log/errors.log, I was getting the following lines:

Mar 28 19:37:16 localhost kernel: [13926.292770] watchdog: error registering /dev/watchdog (err=-16).
Mar 28 19:37:16 localhost kernel: [13926.292771] mei: unable to register watchdog device.

A comment on Archlinux forum clarified that it was caused because the kernel supports only one watchdog. The solution is two blacklist MEI driver. That can be done using the following line.

echo blacklist mei > /etc/modprobe.d/mei.conf

You read more about IMEI here.

Reusing packages from one system in building a new one

While installing Arch linux on my new Dell Latitude, I wanted to reuse packages on my existing Arch installation on my old laptop. As soon as I was through with the initial install using the net install image, I put all packages from /var/cache/pacman/pkg to a folder called repo on a USB stick. From the command line I mounted the usb stick on my new installation to /mnt/usb.

mount -t vfat /dev/sdb1 /mnt/usb
 
Now, all I had to do was to tell pacman to look for packages in the repo folder in the USB stick. I achieved this by setting CacheDir variable in pacman.conf to /mnt/usb/repo.

#DBPath      = /var/lib/pacman/
CacheDir    = /mnt/usb/repo/
LogFile     = /var/log/pacman.log

Actually, you can also try creating a local repo. It is there in the pacman manual pages. However, this seemed easier and faster to me and worked on first go.

After this setting, when I tried installing Xorg it told me that there is no extra.db and community.db; but I had those repos enabled and therefore it failed. I realized only core.db existed in my system and I had not synced the repo databases even once. I could have achieved that by pacman -Syu; but for my internet connection to work I needed to install wvdial and usb_modeswitch as I use a 3G USB internet card. So, I just copied extra.db and community.db from my old system into the new one and things worked fine.

Partial upgrade messed my system

Although I am aware of the potential risks of a partial upgrade, due to slow connection I thought I will go ahead with it. I was feeling confident that if things mess up I will be able to handle them. I had installed grep and udev without installing upgraded versions of kmod and pcre.

When I restarted [may be I should not have done that], during boot only the system started throwing errors about grep being unable to find libpcre and kmod not being found. I was able to boot into kdm but my keyboard and touchpad were not working. The root of the problem is still unknown; but I thought of trying installing pcre and kmod. However, to install I had to get to the command prompt at least.

So, I created a Gentoo boot disk using my flash drive and chrooted into my system. I connect using 3G USB dongle and from the chrooted environment the mode was not switched. So, I had to get packages downloaded separately and then install them through the chrooted environment. I should have installed the same version as in my system's pacman database; but I installed the latest one. With that I fixed the boot problems and my keyboard was working but it broke a few other things and kdm did not work any more. When I booted now, it took me to the command line. I reinstalled kdebase-workspace; yet the issue persisted. To make things worse, I found that emacs and irssi were also not working. So, I couldn't get to any IRC channel to ask for help. The only good thing that happened was I was able to get to a command line. So, I did not have to download packages elsewhere and install it.

 When I connected to the internet from my system and ran pacman -Syu it showed me downloads of around 650 mb. I found that many of those packages like libreoffice and 32-bit libs are not absolute necessity from a repair perspective. So, I decided to download a small subset to get my KDE back. I downloaded

• avahi 
• ca-certificates 
• compositeproto 
• cpio 
• kdelibs 
• kactivities 
• libxrandr 
• xdg-utils 
• qt  
• oxygen-icons 
• kdepimlibs 
• kdepim-runtime 
• libxml2 
• libqalculate  
• libxcomposite 
• libmysqlclient 
• libvorbis 
• libshout 
• sdl_image 
• zvbi 
• vlc

 The list above is a subset of the packages pacman wanted to download for the system upgrade; but at the same time they also form a superset of the packages I believed could cause my KDM issues.This solved my problem and now I am blogging from my revived linux system.


Caution:
Experiments like these should not be undertaken unless
1. You are crazy like me.
2. You have a backup system and have your /home folder on a separate partition so that even if your system can't be fixed, you can install a fresh new system without losing data. [You can also save configurations in /etc.]
3. You have sufficient bandwidth.

Cleaning KDE "Open with" list

I had installed MPlayer and uninstalled it long back. However, since then KDE always showed it in the "Open With" list for media files. Just to make sure it was not installed on my system I ran

pacman -Rcus mplayer

as root. Obviously the target was not found. After some chatting on #gentoo, I resolved the issue by deleting mplayer.desktop file from ~/.local/share/applications. Along with that, I cleaned some other stale applications from that directory.

Alarming state of linux distributions

A random peek at Distrowatch showed me that the top linux distributions were all losing popularity.

Does this mean linux is losing popularity or some rarely known distribution is gaining prominence in the background?

New Blogger ate my blog post

I had written a blog about Ubuntu's decline and posted it about 8 hours ago. I wanted to edit it to put some lines in unordered list format. I selected the lines and clicked on the bullet button and it took an additional line under the bullet format. So I pressed Ctrl+Z to undo it. However, to my surprise, the whole blog post was deleted. The contents are gone and not recoverable any more. I also checked Google cache; but it was not there obviously as it was only some hours old.

Speeding up KDM

For some time, I have been noticing that KDE Display Manager (KDM) slows down after every version bump. I was of the idea that this was because KDE was becoming bloated. However, CPU usage of KDE had started declining after version 4.4. So, I was sure that KDE was actually not getting hung up in the background any more. However, till 4.7 the KDM load time kept increasing. As a matter of fact, after the recent update, KDM became so slow that I had to restart my system twice before actually getting to KDM. In fact, during the first two restarts, I was thinking that my installation was broken after the update.


I sometimes browse through the bugzilla to check over recent bugs to find if any of them are related to me. After the update, I decided to look up bugzilla to check if I am encountering a common problem. And, Bingo! The very first bug was about KDM slowing down. There was a suggestion about updating font cache to avoid slow startup of KDM. It can be done using the following command:


fc-cache -fv


I tried it and the next time KDM was loaded very fast indeed. The bug was closed by the Arch linux maintainer with the following comment: "Some font package (maybe unofficial) doesn't run fc-cache after its installation or its removal." However, I think a deeper investigation should be made before closing the bug. I have been a number of instances in Arch linux bugzilla when the bug is closed without sufficient investigation. Arch developers pass the buck to upstream developers very fast.