Vergangenen Freitag Nachteinsatz bei $KUNDE. Auftrag: in sechs
Sun M5000 Server die RAM-Module gegen größere tauschen (aus 128GB werden 256GB) und in zwei Maschinen noch jeweils zwei CPUs stecken. Und weil man dazu Downtime braucht, war die Idee, bei der Gelegenheit gleich noch alle Maschinen auf den selben Patch-Stand zu heben, wenn es – aus historisch gewachsenen Gründen – schon nicht das selbe Solaris Minor Release sein kann. Die sechs Maschinen sind drei Cluster-Pärchen, alles SunCluster 3.2. Ganz besonderen Spaß hatten wir mit einem der drei Cluster.
Die Maschinen laufen auf UFS mit gespiegelten Systemplatten. Der erfahrene Patchmeister fährt die Maschine zum Patchen in den singleuser und trennt vor der Patcherei erstmal den Root-Spiegel auf, um ein Fallback zu haben. Sinnvollerweise auch noch gleich das
/var. Dort drin lebt bei Solaris die Paket- und Patchdatenbank, die natürlich fleißig aktualisiert wird, wenn man so um die 200 Patches einfährt. Patches einspielen kann bei Solaris dauern, wenn es viele sind. Es waren viele. Beide Knoten wurden seit der Installation vor 1.5 Jahren nicht mehr aktualisiert. Aber irgendwann geht auch das vorbei. Weil natürlich Kernel-Patches dabei waren, bootet man tunlichst neu. Auch, weil Devicetreiber gerne einen neu gebauten Devicetree sehen würden und deswegen gerne einen Reconfigure-Boot hätten. Weil man aber nicht gleich auch den ganzen Cluster anschmeissen will, fährt man erstmal an den OK-Prompt und von da mit den Optionen
-xs ohne Cluster-Umgebung in den Milestone single-user. Auf einem der beiden Knoten ging das ganz wunderbar ohne Fehler. Auf dem anderen Knoten sah das nach Anbooten des Kernels so aus:
Rebooting with command: boot -xs
Boot device: /pci@40,600000/pci@0/pci@8/pci@0/scsi@1/disk@0,0:a File and args: -xs
SunOS Release 5.10 Version Generic_137111-06 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_disconnect'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_getsockname'
/kernel/fs/sparcv9/sockfs: undefined symbol 'nd_free'
/kernel/fs/sparcv9/sockfs: undefined symbol 'nd_load'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_create'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_close'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_listen'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_recvd'
/kernel/fs/sparcv9/sockfs: undefined symbol 'mi_mpprintf'
/kernel/fs/sparcv9/sockfs: undefined symbol 'udp_wput_data'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_alloc_hdr'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_get_opt'
/kernel/fs/sparcv9/sockfs: undefined symbol 'tcp_wput'
/kernel/fs/sparcv9/sockfs: undefined symbol 'mi_sprintf'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_bind'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_getpeername'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_sendmsg'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_set_opt'
/kernel/fs/sparcv9/sockfs: undefined symbol 'sctp_connect'
WARNING: mod_load: cannot load module 'sockfs'
WARNING: sockfs: unable to resolve dependency, module 'drv/ip' not found
/kernel/drv/sparcv9/ip: undefined symbol 'dhcifname'
WARNING: mod_load: cannot load module 'ip'
Sowas will man nicht haben. Jetzt war guter Rat teuer.
Erstmal Maschine abschießen, sprich vom System Controller ein Break schicken. Lustigerweise kam die Maschine damit zwar nicht auf den ok-Prompt, hörte aber auch mit dem Laden von Modulen auf und bot einen Login-Prompt. Der sogar funktionierte. Also konnten wir versuchen, ein wenig Forensik zu betreiben:
root@solaris# svcs -a | grep maintenance
maintenance 21:36:45 svc:/network/physical:default
maintenance 21:38:09 svc:/system/device/local:default
root@apollon207:svcs -xv svc:/system/device/local:default
svc:/system/device/local:default (Standard Solaris device configuration.)
State: maintenance since Fri Jul 17 21:38:09 2009
Reason: Start method exited with $SMF_EXIT_ERR_FATAL.
See: http://sun.com/msg/SMF-8000-KS
See: /etc/svc/volatile/system-device-local:default.log
Impact: 11 dependent services are not running:
svc:/system/filesystem/minimal:default
svc:/system/manifest-import:default
svc:/network/routing-setup:default
svc:/milestone/single-user:default
svc:/system/sysevent:default
svc:/system/device/fc-fabric:default
svc:/milestone/devices:default
svc:/system/cluster/loaddid:default
svc:/system/coreadm:default
svc:/system/cryptosvc:default
svc:/system/pools:default
root@solaris# less /etc/svc/volatile/system-device-local:default.log
[ Jul 17 21:36:43 Enabled. ]
[ Jul 17 21:36:58 Executing start method ("/lib/svc/method/devices-local") ]
[ Jul 17 21:36:58 Timeout override by svc.startd. Using infinite timeout ]
internal error: failed to initialize ZFS library
[ Jul 17 21:38:09 Method "start" exited with status 95 ]
Tja, wenn das
system-device-local schon nicht läuft, kommt eine Menge anderes Zeug auch nicht hoch. Mist.
Als nächstes die Idee, mal vom hoffentlich intakten Mirror zu booten. Also flugs die abgetrennte Root-Partition gemountet, in der
/etc/vfstab die Referenzen auf den Spiegel entfernt und aus der
/etc/system den Verweis auf das Root-Device raus geschmissen. Runter auf den OK-Prompt und von dort den Spiegel gestartet. Kommt tadellos hoch:
{1} ok boot mirror -xs
Resetting...
Sun SPARC Enterprise M5000 Server, using Domain console
Copyright 2008 Sun Microsystems, Inc. All rights reserved.
Copyright 2008 Sun Microsystems, Inc. and Fujitsu Limited. All rights reserved.
OpenBoot 4.24.10, 65536 MB memory installed, Serial #xxxxxxxx.
Ethernet address 0:21:28:xx:xx:xx, Host ID: 85xxxxxx.
Rebooting with command: boot -xs
Boot device: /pci@40,600000/pci@0/pci@8/pci@0/scsi@1/disk@0 File and args: -xs
SunOS Release 5.10 Version Generic_137111-06 64-bit
Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Booting to milestone "milestone/single-user:default". Immerhin, wir haben ein funktionierendes Fallback. Trotzdem strange.
Als nächstes die Idee, die frisch gepatchte Spiegelhälfte mal einen reconfigure boot fahren zu lassen. Gesagt getan:
Rebooting with command: boot -rxs
Boot device: /pci@40,600000/pci@0/pci@8/pci@0/scsi@1/disk@0,0:a File and args: -rxs
SunOS Release 5.10 Version Generic_137111-06 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Kommt tadellos hoch. Aber hoppla! Das Boot-Device ist doch das selbe, wie wenn man vom (ungepatchten) Mirror booten will!? WTF!? Runter an den ok-Prompt. Und siehe da:
{2} ok devalias
cdrom /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@3,0:f
net /pci@0,600000/pci@0/pci@8/pci@0/network@2
disk /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@0
mirror /pci@40,600000/pci@0/pci@8/pci@0/scsi@1/disk@0,0:a
name aliases
{2} ok printenv boot-device
boot-device = mirror disk net Da hat also jemand an der Boot-Reihenfolge im OBP rum gepfuscht. Ein flockiges
boot disk -xs bringt und dann ohne weiteres Murren und Mucken genau dahin, wo wir ganz zu Anfang schon hin wollten.
Und damit wurde dann auch klar, was beim ersten Boot-Versuch nach dem Patchen passiert ist: Anstatt der frisch gepatchten Spiegelhälfte wurde der Kernel von der abgetrennten Platte gestartet. Der findet eine Einstellung für einen Bootspiegel d0 (der frisch gepatcht ist), startet das Device erfolgreich, mountet sich das Filesystem zusammen und lädt dann Kernel-Module von einer gepatchten Spiegelhälfte, die aber so gar nicht nicht zum laufenden Kernel passen.
Boot-Device im OBP geändert, und schon bootet der Clusterknoten wieder ganz fidel vor sich hin. Gegen fünf Uhr morgens – nach noch ein paar anderen aufgedeckten Kaputtkonfigurationen – war dann der Tag (und die Nacht) für uns zu Ende.
| 
