Upgrade UCS 4.1-5 auf 4.2 hängt bei Generating legacy menu.lst from current kernels

UCS - Univention Corporate Server
#1

Guten Tag liebe Leut,

gerne würde ich einen UCS von Version 4.1-5 auf 4.2 bringen. Angezeigte Warnungen, die vor dem eigentichen Upgrade angeziegt werden, habe ich beseitigt. Nach etwa 40 Minuten tut sich nichts mehr im updater.log, hier die letzen Zeilen…

Found linux image: /boot/vmlinuz-4.9.0-ucs103-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs103-amd64
Found linux image: /boot/vmlinuz-4.1.0-ucs227-amd64
Found initrd image: /boot/initrd.img-4.1.0-ucs227-amd64
Found linux image: /boot/vmlinuz-4.1.0-ucs222-amd64
Found initrd image: /boot/initrd.img-4.1.0-ucs222-amd64
Found linux image: /boot/vmlinuz-4.1.0-ucs207-amd64
Found initrd image: /boot/initrd.img-4.1.0-ucs207-amd64
Found memtest86+ image: /memtest86+.bin
File descriptor 3 (pipe:[62378138]) leaked on lvs invocation. Parent PID 11240: /bin/sh
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11548: grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11548: grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11548: grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11548: grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11548: grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11548: grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
grub-probe: error: unknown filesystem.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11811: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11811: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11811: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11811: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11811: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11811: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
/usr/sbin/grub-probe: error: unknown filesystem.
Found Univention Corporate Server 4.1-5 errata489 (Vahr) (4.1-5 errata489) on /dev/mapper/vg_ucs-root--snapshot
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11962: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
File descriptor 3 (pipe:[62378138]) leaked on vgs invocation. Parent PID 11962: /usr/sbin/grub-probe
  Configuration setting "activation/thin_check_executable" unknown.
Found Univention Corporate Server 4.1-4 errata444 (Vahr) (4.1-4 errata444) on /dev/mapper/vg_ucs_data-root
done
Generating legacy menu.lst from current kernels

Die letzte Aktion des Updaters hat offensichtlich mit memtest86+ zu tun:

#ps -ef | grep memtest
root      2984 17260  0 03:01 pts/3    00:00:00 grep memtest
root     31780 32330  0 02:55 pts/2    00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/memtest86+.postinst configure 4.20-1.1.21.201502271253
root     31809 31780  0 02:55 pts/2    00:00:00 [memtest86+.post] <defunct>

Den Perl Prozess habe ich dann abgewürgt
#kill 31780

Danach lief die Upgrade Prozedur noch eine Weile weiter, wurde aber letztendlich leider doch mit Fehler beendet:

Trigger für libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u5) werden verarbeitet ...

Fehler traten auf beim Bearbeiten von:
 memtest86+
 univention-grub
 univention-role-common
 univention-role-server-common
 univention-bind
 univention-server-master
E: Sub-process /usr/bin/dpkg returned an error code (1)
Error: Failed to execute "apt-get -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-overwrite -o DPkg::Options::=--force-overwrite-dir --trivial-only=no --assume-yes --quiet=1 -u dist-upgrade"
exitcode of univention-updater: 1
ERROR: update failed. Please check /var/log/univention/updater.log

Da ich einen LVM Snapshot vorher gemacht habe, konnte der vorherige Zustand einfach wiederhergestellt werden. Den Bootloader mit update-grub manuell updaten klappt übrigens ohne Fehler. Bei einem zweiten Anlauf bliebt die Installation an der selben stelle hängen.
Auf den Memtest im Bootmenü könnte ich verzichten, deinstallieren geht aber wegen Abhängigkeiten nicht so einfach.

Wo könnte der Hund begraben sein?

Gruß,
Dirk

#2

Hellau!

diese Anfrage kurz vor dem Univention Summit zu posten war vermutlich nicht so geschickt. Vielleicht gibt es jemanden, der auch keine Lust auf Fasching hat :wink:

Gruß,
Dirk

#3

Hallo,

ich habs auch mal erlebt (beim Upgrade auf 4.1 glaub ich), daß der Upgrade-Prozeß an der Stelle hing. Ich hab damals glaub ich sogar noch das psotinst-Script bearbeitet. Aber vieleicht reichts ja auch die Generierung der Grub1-Config abzuschalten:

ucr set grub/generate-menu-lst='no'

