UCC 3 Updates

Hallo,

vielleicht können angesichts der aktuellen Bugs (z.B. Dirty Cow) mal wieder die aktuellsten Ubuntu-Updates bereitgestellt werden.

Danke und viele Grüße,
SirTux

Hallo,

danke der Nachfrage. Beim letzten Test eines Mirror Updates gab es Probleme mit einem der Ubuntu Pakete bei der unbeaufsichtigten Installation, wie wir sie in UCC durchführen. Wir werden das Thema in der nächsten Woche noch einmal angehen.

Hat sich etwas neues ergeben? Vielleicht kann man ja das fragliche Paket vorerst weglassen?

Hallo,

bitte entschuldigen Sie die Verzögerung. Aller Voraussicht nach werden wir nach der Freigabe eines Errata Updates heute im Laufe des Tages den Mirror aktualisieren.

Danke, leider kams mit dem neuen Kernel zu Problemen, die mir bei reinen Ubuntu-Installationen nicht aufgefallen sind.

So kam es bei mehreren Systemen (bis jetzt 3 von 4) zu einem Freeze. Bei einem ist dieser sogar dauerhaft. Es bootet nur mit dem alten Kernel voll durch. Mit dem neuen kommt es nur bis zum Software-Update.

Das stark betroffenene ist ein 32-Bit-System. Aber unter den zwei weniger stark betroffenen ist auch ein 64-Bit-System, das nicht betroffene ist auch 32 Bit.

Der Kernel ist identisch zum Ubuntu-Kernel. Ich habe die Hash-Werte der Pakete und der Kernel-Datei verglichen.

Zwei virtualisierte Systeme haben auch keine Probleme gezeigt. Es steht jetzt also nur noch bei 3 von 6.

Hallo,

sowohl virtualisierte als auch reine hardwarebasierte Systeme haben in unseren Tests des Updates per PXE als auch local-boot funktioniert. Wie unterscheiden sich Ihre Systeme von einem Standard Image? Ist zusätzliche Software installiert, wird eine angepasste Partitionierung verwendet?

Gibt es Hinweise in der /var/log/univention/software-updates.log auf Probleme bei der Installation der aktualisierten Pakete?

Nein, in den Logs gibt es keine Hinweise.

Die Images unterscheiden sich sowohl vom Standardimage als auch untereinander bezüglich Software und Partitionierung. DIe 64-Bit-Systeme haben KDE neon und teilweise LVM-Partitionierung. Die 32-Bit-Systeme haben LXDE und nur eine größere Root-Partition.

Bei einem System konnte ich übrigens u.a. folgende Meldung sehen (erinnert mich ein wenig an Dirty Cow):

bug unable to handle kernel paging request

Das Problem trat übrigens bei einem System nun erneut auf. Das heißt, daß prinzipiell alle Systeme betroffen sein können.

Bei dem dauerbetroffenen System habe ich mal den neusten Xenial-Kernel aus ppa:canonical-kernel-team/ppa probiert. Leider keine Änderung. Mit dem Yakkkety-Kernel aus dem selben PPA bootet das System zwar, aber NFS-Mounts sind nicht verfügbar und lassen sich auch nachträglich nicht mounten.

Hallo,

das ist aus der Ferne schwierig zu debuggen. Dinge die mir spontan einfallen:

• Werden die Systeme per PXE (dann mit ‘alten’ Kernel) gestartet oder per local boot? Ändert sich das Verhalten, wenn man das jeweils andere verwendet?
• Kann das ganze auf bestimmte Kernel Versionen eingegrenzt werden? Dazu bitte testweise einmal ältere Kernel Versionen aus dem UCC repository installieren.

Hallo,

die Kernel werden alle Lokal über GRUB gebootet. Ich mal den vorletzten Kernel 42 installiert. Mein Dauerverweigerer hat damit auf Anhieb gebootet.

Auch ein 64-Bit-System konnte ich damit booten, welches eben auch zu einem Dauerverweigerer mutiert ist.

Inzwischen glaub ich auch, daß das nichts mit dem Updater zu tun hat. Es schien jetzt eher beim NFS-Mount zu hängen.

Dise Meldungen habe ich mir notiert:

rpc_pipe_read
oops: 0002 smp

Viele Grüße,
SirTux

Also 42 crasht auch. 43 hatte ich übersehen, ist aber ja vermutlich auch betroffen. Ich teste gerade 36.

Bei 42 crashte diesmal übrigens der rpc.gssd. Es handelt sich übrigens zumindest zunächst nicht um einen richtigen Freeze, also das System reagiert teilweise noch.

Momentan siehts so aus, als hätte ich einen Workauround gefunden. Ich habe das Kernel-Modul “rpcsec_gss_krb5” gebalcklistet und der Problemhost startet.

Das war übrigens ein Irrtum. den 42-Kernel hatte ich mit diese anscheinend doch nicht getestet.

2 funktionierende Reboots beim Problemhost sind IMO ein gutes Zeichen. Das paßt auch gut zu meinen sonstigen Beobachtungen: Reine Ubuntu-Systeme, die ich betreue, sind entweder ohne NFS oder ohne Kerberos. Deshalb sind diese nicht betroffen.

Inzwischen ist es offensichtlich, daß der Workaround funktioniert.

Hallo,

schön, dass es mit dem Workaround erst einmal funktioniert. Dazu habe ich noch bugs.launchpad.net/ubuntu/+sour … ug/1270445 gefunden, das ist eventuell ein weiterer Workaround.

"NEED_GSSD=yes"

hatte ich mein ich auch probiert, aber das brachte leider nichts. Die anderen kann ich bei Gelegenheit mal ausprobieren.

Aber ein möglicher anderer Workaround wäre interessanter: Unterstützung für Kerberos-Mounts in UCS und UCC

Danke für die schnelle Bereitstellung der heutigen Updates

Wegen Stack-Clash ist es wohl mal wieder Zeit für einen Mirror Sync.

Hallo,

vielen Dank für die Nachfrage. Der UCC 3 Mirror wurde gestern nachmittag, der UCC 2 Mirror jetzt gerade aktualisiert.

Anscheinend gab es gestern noch ein paar weitere sicherheitskritische Updates. Könnten die vielleicht noch vor dem Wochenende durchgeleitet werden? Vielen Dank