Univention Bugzilla – Bug 27456
Kernel 3.2
Last modified: 2012-12-12 21:09:11 CET
Mit UCS 3.1 sollte das Kernel Update von 2.6.32 auf Kernel 3.2 geprüft werden. Im Idealfall wird der alte 2.6.32iger Kernel durch den Kernel 3.2 komplett ersetzt.
Diese Patches wurden übernommen und auf 3.2 portiert: 10_config-changes.patch 72_enable_legacy_pts.patch (die Änderung wurde ebenfalls in 10_config-changes.patch integriert) 41_disable_abicheck.patch 71_ucs_version.patch Der Patch 40_set_flavour.patch ist nicht mehr nötig, openvz und vserver sind nach 2.6.32 nicht mehr enthalten. Der Patch 90_linux-base-postinst.patch kann entfallen, wenn der Installer angepasst wird, so dass direkt die UUID-Notation geschrieben wird (Bug 17018) Diese Patches sind in 3.2 upstream enthalten und sind nicht mehr nötig: 91_23258_kvm-clock-reset.patch 92_ext4-serialize-unaligned-asynchronous-DIO.patch Folgende Patches sind min. noch nötig: - Das rt-Flavour sollte deaktiviert werden. Es erhöht die Übersetzungszeiten und da es nicht upstream ist, ist nicht gesichert, das es in späteren Kerneln weiter enthalten ist. - Bau mit gcc-4.4 - Deaktivieren der mit kernel-wedge gebauten Kernel-Pakete für den debian-installer - Zurücksetzen der Kompression von xz auf gz
> Folgende Patches sind min. noch nötig: > > - Das rt-Flavour sollte deaktiviert werden. Es erhöht die Übersetzungszeiten > und da es nicht upstream ist, ist nicht gesichert, das es in späteren Kerneln > weiter enthalten ist. 16-disable-rt-flavour.patch > - Bau mit gcc-4.4 18-use-gcc-4.4.patch > - Deaktivieren der mit kernel-wedge gebauten Kernel-Pakete für den > debian-installer 22-disable-udeb-generation.patch > - Zurücksetzen der Kompression von xz auf gz 20-disable-xz-compression.patch Die für den Bau verwendeten Python-Skripte verwenden min. ein Feature aus Python 2.7 (collections.OrderedDict). Ggf. muss python2.7 als Build-Dep gebaut werden falls es zu viele 2.7-Spezifika gibt, die ersetzt werden müssen.
(In reply to comment #2) > Die für den Bau verwendeten Python-Skripte verwenden min. ein Feature aus > Python 2.7 (collections.OrderedDict). Ggf. muss python2.7 als Build-Dep gebaut > werden falls es zu viele 2.7-Spezifika gibt, die ersetzt werden müssen. In Apache Wave gibt es einen Backport von OrderedDict, den ich integriert habe: 24-ordereddict-backport.patch
Weitere offene Punkte: Die quilt-Version aus 3.0 ist zu alt; das Kernel-Buildsystem muss gepatcht werden, so dass die Option "--fuzz" nicht mehr verwendet wird. Das sollte keine problematischen Auswirkungen haben.
linux-base und initramfs-tools 0.99 wurden ebenfalls als Backports für 3.1 gebaut
(In reply to comment #4) > Weitere offene Punkte: > > Die quilt-Version aus 3.0 ist zu alt; das Kernel-Buildsystem muss gepatcht > werden, so dass die Option "--fuzz" nicht mehr verwendet wird. Das sollte keine > problematischen Auswirkungen haben. -> 26-quilt-compat.patch
Ein Basis-Kernel ist gebaut, der Patch 14_ucs_version.patch muss noch aktualisiert werden, die Kernel-Build-Interna haben sich geändert. Folgende Kombinationen müssen mit Xen und KVM getestet werden: Wirt 3.2, Gast 2.6.32 Wirt 2.6.32, Gast 3.2 Wirt 3.2, Gast 3.2
firmware-free und firmware-nonfree wurden in 3.2-kompatiblen Versionen importiert und gebaut. Die Problematik mit der notwendigen interaktiven Bestätigung der Lizenz der Firmware-Pakete für ipw2x00 und ivtv besteht weiterhin (siehe Bug 22508). Für UCS 3.1 wird dieselbe Lösung umgesetzt, d.h. die Pakete sind weiterhin nicht über das Meta-Paket installierbar. Ich habe alle übrigen Firmware-Pakete geprüft; sie lassen sich direkt installieren.
KVM wurde mit einem Virtualisierungs-Server unter i386 getestet: Mit dem 3.2-Kernel auf dem Wirt konnte ein i386-Gast mit UCS 3.0-2 und Kernel 2.6.32 und ein i386-Gast mit UCS 3.1 und einem 3.2-Kernel erfolgreich getestet werden. Getestet wurden jeweils ein kurzer Start der VM und Netzwerkzugriffe. Was aktuell nicht funktioniert ist der Betrieb von UCS 3.1 mit Kernel 3.2 als Gast auf einem 3.0-2-System mit dem 2.6.32-Kernel. Die VM belegt 100% der CPU-Last und die VNC-Ausgabe bleibt nur schwarz. Anwendungsfall für dieses Szenario: - Jemand möchte in einer UCS 3.0-Umgebung ein UCS 3.1 testen - Eine Virtualisierungsumgebung, in der einzelne Systeme noch nicht auf 3.1 aktualisiert wurden In strace sieht man das fortlaufend versucht wird auf einen FD zu selecten(), ich habe das aber nicht weiter verfolgt, da die KVM-Userspace-Tools ohnehin noch aktualisiert werden sollen und das dort vermutlich bereits gefixt ist. Tests mit Xen stehen noch aus.
Der blktap-Patch, der im Squeeze-Kernel enthalten war, ist im Wheezy nicht mehr enthalten, da er nicht mit dem übrigen Xen-Code upstream gemergt wurde. Das führt beim Starten einer VM zu folgendem Traceback: Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain self._createDevices() File "/usr/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2364, in _createDevices devid = self._createDevice(devclass, config) File "/usr/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2326, in _createDevice return self.getDeviceController(deviceClass).createDevice(devConfig) File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 174, in createDevice device = TapdiskController.create(params, file) File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 286, in create return TapdiskController.exc('create', '-a%s:%s' % (dtype, image)) File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 233, in exc (args, rc, out, err)) TapdiskException: ('create', '-aaio:/var/lib/libvirt/images/ucs_3.0-2-20120717145516-dvd-amd64.iso') failed (55808 blktap kernel module not installed ) [2012-08-07 13:41:56 1933] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy: domid=1 [2012-08-07 13:41:56 1933] DEBUG (XendDomainInfo:2401) Destroying device model Es gibt ein separates Paket blktap-dkms, das den Code über DKMS bereitgestellt. Das werde ich testen/integrieren.
linux-tools wurde ebenfalls importiert und gebaut. Es stellt kbuild bereit, das für das Header benötigt wird, das wiederum von dkms benötigt wird.
Mit dem DKMS-blktap funktioniert Xen generell, weitere Tests stehen noch aus.
Xen wurde mit einem Virtualisierungs-Server unter amd64 getestet: Mit dem 3.2-Kernel auf dem Wirt konnte ein amd64-Gast mit UCS 3.0-2 und Kernel 2.6.32 und ein i386-Gast mit UCS 3.1 und einem 3.2-Kernel erfolgreich getestet werden. Getestet wurden jeweils ein kurzer Start der VM und Netzwerkzugriffe. Auch der der Betrieb von UCS 3.1 mit Kernel 3.2 als Gast auf einem 3.0-2-System mit dem 2.6.32-Kernel funktioniert.
Die Kernel-Meta-Pakete wurden umbenannt; anstatt die Kernel-Version in den Namen aufzunehmen, heissen sie jetzt nur noch: Unter amd64; univention-kernel-image : Ein Kernel für alles; Xen und Standard-Betrieb. Unter i386: univention-kernel-image-pae : der Standard-Kernel für i386, mit diesem Kernel ist auch Xen möglich univention-kernel-image : der Kernel für i386-Systeme, die kein PAE beherrschen (486, Pentium, wenige 686) Analog univention-kernel-headers-* und univention-kernel-source-*
Ich habe die Meta-Paket noch einmal überarbeitet und aufgeräumt. Das Standard-Metapaket für i386 und amd64 heisst jetzt einheitlich univention-kernel-image. Auf amd64 ist es das einzige. Unter i386 gibt es für Altsysteme ohne PAE zusätzlich univention-kernel-image-486. Analog univention-kernel-headers-* und univention-kernel-source-*
Ich habe die Aktualisierung der Metapakete gestestet, beim Update wird der 3.2-Kernel installiert (analog Kernel-Header und Kernel-Sourcen). Das Changelog wurde ergänzt. Die Tests auf zwei verschiedenen Servern aus dem Labor und in Xen/KVM waren soweit erfolgreich. Das einzige was noch aussteht, sind X11-Tests mit Systemen, die die drei KMS-fähigen X-Server verwenden (intel, ati und nouveau). Hier ist zu prüfen, ob aufgrund von Kernel-Änderungen/KMS Aktualisierungen der X11-Bibliotheken notwendig sind.
> Die Tests auf zwei verschiedenen Servern aus dem Labor und in Xen/KVM waren > soweit erfolgreich. Das einzige was noch aussteht, sind X11-Tests mit Systemen, > die die drei KMS-fähigen X-Server verwenden (intel, ati und nouveau). Hier ist > zu prüfen, ob aufgrund von Kernel-Änderungen/KMS Aktualisierungen der > X11-Bibliotheken notwendig sind. Der Radeon-Treiber aus 3.0/3.1 funktioniert weiterhin mit Kernel 3.2 (zumindest in der Hardware, wie in in den Schulungsrechnern verbaut ist). Der Nouveau-Treiber funktioniert _nicht_ mehr, im xorg-Log sieht man nur ein drmOpen() failed Das passt auch in etwa zu diesem Changelog-Eintrag des Xservers: xserver-xorg-video-nouveau (1:0.0.16+git20101210+8bb8231-1) experimental; urgency=low [ Sven Joachim ] * New upstream snapshot. - X server 1.8 or higher is now required. - Bump build-dependency on libdrm-dev to (>= 2.4.23) due to libdrm-nouveau API changes. -- Julien Cristau <jcristau@debian.org> Tue, 04 Jan 2011 11:59:17 +0100 Tests mit Intel stehen noch aus, das ausgemusterte Acer-Notebook scheint bislang mit dem Standard-3.0 nur in VESA zu laufen.
(In reply to comment #7) > Ein Basis-Kernel ist gebaut, der Patch 14_ucs_version.patch muss noch > aktualisiert werden, die Kernel-Build-Interna haben sich geändert. > > > Folgende Kombinationen müssen mit Xen und KVM getestet werden: > > Wirt 3.2, Gast 2.6.32 > Wirt 2.6.32, Gast 3.2 > Wirt 3.2, Gast 3.2 Bitte auch die Xen Live Migration von UCS 3.0 mit 2.6.32 auf UCS 3.1 mit Kernel 3.2 testen. Dabei sowohl mit Windows + GPLPV, als auch mit einem UCS Gast.
(In reply to comment #17) > Tests mit Intel stehen noch aus, das ausgemusterte Acer-Notebook scheint > bislang mit dem Standard-3.0 nur in VESA zu laufen. Der Intel-Treiber aus 3.0/3.1 funktioniert weiterhin mit Kernel 3.2 (zumindest in der Hardware, die in einem Thinkpad X61 verbaut ist) Für die Grafikdarstellung in UCS reicht auch VESA, ich werde die Release Notes um einen Hinweis ergänzen, dass einige Grafiktreiber mit dem neuen Kernel nicht mehr zur Verfügung stehen.
> Bitte auch die Xen Live Migration von UCS 3.0 mit 2.6.32 auf UCS 3.1 mit Kernel > 3.2 testen. Dabei sowohl mit Windows + GPLPV, als auch mit einem UCS Gast. Die Live-Migration funktioniert. Getestet mit einem UCS 3.0-Basissystem und einem Windows 7 / 32 Bit und den GPLPV-Treibern. Ein Ping auf die migrierende Instanz brauchte nicht länger als 20 ms.
Soweit alles erledigt, für die spätere Aktualisierung in der späteren Release-Phase gibt es einen separaten Bug.
Ich glaube eine ausführliche QA ist erst mit Bug #28157 notwendig. Hier sollten die allgemeinen Punkte kurz getestet werden: - ist der Kernel auf der DVD - wird der Kernel beim Update aktualisiert - Changelog
OK: Installation mit ucs_3.1-0-20120906065702-dvd-amd64.iso OK: Installation mit ucs_3.1-0-20120906065701-dvd-i386.iso OK: Upgrade UCS-3.0-errata120 amd64 FAIL: Kein ChangeLog-Eintrag
(In reply to comment #23) > OK: Installation mit ucs_3.1-0-20120906065702-dvd-amd64.iso > OK: Installation mit ucs_3.1-0-20120906065701-dvd-i386.iso > OK: Upgrade UCS-3.0-errata120 amd64 > FAIL: Kein ChangeLog-Eintrag Changelog-Eintrag war drin, aber ein Typo in der Bug-Nummer.
OK: ChangeLog
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".