Falls die Probleme bei den anderen Paketen dann weiterhin auftreten sollten, müßtest du mal das vollständige Log posten.

Gruß,
SirTux

#4

Hallo SirTux,

danke für den prima Tipp. Das hat zwar das Problem noch nicht gelöst, aber es gibt nun eine neue Idee.
statt

steht jetzt am Ende nur noch

Found Univention Corporate Server 4.1-4 errata444 (Vahr) (4.1-4 errata444) on /dev/mapper/vg_ucs_data-root
done

Da fiel mir die Version 4.1-4 auf, obwohl der Server schon bei 4.1-5 ist. Wegen Platzmangel hatte ich dort in der Vergangenheit eine größere Festplatte eingebaut und einfach alles von der kleineren Platte drauf kopiert und beide drin gelassen. Der Updater findet also eine verwaiste UCS Installation. Werde das bereinigen und dann sehen ob das die Ursache war.

bis bald,
Dirk

#5

nun habe ich alle überflüssigen Betriebssystem Dateien, auf der zusätzlichen Festplatte, entfernt. Jetzt erkennt die Updateprozedur keine andere UCS Installation mehr, nur den “Backup-Snapshot”. Leider bleibt der Fortschritt wieder nach ca. 40 Min. an der selben Stelle hängen:

Found Univention Corporate Server 4.1-5 errata489 (Vahr) (4.1-5 errata489) on /dev/mapper/vg_ucs-root--snapshot
done

Eigentlich wollte ich dann schon wieder abbrechen, war aber anderweitig noch beschäftigt. Nach etwa 20 Min. erschien überraschend ein neuer Eintrag im updater.log

Starting univention-upgrade. Current UCS version is 4.1-5 errata0

Nach weiteren 8 Stunden, kam jede Stunde der selbe Eintrag

Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0


Starting univention-upgrade. Current UCS version is 4.1-5 errata0

Wenn ich das ganze Log nach “Error” durchsuche, finde ich nur etwas zu Iptables, Apache und grub-probe. Dass es an Iptables oder Apache liegt, ist für mich unwahrscheinlich. Bleibt noch

grub-probe: error: unknown filesystem.

Leider kenne ich keine Stelle, an der es ein unbekanntes Dateisystem geben könnte? Kein RAID, kein SAN, kein ISCSI. Nur 2 SSD’s und 2 HDD’s.

lsblk -o name,fstype,size,type
NAME                        FSTYPE        SIZE TYPE
sda                         ext4          2,7T disk
sdb                                     465,8G disk
├─sdb1                      ext2          500M part
├─sdb2                                      1K part
└─sdb5                      LVM2_member   455G part
  ├─vg_ucs-root (dm-2)      ext4        135,2G lvm
  └─vg_ucs-swap_1 (dm-4)                   10G lvm
sdc                                     931,5G disk
├─sdc1                      ext2          487M part
├─sdc2                                      1K part
└─sdc5                      LVM2_member   931G part
  └─vg_ucs_data-root (dm-5) ext4          910G lvm
sdd                         ext4          2,7T disk
sr0                                      1024M rom

Was könnte es jetzt noch sein?

updater.log (1.2 MB)
Gruß,
Dirk

#6

Der GRUB stört sich häufiger an den LVM-Snapshots. Mitunter ist es nötig die “grub-probe”-Prozesse zu killen:

ps aux | grep grub
kill $pids

EDIT: Korrektur des Befehls

#7

Hallo SirTux,

vielen herzlichen Dank!
Den Grub Prozess beenden war der ausschlggebende Hinweis.

Allerdings führte ps aux grub-probe bei mir zu einer Fehlermeldung. Ich habe es dann mit
#ps aux | grep grub
versucht und einen grub-mount Prozess gefunden.
root 21714 0.0 0.0 24628 1704 ? Ss 01:19 0:00 grub-mount /dev/mapper/vg_ucs-root--snapshot /var/lib/os-prober/mount
diesen hatte ich dann gekillt und schon ging es weiter. Ich musste im Verlauf des Updates noch einmal zu diesem Kniff greifen.

Ist schon eine gewisse Ironie, dass das Update bisher an der Methode der Sicherung gescheitert ist. Aber so ist es mir lieber, als alles neu Aufzusetzen.

Univention Alaaf :smiley:
Dirk

#8

Sorry ja genau so sollte es eigentlich heißen. Da ist mir leider Fehler unterlaufen. Es freut mich, daß es geklappt hat.

Mastodon