Probably, this may works with other distributions, kernel versions and other systems, but I’m not going to do any further test.

Recently, a friend of mine asked me to install a new hard drive on his Sony Vaio laptop, because he ran out of free space on the original drive.

So after buying and installing a new 160GB drive, I began with the setup of Windows XP SP3. Anyway I left some free space for Linux.

Setting up Windows was quite easy, but setting up Linux, was a real nightmare.

I tried 4 differents x86 Ubuntu’s CDs (8.04 live, 8.10 live & alternate, 9.04 alternate). They all had the same problem: kernel hanged during startup. The strange thing about that was that by pressing a key (any key), kernel startup process moved forward of a single step, and, keypress after keypress, after 10 or more minutes, the OS was completely loaded!

I tried with OpenSuSE 11.1 live CD. There were less problems during startup, but the matter still remained the same: the OS required several keypresses to boot. After installing to disk, nothing changed.

Now, I’m not an expert, but thinking about that, I supposed there was a problem with interrupts or system clock or both, so after looking for solutions on Google, I found someone writing about the boot parameter “clocksource”.

To know clocksources available on my system, I wrote:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

on a terminal, and got:

tsc acpi_pm jiffies

Firstly I tried adding “clocksource=acpi_pm” in /boot/grub/menu.lst but, at the following boot, nothing changed.

Then I tried with “clocksource=jiffies“: that actually works!

The system boot up quite rapidly and without the need of any keypress.

Hope this article could help someone who is hitting a wall with his head trying to install Linux on this laptop.

Bye

This is a post taken from an old unused blog of mine. Many things have changed, but this article could be useful for distributions that still use the “classical” ( /dev/sda1 or /dev/hda1 ) way to refer to mass storage devices.

Having some spare time, I decided do some jobs on Mirage.
Apart from Solaris 9 that is unused by months on the Samsung 20GB IDE drive, I decided to reinstall Debian 4.0 on the Fujitsu 18GB SCSI drive that was initially placed inside the Sun 599 box.
Version 4.0 is the last one that allow installing a working dektop environment. Version 5.0 with the “new” 2.6.26 kernel doesn’t correctly start X.org, while Debian 4.0 works flawlessly.
Just to try something new, I decided to go for XFCE as default desktop environment instead of Gnome.
Installation was perfect, but at the first reboot, the system halted on the message:

Begin: mounting root file system

Obviously, there are some problems in mouting /, /boot, /usr and other filesystems…
Pressing

[STOP]+[A]

take me to the OpenBoot prompt where using

reset-all

I restart the system, this time giving more attention to the kernel messages.
During boot, kernel finds the Samsung IDE drive, the two 9GB IBM SCSI drives inside the Sun 599, the Plextor SCSI CD drive and, finally, the Fujitsu SCSI drive.
Ok, so, if the two IBM drives are /dev/sda and /dev/sdb respectively and the Plextor CD drive is /dev/sdc, then the Fujitsu drive must be /dev/sdd.

Obviously the system hangs on the same message, as before.
Once started BusyBox, the emergency shell

mkdir temp

followed by

mount /dev/sdd1 /temp

Some warnings, but it mount the file system. With

ls /temp

I can read the files in /boot. 

 An immediate check to the silo.conf file shows me

root=/dev/sdc4

So, in a moment

vi /temp/silo.conf

the “wrong” parameter is modified.

At the next boot… the system hangs always on the same message.

Uhm… probably (ehm, that means, “for sure”) I mounted the file system read-only from BusyBox.
Looking at the file, I actually haven’t modified it.

At the next boot, at the SILO prompt I type

help

and SILO tells me that I can define a root device using

root=/dev/$device

So I try

linux root=/dev/sdd4

and finally boot goes on, even if it stops for another less important reason.

The next question is easy to solve. It simply try to mount /dev/sdc4 as /.

mkdir temp
mount /dev/sdd4 /temp
vi /temp/etc/fstab

Just the time of changing every reference of /dev/sdc to /dev/sdd and rebooting and…
Voilà! Everything goes right and within a minute I’m able to login in gdm.

Okay… and now there is a problem bigger than a house.
The CD-ROM drive IS NOT /dev/sdc.

And so, what?

What the Hell is “stealing” a SCSI drive designation?

… SUSPENCE …

The “thief” is a 128MB USB flash drive, to which the kernel assigns the designation /dev/sda.
Obiviously, removing that drive means that the system hangs on finding the root file system…
Changing silo.conf and /etc/fstab to use the original /dev/sdc  make the system bootable without the USB drive inserted, but of course with the drive inserted the system is unable to boot.

The title of this article came from a message the Debian installer wrtites at the end of the process:
“The Silo bootloader results installed. The system should now be bootable.”

[UPDATE – PROBLEM SOLVED]

After asking some friends and doing some search I’ve found many interesting things (like how useful udev can be)… that haven’t helped me figuring out how to solve this problem.
The BIG idea come from a friend’s laptop on which I recently installed OpenSUSE 11.1. This Linux distribution uniquely identify a disk using an id. To access a mass storage device, instead of using the classical

/dev/sdxn

where x is the letter used to identify the physical disk device and n is the number identifying the partition, uses

/dev/disk/by-id/scsi-SFUJITSU_MAN3184MC_JADDAJADDAJADDA-partn

where JADDAJADDAJADDA is the device serial number and n is always the partition number.
This way to identify the various devices has been introduced in kernel 2.6 and newer.

Modifying silo.conf and /etc/fstab accordingly Mirage is now bootable even with more USB devices attached.
A minor “collateral damage” is that the system disk can be designated in various different ways depending on the number of external disks connected, but until now this has caused no problems.

Bye