Univention Bugzilla – Bug 21984
Kernel-Probleme auf Xen-Instanzen, Installer startet nicht
Last modified: 2011-09-14 10:56:54 CEST
Probleme mit dem univention-installer traten reproduzierbar auf mit vollvirtualisiertem Rechner unter XEN auf xen15. Beim Aufruf des Installers bereitet er alles vor, wechselt dann aber nicht in den Installer-Dialog und bleibt hängen bei der Zeile: ==================== ... Starting syslog daemon: syslogd, klogd Loading USB HID module Loading <stdin> ==================== Das scheint in Verbindung mit Kernel-Anpassung zu stehen. Einstellungen für CD-Rom, Festplatte, Netzwerkkarte scheinen keinen Einfluss zu haben, ebenso scheint alles ok mit einem paravirtualisierten Rechner. Problem trat auf mit dem Image: ucs_2.4-0-20110302134649-dvd-amd64.iso kopiert von von /mnt/omar/vmwares/iso-images/ucs/ucs2.4-0-sec1+2/ucs_2.4-0-20110302134649-dvd-amd64.iso Ebenso trat das Problem auf mit der i386-Variante. Keine Probleme gab es mit dem Image: ucs_2.4-0-100829-dvd-amd64.iso ==================== XML-Dump: <domain type='xen' id='33'> <name>test2_ucs_vv_disk0_eth0</name> <uuid>52218f3e-0c5f-e1ae-bc80-ce7d0c5c6def</uuid> <memory>524288</memory> <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='cdrom'/> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <disk type='file' device='cdrom'> <driver name='tap' type='aio'/> <source file='/var/lib/libvirt/images/ucs_2.4-0-20110302134649-dvd-amd64.iso'/> <target dev='hdb' bus='ide'/> <readonly/> </disk> <interface type='bridge'> <mac address='00:16:3e:c3:a7:63'/> <source bridge='eth0'/> <script path='/etc/xen/scripts/vif-bridge'/> <target dev='vif33.0'/> </interface> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5904' autoport='yes' listen='0.0.0.0' keymap='de'/> </devices> </domain> ==================== Darüberhinaus tritt ein Traceback beim Startvorgang des Installers auf, wenn eine paravirtualisierte Instanz eine paravirtualisierte Festplatte mit einem vollvirtualisierten CD-Rom-Laufwerk gestartet wird. ==================== ... XENBUS: Waiting for devices to initialise: 295s... ... 125s... Starting syslog daemon: syslogd, klogd ==================== Der Installer wird daraufhin nicht gestartet. Hier der XML-Dump der Maschine: ==================== <domain type='xen'> <name>test2_pv_disk0_eth0</name> <uuid>b76b08ff-900c-6967-0c27-bc16775fbf48</uuid> <memory>524288</memory> <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <bootloader>/usr/bin/pygrub</bootloader> <bootloader_args>-q</bootloader_args> <os> <type>linux</type> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <disk type='file' device='cdrom'> <driver name='tap2' type='aio'/> <source file='/var/lib/libvirt/images/ucs_2.4-0-20110302134649-dvd-amd64.iso'/> <target dev='hda' bus='ide'/> <readonly/> </disk> <disk type='file' device='disk'> <driver name='tap2' type='aio'/> <source file='/var/lib/libvirt/images/test2_pv_disk0_eth0-0.raw'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <mac address='00:16:3e:38:bf:38'/> <source bridge='eth0'/> <script path='vif-bridge'/> <target dev='vif-1.0'/> </interface> <console type='pty'> <target type='xen' port='0'/> </console> <input type='mouse' bus='xen'/> <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='de'/> </devices> </domain> ====================
Mit verantwortlich scheint wohl das Skript trunk/ucs/base/univention-installer/startup-scripts/S90virt zu sein. Dieses überprüft, ob das Verzeichnis /proc/xen existiert und lädt ggf. XEN-Treiber nach. /proc/xen existiert auf einer vollvirtualisierten Maschine mit der älteren Installations-DVD nicht, ist jedoch auf der vollvirtualisierten Maschine mit der neuen Installations-DVD vorhanden.
Das Skript versucht diverse Xen Module zu laden. Wird davon ein Modul erfolgreich geladen?
Die Module, die für die paravirtualiserte Maschine geladen werden, werden auch auf der voll-virtualisierten Maschine erfolgreich gestartet. Vielleicht liefert /proc/fb einen Hinweise? Unter der vollvirtualisierten Maschine steht dort "0 VESA VGA", unter der paravirtualisierten "0 xen". Ansonsten enthält eine vollvirtualisierten Maschine die Datei /sys/devices/virtual/dmi/id/product_name mit dem Inhalt "HVM domU". Das Verzeichnis /sys/devices/virtual/dmi existiert nicht auf einer paravirtualierten Maschine. Das Verzeichnis /sys/bus/pci/drivers/xen-platform-pci scheint nur auf einem vollvirtualisierten System zu existieren. Ein Link, in bzgl. /proc/xen gesprochen wird (nicht sicher, ob der weiterhilft): > http://xen.1045712.n5.nabble.com/grep-proc-xen-capabilities-No-such-file-or-directory-td2609965.html
Wir sollten dafür eine angepasste DVD bereitstellen, als Basis sollte die 2.4 sec1+sec2 DVD verwendet werden. Der USB Profil Fix sollte ebenfalls integriert werden: Bug #21757.
Created attachment 3142 [details] Kernel-Log Ich hatte bei Xen auch schon früher Probleme bei Verwendung Block-Devices, wenn diese verschiedene Zugriffsmethoden benutzen, z.B. blktap-Festplatte und IDE-CDROM. Dann lief die Gast-VM immer in das 300s-Time-Out-Problem, weil die BlkTap-Devices nicht mehr gefunden wurden. Leider hat ein 'xm sysrq $VM t' nicht funktioniert um herauszubekommen, wo die Prozesse gerade hängen: Im Log erscheint zwar die Meldung, daß der Task-Dump gemacht wird, aber danach erscheint er nicht auf der seriellen Konsole.
Googlet man nach "if test -d /proc/xen", wird man auf einigen Mailinglisten fündig. Auf einer wird der unten stehende Code verwendet, um /proc/xen zu mounten. Auf den Xen-Maschinen (sowohl paravirtualisiert als auch vollvirtualisert) war das Verzeichnis /proc/xen immer leer. ==================== if test "x$1" = xstart; then if ! grep ' xenfs$' /proc/filesystems >/dev/null; then test -x /sbin/modprobe && /sbin/modprobe xenfs 2>/dev/null fi if test -d /proc/xen && \ ! test -d /proc/xen/capabilities && \ ! grep '^xenfs ' /proc/mounts >/dev/null; then mount -t xenfs xenfs /proc/xen fi fi ==================== Von: http://www.gossamer-threads.com/lists/xen/devel/176224
Ein ähnliches Problem fiel auf einer paravirtualisierten Xen-Instanz mit paravirtualiserten Geräte auf. Dazu wurde ein Rechner mit CD-Rom-Laufwerk nach dem 64bit-Profil UCS-2.4 angelegt und UCS von dem Image ucs_2.4-0-20110302134649-dvd-amd64.iso installiert. Dabei schlägt die automatische Partitionierung im Installer einen falschen Masterboot-Record vor (→ Bug #21988). Wird dieser akzeptiert, dann erhält die Maschine nach der Installation ebenfalls den oben erwähnten Timeout: ==================== ... XENBUS: Waiting for devices to initialise: 295s... ... 125s... Starting syslog daemon: syslogd, klogd Starting syslog daemon: syslogd, klogd Loading USB HID module Loading <stdin> ==================== Hier die Infos zur Maschine: ==================== virsh # dumpxml alex_ucs <domain type='xen'> <name>alex_ucs</name> <uuid>2d1fd30b-822f-e7ff-5694-4a42b3247098</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <bootloader>/usr/bin/pygrub</bootloader> <bootloader_args>-q</bootloader_args> <os> <type>linux</type> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <disk type='file' device='cdrom'> <driver name='tap2' type='aio'/> <source file='/var/lib/libvirt/images/ucs_2.4-0-100829-dvd-amd64.iso'/> <target dev='xvdc' bus='xen'/> <readonly/> </disk> <disk type='file' device='cdrom'> <driver name='tap' type='aio'/> <source file='/var/lib/libvirt/images/ucs_2.4-0-20110302134649-dvd-amd64.iso'/> <target dev='xvdb' bus='xen'/> <readonly/> </disk> <disk type='file' device='disk'> <driver name='tap' type='aio'/> <source file='/var/lib/libvirt/images/alex_ucs-0.raw'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <mac address='00:16:3e:23:e4:ec'/> <source bridge='eth0'/> <script path='/etc/xen/scripts/vif-bridge'/> <target dev='vif-1.0'/> </interface> <console type='pty'> <target type='xen' port='0'/> </console> <input type='mouse' bus='xen'/> <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='de'/> </devices> </domain> ====================
In der XEN-Vollvirtualisierung auf xen14 wurde /dev/hvc0 nicht angelegt. Jedoch wurde /dev/tty1 durch einen Symlink auf das nicht-existente /dev/hvc0 ersetzt. Der Code wurde jetzt so angepasst, dass diese Ersetzung nur dann stattfindet, wenn /dev/hvc0 auch wirklich existiert. Bei einer XEN-Paravirtualisierung auf xen14 existiert zwar /dev/hvc0, aber /sys/devices/virtual/graphics/fb0/ existiert ebenfalls, so dass die Ersetzung wie bisher nicht durchgeführt wird.
Kein Changelog Eintrag, sonst ok Patch in branch 2.4 /univention-installer-> svn diff -c 23500 --- startup-scripts/S90virt (Revision 23499) +++ startup-scripts/S90virt (Revision 23500) @@ -34,7 +34,7 @@ # console: maybe there is a better solution (changing # inittab) but at this point we can not reload inittab - if [ ! -d /sys/devices/virtual/graphics/fb0 ]; then + if [ ! -d /sys/devices/virtual/graphics/fb0 -a -e /dev/hvc0 ]; then rm /dev/tty1 ln -s /dev/hvc0 /dev/tty1 fi ist identisch mit Patch für scope sec2.4-4 --- univention-installer-6.0.47.orig/startup-scripts/S90virt +++ univention-installer-6.0.47/startup-scripts/S90virt @@ -34,7 +34,7 @@ # console: maybe there is a better solution (changing # inittab) but at this point we can not reload inittab - if [ ! -d /sys/devices/virtual/graphics/fb0 ]; then + if [ ! -d /sys/devices/virtual/graphics/fb0 -a -e /dev/hvc0 ]; then rm /dev/tty1 ln -s /dev/hvc0 /dev/tty1 fi und mit einer DVD mit diesen Änderungen wurde es bereits getestet -> Bug #23018
Changelogeintrag wurde hinzugefügt
UCS 2.4-3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".