According to Debians Upgrade instruction and it’s “How to recover” section, the problem can be caused by new naming conventions for IDE disks.

This problem can occur when the upgrade of the kernel introduces the use of the new generation of IDE drivers. The IDE disk naming convention for the old drivers was hda, hdb, hdc, hdd. The new drivers will name the same disks respectively sda, sdb, sdc, sdd. The problem appears when the upgrade does not generate a new /boot/grub/menu.lst file to take the new naming convention into account. During the boot, Grub will pass a system root partition to the kernel that the kernel doesn’t find.

This seems like to be very common reason for these “Waiting for root file system” troubles that many faces now when upgrading to Lenny. But in my case I allready had the new sda* names in the grub/menu.lst and /etc/fstab. The “solution to recover” did not work.

The virtual lenny server with the new kernel images that fails to boot was hosted by VMWare Server 1.0.3. For a nearly the same upgrade process (etch to lenny) hosted on FMWare fusion 2.0.2, I did not have these problems.

Solution: My VMWare Server 1.0.3 was out of date and had a known vmware bug that caused this error. Upgrading to the latest version (now 1.0.8) solved the problem.

http://vmware.com/download/fusion/

Nach dem Konvertieren findet die VM unter VMWare Server nicht mehr das Netzwerk. /etc/network/interfaces ist unter Fusion mit eth0 gelaufen. Unter VMWareServer zeigt die VM mit “ifconfig -a” nur ein eth1 an. Ich habe die also in /etc/interfaces das primary network interface von eth0 auf eht1 geändert. Danach “/etc/ini.d/network restart” und nun läuft es wieder. Muss ich bei Gelegenheit mal genauer schauen, was da schief gelaufen ist – muss wohl irgendwas mit dem vmxnet networking driver sein.

Update: Die VM wurde “geklont” dabei wurde eine neue MAC-Adresse angelegt. Bei Debian ist in der “/etc/udev/rules.d/z25_persistent-net.rules” die alte MAC-Adresse eingetragen. Ich habe die “/etc/udev/rules.d/z25_persistent-net.rules” gelöscht und rebootet. Danach war das interface wieder als eth0 zu verwenden.

Auch andere haben schon vor dem Problem gestanden und versucht die 25 seitige Dokumentation “Timekeeping in VMware Virtual Machines” irgendwie auf das wesentliche zusammenzufassen.

Nach dem Tipp eines befreundeten Admins (Danke Dirk) in die Knowledgebase bei RedHat zu schauen, finde ich dort nur den Weg, den ich zuvor schon versucht hatte. Grob zusammengefasst:

1. Im Gast OS die VMWare-Tools installieren.

2. In der *.vmx Datei den Eintrag
tools.syncTime = “TRUE”
setzen.

3. ntpd im Gast nicht erforderlich aber für den Host empfohlen.

Damit hatte es aber noch nicht geklappt (Gast Uhr läuft extrem hinterher) und ohne den Eintrag “host.useFastClock = FALSE” werde ich mit “rtc: lost some interrupts” im Syslog zugeschmissen.

