Archive for category Linux
“Waiting for root file system” caused by out dated VMware Server
Posted by Lars Schenk in Linux on Februar 25th, 2009
I run into a strange problem when I upgraded some VMs from Debian Etch to Lenny. I’m using VMware Fusion on my MacBook Pro and VMware Server on my local Debian Server. Upgrading VMs hosted by the VMware Server ended in System boot hangs “Waiting for root file system”. Upgrading nearly the same Etch VMs hosted by VMware Fusion did not fail.
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.
Nagios commands via web-interface on Debian
Posted by Lars Schenk in Linux, Open Source, tech-recipes on Februar 24th, 2009
Ups, I did it again – when I upgraded to Debian GNU/Linux 5 (lenny) and Nagios3 I stumbled about this nagios error when I try to send directs commands via the web-interface:
Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!
In “/etc/nagios3/nagios.cfg” the “check_external_commands=1″ was already set. So there was something more required to make it run on Debian…
Deep in my memory I know that there was a debian way to solve this user right related problem. This time I’ll write it down here – perhaps I’ll find it more easily when I upgrade to Debian GNU/Linux 6.0 (codenamed squeeze) and/or Nagios4.
/etc/init.d/nagios3 stop
dpkg-statoverride –update –add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride –update –add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start
Welches SDK: Android oder iPhone?
Posted by Lars Schenk in Apple, Linux, Open Source, osx on September 25th, 2008
Ich habe mir das Video der Vorstellung des T-mobile G1 Android angeschaut…. Nunja. Der einzige echte Plusplunkt ist die konsequente Umsetzung von OpenSource. Alledings wirkt es auf mich auch fast wie eine Entschuldigung für alles wo das iPhone (noch) in einer anderen Liga spielt…
Ich habe zu wenig Zeit um in das interessante Thema tiefer einzusteigen – aber hier dennoch ein paar lesenswerte Artikel (etwas iPhone-lastig):
Aus Entwickler-Sicht sehr interessant der Vergleich zum “kontrollierten” AppStore vs. dem unreguliertem Andorid Market Place.
Und ebenfalls interessant: http://gizmodo.com/5053441/giz-explains-whats-good-and-bad-about-developing-for-android-and-iphone
Aus Benutzersicht ist das iPhone zZ noch das deutlich rundere Paket. Zumal wenn man auf dem Desktop OS X einsetzt, drängt sich das iPhone geradezu auf. Allerding sieht es aus Entwicklersicht ganz anders aus: wenn man nicht in das geregelte (geschlossene) System von Apple eintauchen will (und Objective C nicht einsetzen mag), bleibt nur der Android.
Ich vermute, dass Android zum Start kein Renner wird und sich womöglich ähnlich schwer tun wird wie Linux den Desktop zu erobern. Aber immerhin hat das iPhone nun einen mächtigen Gegenspieler (mit sehr starken Konzepten) und die OpenSource Entwickerkommunity hat endlich ein SDK 1.0 für Android. Es wird spannend…
Debians Supergau:
Das Internet ist nicht mehr sicher – und Kurt ist schuld
Posted by Lars Schenk in Linux, Open Source on Mai 17th, 2008
‘Ach Du Schreck’ denke ich, als ich beim obligatorischen upgraden der Debian-Pakete den folgenden Hinweis bekam:
Vulnerable host keys will be regenerated
Some of the OpenSSH server host keys on this system were generated with a version of OpenSSL that had a broken random number generator. As a result, these host keys are from a well-known set, are subject to brute-force attacks, and must be regenerated.
…
Mehr Details dazu unter: http://lists.debian.org/debian-security-announce/2008/msg00152.html
Das ist wirklich schlimm, denn anders als bei den meisten üblichen Sicherheitslücken, die durch einen Patch sofort mehr oder weniger zuverlässig geschlossen werden (hoffentlich ohne neue Sicherheitslücken aufzureissen), ist dieser Fehler eher wie eine Art Bandwurm. Das fehlerhafte Debian Paket OpenSSL hat Schlüssel erzeugt, die nicht so zufällig waren wie sie hätten sein sollen. Daher sind diese Schlüssel vorhersagbar und nicht sicher.
Etliche sicher geglaubte Keys sind längst im Umlauf (das Problem besteht seit dem 17.09.2006) und müssen nun rasch durch neue, sichere Schlüssel ersetzt werden, bevor die schwachen Schlüssel, die ja auch zur Authentifizierung genutzt werden, geknackt werden. Read the rest of this entry »
VMWare Fusion nicht kompatibel zu VMWare Server 1.x
Posted by Lars Schenk in Linux, Virtualisierung on März 18th, 2008
Ich habe eine VM mit Fusion erstellt, die Debian Etch enthält. Diese soll nun unter VMWare Server 1.x laufen. Die unter Fusion erstellte VM ist aber nicht kompatibel mit VMWareServer 1.x. Ob der neue VMWare Server 2.x, der zZ. in beta ist, mit Fusion erstelte VMs laufen lassen kann, habe ich nicht ausprobiert. Ich habe mit VMWare Converter die mit Fusion erstellte VM in das Format von VMWareServer 1.x gebracht.
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.
Zeitsynchronisierungs-Probleme unter VMWare
Posted by Lars Schenk in Linux, Virtualisierung on März 16th, 2008
Um zigtausende “rtc: lost some interrupts” Meldungen aus dem syslog zu verbannen, hatte ich für einzelne betroffenen VMs den Eintrag “host.useFastClock = FALSE” in der *.vmx gesetzt. Der Preis dafür war eine nicht mehr exakte Zeitsynchronisierung die bisher für meine Anwendungsfälle vertretbar war und durch externe Zeitsynchronisierung (ntpd) aufgefangen wurde.
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.”
VMWare rtc: lost some interrupts
Posted by Lars Schenk in Linux, Virtualisierung on September 4th, 2007
Nachdem ich VMWare Server unter Debian Etch Linux laufen lasse, bekomme ich bei einigen Gast OS die Meldung “rtc: lost some interrupts” im Syslog des Hosts eingetragen – und war sehr häufig, so dass das Syslog regelrecht zugemüllt wird. Eine Lösung für Gast OSe, die keine absolut exakte Zeiterfassung benötigen kann man dem VMWare Timekeeping Manual entnehmen:
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.
Latest comments