Reboot on Dell Latitude E6520 with Arch linux

On Dell Latitude E6520 and some other Latitude models, a number of distributions were having issues with reboot. Rebooting by any method, viz.

• restart command
• shutdown -r now command
• or restart from GUI

stopped all processes. The run level goes to 6 and everything works fine. Finally the system shows a message that it is rebooting now but the reboot does not happen. Ubuntu had this bug too but they fixed it and when my friend tried Ubuntu on the same hardware, reboot worked fine for him. I filed a bug in Arch and discussed it on #archlinux. The developers said it is an upstream issue and I was able to find an already reported bug upstream. Looking into the bugs and comments, I figured I should try setting the kernel parameter 'reboot' to 'pci'. So, I changed the kernel line in /boot/grub/menu.lst to include 'reboot' parameter as follows.

kernel /boot/vmlinuz26 root=/dev/sda2 resume=/dev/sda1 ro reboot=pci


After the above change, my system rebooted successfully.


N.B.: 1. Here, /dev/sda2 is my root partition and /dev/sda1 is my swap partition.
         2. Read more about rebooting a system.

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.

Bootcharting Gentoo baselayout 2

In this post I shall share my experience of yet another Gentoo installation. I keep coming back to this distribution for its stability, wonderful package management and the experiencing fine grained control.

I have been using KDE for over six years now. I wanted to try GNOME 3. However, as I found out GNOME 3 is not yet stabilized in Gentoo so I had to be content with GNOME 2. They are stabilization by the next release. I believe that it for good reason. Well GNOME 3 does not support Compiz. There are no multiple timezone clocks.

Having prior experience in installing Gentoo linux, I knew that following the handbook strictly you have to wait for downloads while there is compilation going on and vice versa. So this time I chrooted not from a single terminal but from multiple terminals. I could run package downloads separately using

emerge -f <package name>

and compile concurrently on a different terminal using

emerge <different package>

After installation, when I booted the system hung up.

Hung up Gentoo bootscreen

I read a line saying

Ext3-fs: couldn't mount because of unsupported optional features(240)

Adding the following to the kernel line solved the issue.

rootfstype=ext4

However, I was still getting a hung up system. If I inserted or removed USB drives, I was getting appropriate messages printed on screen; but the system was not responding to any keystrokes or mouse, neither was it loading X. Only the error line was gone. So, I understood that it was not the filesystem issue that was causing it. Asking on #gentoo I found that it was a common issue caused by the switch to baselayout 2. Instead of old init scripts Gentoo had started using openRC. Last time  heard about it was about a couple of years ago. It was a nice project started by Roy Marples. However, now it was stable and I was happy to be using it. My issue was solved following Alex's suggestions for the issue.

I wanted to see the boot time with baselayout 2 and openRC so after I had other installations I did a boot chart to find much faster boot than my previous installation on the same machine.

Also noteworthy was the fact that X worked out of the box and I was surprised to see Firefox 3.6.17 in stable tree. I was expecting Firefox 4.0. Well I hope it is stabilized soon.

Removal of hal improves boot time

I upgraded my kernel to 2.6.37, removed hal and KDE to 4.6 and experience improved boot times now.

Bootchart on Archlinux

After switching to Arch linux, I thought of charting boot time. I found it to be faster than Gentoo and openSUSE.

Improving boot time on Gentoo

Continuing with my attempts at reducing boot time on my Gentoo x86_64 running desktop, I tried switching off interactive boot and booted in about 20 seconds.

To improve booting, I tried prelinking. However, to my surprise it increased boot time.

Slower boot on newer kernels

Recently, I upgraded my kernel on my Gentoo x86 and patched my kernel on openSUSE 11.1 x86_64. I found both booted slower than when I charted booting last time, earlier this year.

The increase in boot-time was more in case of openSUSE compared to Gentoo.

Adventure of a Gentoo install

My first Gentoo install was on an x86 laptop. It worked fine. I wouldn't say it was a piece of cake as I would say for a SuSE install. However, it was pretty much close. I was trying to get the GUI installer to work but realized gradually that it was broken and I should try my hands on the command line. After few years of linux experience, I wasn't scared of the shell. The install completed fine. I successfully configured a dual boot system. I liked Gentoo's performance and ease of tweaking. So, I decided to try Gentoo on my old desktop at home.

Now that I am enjoying vacation at home, I decided to embark on the Gentoo installation adventure (I wont be calling it an adventure, were it not in retrospection.). Recently, the desktop was upgraded to an core 2 duo processor (E7200). So, I thought of giving the amd64 version a shot. I started from the command line. Everything went fine till the grub installation. I configured my bsnl broadband to work with it. I shall write about it in my next post.

