Language Pack

[smurfer]

Hallo zusammen,

bin gerade dabei einen Testserver unter Linux (Cent OS 6 64 Bit) aufzusetzen. Der Domino 8.5.3 FP6 rennt auch.
Nun möchte ich das dt. Language Pack installieren. Da sieht auch erst mal alles gut aus. Wenn er dann aber loslegen will,
kommen folgende Fehlermeldungen ...


Dateien werden auf dem Domino Server ersetzt...

Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00663368 Handler2=0018984F InaccessibleAddress=00000000
EDI=00790C8C ESI=00000000 EAX=00000000 EBX=00480FF4
ECX=00790E1C EDX=00000000
EIP=003679F1 ES=0000002B DS=0000002B ESP=00790C4C
EFlags=00210246 CS=00000023 SS=0000002B EBP=00790DCC
Module=/lib/libc.so.6
Module_base_address=002EE000
Target=2_30_20070420_12448_lHdSMR (Linux 2.6.32-431.23.3.el6.x86_64)
CPU=x86 (1 logical CPUs) (0xef8db000 RAM)
JVMDUMP006I Processing Dump Event "gpf", detail "" - Please Wait.
JVMDUMP007I JVM Requesting System Dump using '/notes/notes_server_setup/CI3UADE/core.20141128.095147.16747.dmp'
JVMDUMP010I System Dump written to /notes/notes_server_setup/CI3UADE/core.20141128.095147.16747.dmp
JVMDUMP007I JVM Requesting Snap Dump using '/notes/notes_server_setup/CI3UADE/Snap0002.20141128.095147.16747.trc'
JVMDUMP010I Snap Dump written to /notes/notes_server_setup/CI3UADE/Snap0002.20141128.095147.16747.trc
JVMDUMP007I JVM Requesting Java Dump using '/notes/notes_server_setup/CI3UADE/javacore.20141128.095147.16747.txt'
JVMDUMP010I Java Dump written to /notes/notes_server_setup/CI3UADE/javacore.20141128.095147.16747.txt
JVMDUMP013I Processed Dump Event "gpf", detail "".

Folgendes Java ist installiert ...

java version "1.7.0_65"
OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Hat jmd. eine Idee?

Danke und Gruss
Thomas

[Pfefferminz-T]

Moin,

die empfohlene Reihenfolge ist

Domino Server installieren
Language Pack installieren
FixPack bzw. Interim Fixes installieren

Grüsse,
Thorsten

[smurfer]

Hallo Thorsten,

habe mal alles zurück gebaut. (Verzeichnisse umbenannt). Danach neu installiert.
Und danach sofort das LP. Leider mit denselben Fehlermeldungen.

Gruss
Thomas

[m3]

Ein unterstütztes OS würde vermutlich helfen.
Ev. SELinux nicht deaktiviert?

[smurfer]

dachte CentOS 6 (ist ja an sich Red Hat) würde unterstützt.
Windows Server wäre mir auch lieber. Bekomme ich aber nicht durchgesetzt!

SELinux status:                 disabled

Das war es leider auch nicht ...

[Micha B]

Wenn CentOS Red Hat wäre, würde es Red Hat heißen 

http://www-01.ibm.com/support/docview.wss?uid=swg27022468
http://www-01.ibm.com/support/docview.wss?uid=swg27007909

[smurfer]

schon klar!
Die Diskussion hatte ich mit unserem Linux Fachmann auch.

Er meinte, abgesehen vom kostenpflichtigen Support den Red Hat anbietet, gibt es da keinen
Unterschied.

[m3]

Schon mal mit dem konsolenbasierten Installer probiert?

[koehlerbv]

Die Diskussion hatte ich mit unserem Linux Fachmann auch.

Angesichts der Tatsache, dass in früheren Fällen die Installation dann doch geklappt hat, weil man Pakete aus einer Suse-Installation CentOS untergejubelt hat, würde ich den Begriff "Fachmann" bei dieser Aussage des Kollegen arg überdenken. DER macht dann auch andere Fehler.

Bernhard

[smurfer]

Hallo Bernhard,

soweit würde ich jetzt nicht gehen. Tatsache ist aber, dass ich wohl mit dem englischen Domino leben muss. Ist bei der Fehlersuche eh' besser. Trotzdem ärgerlich.

Ich habe noch einen 2. Linuxserver, der gleich aufgesetzt ist. Mal sehn', wie es sich da verhält ...

Gruss
Thomas

[stoeps]