Also ist eine rasch zu ergoogelnde Lösung nicht in Sicht und ich muss nochmal genauer in die VMWare-Bibel der Zeitsynchronierung schauen. Dort finde ich auf Seite 22 bei Punkt 3, Unterpunkt 3 eine Lösung die für meine Konfiguration (Host = 2.6.18-6-686 #1 SMP mit VMWare Server1.x) funktioniert:

Linux kernel 2.6 guests normally request 1000 PIT 0 timer interrupts per second, plus, in
some cases, 1000 local APIC timer interrupts on each virtual CPU. For single processor guests, you can usually eliminate the unneeded APIC timer interrupts by including the kernel command line flags noapic nolapic nosmp. (All three flags may not be needed, depending on your exact kernel version, but it should be harmless to give all three.)

Aktuelle fahre ich also folgende Kernel Flags für die VM in der grub/menu.lst:
kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda1 ro noapic nolapic nosmp clock=pmtmr
und habe damit eine synchrone Zeit zwischen Host und VM und keinerlei “rtc: lost some interrupts” Meldungen im Syslog mehr.

Wie schön dass es noch immer einen Schalter mehr gibt, den man noch ausprobieren kann… Oder wie schreibt VMWare so schön auf Seite 25: “Conclusion: Timekeeping in virtual machines is a complex subject.”

Unter dem Namen Open Virtual Machine Format (OVF) wird derzeit an einem branchenweiten Standard für virtuelle Maschinen (VM) gearbeitet. Ziel des Standards ist es, dass virtuelle Maschinen unter verschiedenen Virtualisierungsprogrammen unabhängig davon, mit welcher Anwendung sie erstellt wurden, zum Laufen gebracht werden können.

Das ist eine gute Nachricht, denn es sichert die Investitionen, die man in den Aufbau seiner VMs getätigt hat und wird auch Dienste wie Amazons EC2 (basierend auf XEN) noch attraktiver machen. Wäre ein solcher Standard bereits heute verfügbar, könnte ich wohl meine mit VMWare erstellten VMs nach Amazon S3 uploaden und mit EC2 nutzen. Traumhaft.

You can prevent /dev/rtc from being used. This will generally cause clocks to run slow
in any virtual machines you have that need the additional interrupts, but that may be
acceptable to you, depending on your application. To do so, add the following setting to
each virtual machine’s .vmx configuration file, or add the setting globally to the host’s
configuration file (/etc/vmware/config):

host.useFastClock = FALSE

Wenn man diese Zeile im /etc/vmware/config einträgt und vmware neu startet (/etc/init.d/vmware restart), ist man die Einträge im Syslog los.

Hier habe ich eine Lösung gefunden, die als root durchzuführen ist:

1. cd /usr/lib/vmware/lib/libpng12.so.0
2. mv libpng12.so.0 libpng12.so.0.old
3. ln -sf /usr/lib/libpng12.so.0
4. cd ../libgcc_s.so.1
5. mv libgcc_s.so.1 libgcc_s.so.1.old
6. ln -sf /lib/libgcc_s.so.1

Zuvor hatte ich VMWare Server unter Windows 2003 laufen und da gab’s die Probleme nicht. Erst mal dem Umzug meines VMWare Servers auf meinen neuen Ubuntu 6.06 LTS Server gibt’s diese Fehlermeldung. Die Einstellungen der VM sind okay; daran sollte es also nicht liegen. Hmm dachte ich: Papa kennt sich ja aus und regelt das mal schnell, damit die Twins gleich wieder mit Ton spielen können…

Also habe ich Tante Google angeschmissen und musste über das Linux Soundsysteme erstmal mehr lernen als ich eigentlich wollte… Bei Scott Bronson konnte ich nachlesen, dass das historische Open Sound System (OSS) offenbar dafür verantwortlich ist, dass es immer mal wieder derartige Probleme gibt, wenn mehrere Anwendungen Sounds gleichzeitig ausgegeben möchten. Inzwischen gib’t zwar das Advanced Linux Sound Architecture (ALSA) aber gerade einige closed-source Anwendungen gehen heute noch immer über OSS, so dass z.B. Flash /dev/dsp benutzt und offen hält solange Firefox läuft. Auch VMWare benutzt noch OSS und hält /dev/dsp offen, solange eine VM läuft. Scotts Leitfaden beschreibt eine Lösung, wie man OSS Calls nach ALSA redirecten kann. Da ich bei mir mehrere Sounds per aplay wiedergeben konnte ist zumindest gesichert, das meine ALSA Installation korrekt ist. Da das im How-To verwendete Pakete “alsa-oss” bei Ubuntu offenbar als einzelnes Pakete nicht mehr verfügbar ist (Package alsa-oss is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source) habe ich den Weg dann erstmal nicht weiter verfolgt.
Weiter Infos zum Problem habe ich auch unter ubuntuforums.org [2, 3] gefunden wo man dann aber auch über das alsa-oss Paket geht, welches bei mir ja nicht verfügbar scheint. Und überhaupt wollte ich doch eigentlich nur eine einzige Soundquelle zur Zeit zum klingen bringen. Wer mir da nun das /dev/dsp/ blockierte, blieb für mich unerglündlich, denn es liefen keine anderen Apps, die Sound offen haben könnten.

Schließlich habe ich dann beim Ubuntu Host-System unter System/Sound Preferences den Schalter “Enable software sound mixing (ESD)” deaktiviert. Und damit klappt es dann auch sofort mit der virtuellen Maschine, so dass meine Twins Janosch’s Tiger und Bär nun auch wieder mit Ton spielen können. Das WE ist gerettet.