Ich habe gerade beim Testen das "stabile" Solaris gecrashed: bei der Installtion einiger JES Komponenten habe ich auch den Sun Cluster ausgewählt. Ich habe es fertig bekommen den Cluster als eine Single Node Komponente zu installieren, jedoch war hinterher meine LAN Connectivity weg, weil das routing zerschossen war.
Meine Vermutung war, dass der scinstall des cluster nicht richtig auf die Settings mittels DHCP vorbereitet war, und er hat dann bei der Konfiguration von zusätzlichen internen Addressen und virtuellen Interfaces das Gateway und die Netzmaske vermasselt. Dank ALOM nicht weiter schlimm, ich komme ja über das Netz an die Console, aber wie löst man das Problem? Wie stellt man bei einer Solaris Kiste die Konfiguration auf statische Addressen um?
Ich hab keine bessere Lösung gefunden als die Initialkonfiguration noch einmal durchzuführen. Dazu ruft man "sys-uninstall" auf, und rebootet.
Nun gut, der Ansatz war prinzipiell nicht schlecht, das Setup hat mich tatsächlich nach den neuen Netzwerk Settings gefragt. Es hätte nur die Finger von dem neuen virtuellen Netzwerk interconnect Interface lassen sollen, das der Sun Cluster installiert hat. Denn plötzlich brach der Kernel mit einem Stacktrace weg, in dem die Komponente vorkam:
Meine Vermutung war, dass der scinstall des cluster nicht richtig auf die Settings mittels DHCP vorbereitet war, und er hat dann bei der Konfiguration von zusätzlichen internen Addressen und virtuellen Interfaces das Gateway und die Netzmaske vermasselt. Dank ALOM nicht weiter schlimm, ich komme ja über das Netz an die Console, aber wie löst man das Problem? Wie stellt man bei einer Solaris Kiste die Konfiguration auf statische Addressen um?
Ich hab keine bessere Lösung gefunden als die Initialkonfiguration noch einmal durchzuführen. Dazu ruft man "sys-uninstall" auf, und rebootet.
Nun gut, der Ansatz war prinzipiell nicht schlecht, das Setup hat mich tatsächlich nach den neuen Netzwerk Settings gefragt. Es hätte nur die Finger von dem neuen virtuellen Netzwerk interconnect Interface lassen sollen, das der Sun Cluster installiert hat. Denn plötzlich brach der Kernel mit einem Stacktrace weg, in dem die Komponente vorkam:
# mdb unix.0 vmcore.0 :Loading modules: [ unix krtld genunix specfs ufs sd: ip sctp random fcp fctl em lxs nca ] > ::status debugging crash dump vmcore.0 (64-bit) from operating system: 5.10 Generic_118822-26 (sun4v) panic message: BAD TRAP: type=9 rp=2a100236a80 addr=0 mmu_fsr=0 dump content: kernel pages only > ::stack *clprivnet*_wput+0x10c(60001859308, 600019b0740, 2a100232000, 600019bc3b0, e, 600019bc340) putnext+0x218(60001859400, 60001859308, 600019b0740, 100, 6000195e8d8, 0) ill_fastpath_probe+0xd4(0, 0, 1, 600019bc3b0, 600019b0780, 600019b0740) ire_fastpath+0x54(600019d16e8, 600019b0780, 20, 6000195e8d8, 600019d16e8, 60001856fa8) ire_add_v4+0xb20(2a1002371b0, 1, ffffffff, 1, 0, 0) ire_add+0x36c(2a1002371b0, 0, 0, 0, 4, 0) ipif_up_done+0x60c(6000194b748, 7005d800, 6000194b748, 2a1002371c0, 0, 6000194b764) ip_arp_done+0x130(0, 600019b1d40, 600015a1380, 60001856fa8, 8, 60001721060) qwriter_ip+0x68(60001721060, 60001856fa8, 6000195e8d8, 600015a1380, 12f1548, 0) ip_wput_nondata+0x440(0, 6000195e8d8, 600015a1380, c, 4000, 60001859308) putnext+0x218(6000195e9d0, 6000195e8d8, 600015a1380, 100, 6000195e648, 0) ar_rput_dlpi+0x1d0(600019b0ac0, 600019b0ac0, 600019bcb30, 806000000000000, 20, 6000190f0d0) putnext+0x218(60001541e08, 600019a22c8, 600019b0ac0, 0, 600019a2558, 0) clprivnet_breq+0xd8(600019a2650, 600019b0ac0, 3, 806000000000000, 0, 14) clprivnet_proto+0x90(60001835e78, 600019b0ac0, 158, 60001835e40, 1, 600019bcb30) clprivnet_wsrv+0xd0(600019a2650, 2a100237cc0, 0, 600019b0ac0, 1, 600019bcac0) runservice+0x40(600019a26b8, 2a100237cc0, 2000, 600019a26b8, 600019a2650, 20000) stream_service+0x5c(600018a2150, 300005c4a00, 600014109a0, 0, 600018a2010, 600019a2650) taskq_d_thread+0x88(600014109a0, 300005c4a00, 6000140b298, 0, 1b85fea3b8, 600014109d0) thread_start+4(600014109a0, 0, 0, 0, 0, 0)
OOps, das ist nicht gut! Zumal das Problem auch beim Reboot im Single User Mode auftrat. Hier sollte das Sun Engeneering dringend mal Ihre treiber zum Thema HA ansehen. Es kann ja nicht sein dass man so einfach nen Kernel töten kann? (Früher reichte es schon eine unbekannte Netzwerkkarte in den Rechner zu stecken, das ist anscheinend immer noch nicht besser geworden. Das erinnert an Microsoft Bluescreens von vor 5 Jahren).
Nun ja, die Lösung war einfach (habe ich aber erst später herausgefunden): man kann mit "OK> boot disk -x" in einem Stand-Alone non-cluster mode booten und dann mittels "scinstall -r" den cluster tilgen.
Was ich aber dabei gelernt habe: das neue boot-rc Framework von Solaris 10 (SMF) kann mittels -m argumente auf der boot command line gesteuert werden. Das Problem war nämlich, nachdem ich es geschafft hatte in den Single-User mode zu booten, gab es immer noch Kerneldumps. Zum Beispiel "-m verbose" oder aber "-m milestone=none". Letzteres ist vergleichbar mit dem emergency boot mode unter Linux. Um mit ALOM sicher ins OpenBootPROM zu gelangen bietet sich (in meiner Version der Sun Fire T1000) der Befehl "reset -c" an.
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
leider hast du die Berichte über Suns Try&Buy-Programm nicht mehr fortgeführt. Besonders hätte mich (und vielleicht auch andere) interessiert, ob die Rücknahme bei dir ähnlich komplikationslos verlaufen ist wie bei mir.
Hier von mir noch ein großes Lob an Sun für die absolut unkomplizierte und immer freundliche Abwicklung!
Gruss
Bernd
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-2013@eckenfels.net
Read More
2012-09-05 18:19
2012-09-05 17:53
2012-02-08 08:01
2012-02-04 17:28
2012-02-04 14:43
2012-02-04 14:25
2012-02-04 13:00
2012-02-04 10:59