Moin,

Was steht im jvm core dump?

Ich ändere in meinen centos demo Kisten meistens die /etc/redhat-release (es gibt halt doch Unterschiede).

Hast du mal in der Doku geschaut, die installer brauchen meist die libstdcc++5 und ein paar 32 bit compat Pakete

Schon mal mit ltrace getestet ob alle libs vorhanden sind?

[smurfer]

Hallo Christoph,

das muss ich mir erst mal in Ruhe anschauen.
Bin kein Linux Fachmann.

Danke aber schon mal!

Gruss
Thomas

[Zwen]

Haben es inzwischen hinbekommen. Der Tipp von stoeps sich den Java core dump genau anzuschauen, hats gebracht.
Dort sah man den Stack-Trace beim Absturz:
...
4XESTACKTRACE          at com/ibm/wizard/platform/linux/GenericLinuxCommands.statGetFileOwnerGroup(Native Method)
4XESTACKTRACE          at com/ibm/wizard/platform/linux/GenericLinuxCommands.listContents(GenericLinuxCommands.java:163)
...
Vom Methoden-Namen war ersichtlich, dass der Installer Probleme beim Auslesen der Ower/Group-Info von Dateien hatte.
Da hats dann auch gleich geklingelt. Die Server verwenden keine lokalen Benutzer, sondern holen sich die Infos über LDAP.
Sobald man den Notes-User und die Gruppe auch noch lokal in passwd/group eingetragen hatte ging es.

Die kritische Einstellung bzgl. CentOS kann ich im übrigen nicht nachvollziehen. Es ist mit Ausnahme von proprietären Red-Hat Paketen(die keinerlei Core-Funktionalitäten bereitstellen) absolut kompatibel zu RHEL.
Lediglich das Anpassen von /etc/redhat-release wie von stoeps beschrieben ist in manchen Fällen notwendig, damit bestimmte Installationsroutinen das Linux auch als Redhat erkennnen. Ich bin mir sicher, unser Problem tritt so 1:1 auch bei RHEL auf.

[Sebi087]

Hallo Zusammen,

hier würde ich gerne präzisieren:
CentOS ist Binärkompatibel zu RedHat und stellt somit CPU-Befehlssatzkompatibilität bereit.
Anwendungen die für RHEL kompiliert wurden sind ohne ernute Kompilierung auch unter CentOS lauffähig. Somit sind die beiden Betriebssysteme auf der Befehlsebene gleich. Selbst Treibermodelle für RHEL sind unter CentOS lauffähig.

Die beiden Betriebssysteme unterschieden sich allerdings in den Punkten des Support.
Während CentOS die Community Version darstellt und weitgehend ohne Support geliefert wird, stellt RedHat die commecial Variante dar.

Das IBM keine Community Variante eines Betriebssystems offziell supported dürfte sich eigentlich jeder ganz einfach selbst erklären können. Denn während RedHat einen immer gleichen Stand ausliefert sind Community Varianten so vielfältig wie ihre Entwickler.

Produktivsysteme sollten aus den Support Gründen IMMER nach den Richtlinien und Empfehlungen des Herstellers laufen. Denn auf diesen ist man im Zweifel angewiesen.

Meine Testkisten laufen teilweise auch auf CentOS und damit gibt es überhaupt keine Probleme.
Für produktive Systeme kann ich mir dies aber nicht leisten.

Viele Grüße,
Sebi

[Pfefferminz-T]

Der Support, die Bereitstellung von Updates und die Weiterentwicklung eines Produkts lassen sich halt auch nicht allein durch "Luft und Liebe" finanzieren... Neue Versionen, Updates und Bug fixes kommen oft um einiges später und für die produktive Nutzung im kommerziellen Bereich würde ich entsprechend immer RHEL oder SLES empfehlen.

Gruss,
Thorsten

[stoeps]

hier würde ich gerne präzisieren:
CentOS ist Binärkompatibel zu RedHat und stellt somit CPU-Befehlssatzkompatibilität bereit.

Geb ich dir an sich Recht, aber in einigen Installern / Skripten wird geprüft welches OS verwendet wird. Das kann z.B. der Inhalt von /etc/redhat-release sein und da steht halt CENTOS drin, oft reicht es da Red Hat reinzuschreiben.

Dass die Anwendung am Schluß laufen müsste (wegen Binärkompatibilität) ist richtig, aber diese Kleinigkeiten sind v.a. bei Skripten und Installern zu beachten.