The minimal install cd kernel showed the partitions as /dev/hdbx (x being the numbers differentiating partitions). So following the instructions of the handbook, I decided that hdb7, my root partition which contained /boot folder (I do not use a separate /boot partition.) translates to (hd1,6) in grub terminology. I created grub.conf with hdb7 as root and tried install grub with root on (hd1,6). However, I was surprised when an error message told me that no such device existed. I cross checked the handbook and found I was doing as it said. I decided to get some expert opinions on this. So, I switched another virtual terminal and fired up irssi. I talked to people in the #gentoo channel. They also confirmed that I was doing fine and I didn't get any reason for such behaviour. Then I was suggested to try grub-install. I thought lets give it a shot. There were more surprises to come. The device map showed the following translations.
/dev/fd0 -->> (fd0)
/dev/hdb -->> (hd0)
/dev/sda -->> (hd1)
/dev/sdb -->> (hd2)
I reported back at #gentoo and people there were surprised too. I thought I should try in #grub channel as well.

After joining the channel, I read the channel topic. They were basically focusing on grub 2. After confirming that I could about previous grub versions, I put forth my situation. They told me that the device map isn't much predictable as it depends on the BIOS. They also told me that grub is designed such that almost always the device from which the system can boot is (hd0), as happened with me: grub-install made the / partition as (hd0) as it was going to boot from it.

Now that I had understood why and how grub was translating my partitions, (unlike as described in the Gentoo handbook,) I edited my grub.conf to reflect the changes and installed grub manually. After successful install, I was happy to see the splash image and multi-boot options; but the adventure was far from over.

First, I checked if my windows partition was okay. It was relieving to find that it was perfectly alright. Then rebooted again to resume my adventure and headed straight into the next hurdle. I started my newly installed Gentoo system only to run into a kernel panic. The error message came from VFS telling me that it could not find the root partition /dev/hdb7. The first thought that came to my mind was: probably I was right in the beginning in suspecting about the success of the install when I saw hdb instead of sdb. My doubt was based on the fact that irrespective the disk drive being ATA or SATA, newer kernels use to refer to them as /dev/sdx, where x is a letter differentiating drives. The kernel panic message also told me that I should try with /dev/sdxN format. The reason I had not done it before was because I trusted the live cd kernel's behaviour. As the minimal install cd was burnt from an iso generated by the latest autobuild, I did not think that the live cd kernel would be outdated or behave like an outdated one. I checked at #gentoo and was advised to file a bug (my first bug report) after double checking.

I used the minimal install cd again and chrooted to my root partition. I editted my grub.conf and fstab to suit newer kernels' format. After a reboot, I was happy to have successfully installed Gentoo.

sreadahead on gentoo

Sometime back I also tried sreadahead on Gentoo. Here are the results.

I didn't find much difference. According to a bug assigned to Gentoo developer, Jeremy Olexa not much success haas yet been met in this area: the upstream developers don't seem to be making much progress either.

Fine tuning boot on openSUSE 11.1

Recently, I have been trying to fine tune my bootup process. I installed sreadahead from openSUSE build service. I also installed mkinitrd, aaa_base, bootchart, udev, and sysvinit from the devel:playground:fastboot repository. Here is the result.

The disk usage is more frequent but bootup time increased. Also I found that while shutdown the drives could not be umounted properly and my system time was configured to UTC instead of IST.

Next I installed module-init-tools, libvolumeid1, sysconfig, glib2, glib2-devel from that repo and tested. Here are the results.

The disk utilization has improved. Another observation was uniformity in CPU utilization. Earlier it used to be heavy at some periods, and nearly no CPU utilization rest of the time.

Next I have tried installing gconf2, gconf2-devel, gvfs, gvfs-backends, gvfs-fuse, kbd, libbonobo, libbonobo-devel, libgio, libgio-fam, libglib, libgmodule, libgobject, libgthread, libgvfscommon and xorg-x11-driver-video.

Bootchart on opensuse 11.1

After my trials on my Gentoo system, I wanted to chart out the bootup of my opensuse system.

Opensuse has parallel boot by default. It is interesting to see that out of the box, without any tweaking it is one of the fastest booting systems.

Improving on bootchart

From the the bootcharts I posted in my previous post, it is obvious that sleep times could be eliminated to bet better boot up performance. So I thought of looking at boot messages to find processes that I could do away with or at least do something about. During boot-up, the boot process was looking for ethernet connection, i.e. it was trying to bring up net.eth0. As internet wasn't always connected, it was waiting longer when started with no connection. So I created an offline runlevel and added a new entry in /boot/grub/menu.lst. The procedure is described well in the Gentoo handbook. Here is what I got: a reduction of about 30 seconds in boot-up time.

Bootchart on Gentoo

Recently I tried to chart out my system's boot-up. I got bootchart on my new Gentoo. Then I added a line to my menu.lst as described at the bootchart site and rebooted to test my boot-up. Here is what I got.

I read little more about it and found that I can turn on RC_PARALLEL_STARTUP in /etc/conf.d/rc to get slight improvement in speed. I read that in the comments of the rc file. It was also suggested that I should turn on RC_VERBOSE. So I did it. I got a five seconds increase.

Here is the output of uname -a (I have cut out unnecessary parts like system time)
Linux 2.6.27-gentoo-r8 #1 SMP i686
Intel(R) Core(TM) Duo CPU T2300 @ 1.66GHz

Here is the bootchart with a scheduled filesystem check.