DS106j: Webinterface nach IPKG-Installation nicht mehr erreichbar

[Great Gatsby]

Hallo,

ich habe nach dem Update meiner Synology DS106j auf den DSM 3.1-1605, das soweit erfolgreich war (Webinterface funktionierte), wieder IPKG installieren wollen. Nach der IPKG-Installation gibt es jetzt aber folgendes

Problem: Das Webinterface meiner DiskStation funktioniert nicht mehr, per SSH anmelden kann ich mich zum Glück noch.

Der Versuch, Apache mittels /usr/syno/etc/rc.d/S97apache-user.sh restart manuell zu starten (meiner laienhaften Vorstellung nach der Server, über den auch das Webinterface betrieben wird?), bringt folgende Ausgabe:

DiskStation> /usr/syno/etc/rc.d/S97apache-user.sh restart
Start User Apache Server .....
httpd: Syntax error on line 483 of /usr/syno/apache/conf/httpd.conf: Cannot load /lib/libphp5.so into server: /lib/libphp5.so: undefined symbol: sqlite3_load_extension
/usr/syno/etc/rc.d/S97apache-user.sh: user httpd could not be started
DiskStation>

Jetzt bin ich etwas ratlos und auf Eure Hilfe angewiesen, fürchte ich ...

Bei der IPKG-Installation bin ich im Detail wie folgt vorgegangen: Ich bin ins Verzeichnis /volume1/public gewechselt und habe die entsprechende .xsh-Datei für meine DS106j heruntergeladen:

DiskStation> wget http://ipkg.nslu2-linux.org/feeds/optware/ds101g/cross/unstabl
e/ds101-bootstrap_1.0-4_powerpc.xsh
--2011-03-28 12:24:10--  http://ipkg.nslu2-linux.org/feeds/optware/ds101g/cross/unstable/ds101-bootstrap_1.0-4_powerpc.xsh
Resolving ipkg.nslu2-linux.org (ipkg.nslu2-linux.org)... 140.211.169.169
Connecting to ipkg.nslu2-linux.org (ipkg.nslu2-linux.org)|140.211.169.169|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1859267 (1.8M) [text/plain]
Saving to: `ds101-bootstrap_1.0-4_powerpc.xsh'

100%[======================================>] 1,859,267    151K/s   in 12s

2011-03-28 12:24:23 (146 KB/s) - `ds101-bootstrap_1.0-4_powerpc.xsh' saved [1859267/1859267]

Danach habe ich die .xsh-Datei ausgeführt:

DiskStation> sh ds101-bootstrap_1.0-4_powerpc.xsh
DS-10x Bootstrap extracting archive... please wait
bootstrap/
bootstrap/bootstrap.ipk
bootstrap/bootstrap.sh
bootstrap/ipkg.ipk
bootstrap/ipkg.sh
bootstrap/openssl.ipk
bootstrap/wget-ssl.ipk
10271+1 records in
10271+1 records out
Creating temporary ipkg repository... success
Installing DS101(g)-bootstrap package...Unpacking bootstrap.ipk...Done.
Configuring bootstrap.ipk...Regenerating dynamic linker cache...
/opt/sbin/ldconfig: /lib/libss.so.2 is not a symbolic link

/opt/sbin/ldconfig: /lib/libe2p.so.2 is not a symbolic link

/opt/sbin/ldconfig: /lib/libext2fs.so.2 is not a symbolic link

/opt/sbin/ldconfig: /lib/libuuid.so.1 is not a symbolic link

/opt/sbin/ldconfig: /lib/libcom_err.so.2 is not a symbolic link

/opt/sbin/ldconfig: /lib/libblkid.so.1 is not a symbolic link

Done.
 success
Installing IPKG package... (Ignore missing md5sum warning)
./ipkg.sh: line 1147: can't open /volume1/tmp/ipkg-bootstrap/ipkg.conf: no such file
Removing temporary ipkg repository...
Installing OpenSSL..Installing openssl (0.9.7m-5) to root...
Configuring openssl
Successfully terminated.
 success
Installing wget-SSL...Installing wget-ssl (1.12-2) to root...
Configuring wget-ssl
Successfully terminated.
 success
Setup complete...
If your network setup is correct, you should be able to do "ipkg update" to get the
full list of installable packages


BusyBox v1.16.1 (2011-03-24 02:15:54 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

DiskStation>

... und das Paketverzeichnis mit ipkg update heruntergeladen, gefolgt von einem Neustart der Station.

Nach dem Neustart habe ich /opt gelöscht, per ln -s /volume1/opt / das Mount (? - sagt man das so?) durch einen Symlink ersetzt und die /etc/rc.local wie folgt angepasst:

#!/bin/sh

## Optware setup
## mkdir -p /opt
## [ -e /volume1/opt ] && mount -o bind /volume1/opt /opt
## [ -x /opt/etc/rc.optware ] && /opt/etc/rc.optware
[ -e /bin/killall ] || ln -s /bin/busybox /bin/killall

Anschließend habe ich noch das Skript optware.sh in /usr/local/etc/rc.d angelegt, wie es hier empfohlen und beschrieben ist, und es mittels chmod +x /usr/local/etc/rc.d/optware.sh ausführbar gemacht.

Ergebnis nach erneutem Reboot: IPKG lässt sich per SSH normal ausführen, Webinterface der DiskStation ist tot.

Weitere Ausgaben (System-Log, System-Start-Log, ...) liefere ich natürlich gerne nach, sollte das jemandem helfen.

Für jeden noch so kleinen Hinweis dankbar,

Hackintosh HD

 

[Great Gatsby]

Nachtrag 1: Vor dem Update von DSM 3.0 auf DSM 3.1-1605 waren auf meiner DiskStation noch itaris AdminTool und OpenVPN installiert. Nach dem Update hatte ich sie noch nicht wieder in Betrieb genommen, will dies aber erwähnen, falls ich hier eine Abhängigkeit übersehe ...

Nachtrag 2: Ich kann das Webinterface wieder zum Laufen bringen, wenn ich mit rm opt den /opt-Symlink wieder entferne, das Skript optware.sh aus /usr/local/etc/rc.d lösche und die DiskStation neu starte. Dann funktioniert allerdings IPKG natürlich wieder nicht, was also keine wirkliche Lösung des Problems ist ...

 

[Great Gatsby]

Nachtrag 3: Mir ist noch aufgefallen, dass es eine Fehlermeldung erscheint, wenn ich zum Beispiel wget mit /volume1/opt/bin/wget aufrufe:

DiskStation /volume1/opt/bin/wget
/volume1/opt/bin/wget: error while loading shared libraries: libssl.so.0.9.7: cannot open shared object file: No such file or directory
DiskStation>

Ob das damit zu tun hat oder ein völlig anderes Problem ist, weiß ich nicht.

 

[goetz]

Hallo,
seit 3.1 gibt es ein Problem bei den alten powerpc Modellen mit der libphp5.so und ipkg/3rd_party. Den genauen Hintergrund habe ich noch nicht herausbekommen. Für mich habe ich folgende Lösung:
/lib/libphp5.so umbenennen und die libphp5.so der Version DSM 3.0 nach /lib kopieren. Dann klappt's auch mit ipkg und co.

Gruß Götz

 

[Great Gatsby]

Hallo,
seit 3.1 gibt es ein Problem bei den alten powerpc Modellen mit der libphp5.so und ipkg/3rd_party. Den genauen Hintergrund habe ich noch nicht herausbekommen. Für mich habe ich folgende Lösung:
/lib/libphp5.so umbenennen und die libphp5.so der Version DSM 3.0 nach /lib kopieren. Dann klappt's auch mit ipkg und co.

Hallo Götz, vielen Dank! - Nur zum Verständnis: Der neue Name der 3.1er-libphp5.so nach der Umbenennung spielt dann keine Rolle mehr, es dürfte (zum Beispiel) libphp5.so.3.1.backup sein, richtig?

Gibt es vielleicht einen Trick, wie man die libphp5.so des DSM 3.0 aus der entsprechenden .pat-Firmware-Datei extrahieren kann? Ich habe sie vor den Upgrade auf DSM 3.1 leider nicht gesichert ...

 

[Trolli]

Du kannst die .pat Datei einfach nach .tar umbenennen und mit einem geeigneten Packer extrahieren. Im Zweifelsfall mit 7-zip.

 

[Great Gatsby]

Das hat alles geklappt. Nach dem Ersetzen der libphp5.so des DSM 3.1-1605 mit der des DSM 3.0-1354 nach dem Tipp von goetz lässt sich IPKG installieren, ohne dass das Webinterface beeinträchtigt ist. Auch die oben erwähnte Fehlermeldung mit der libssl.so.0.9.7 verschwindet danach.

Die dafür benötigte 107er-Firmware 3.0-1354 gibt es übrigens noch hier, sie lässt sich wie von Trolli beschrieben (ebenfalls danke! ) umbenennen und mit 7-zip entpacken.

 

[jahlives]

Wegen dem Problem mit libssl: Vermutlich ist dein wget noch mit einer alten SSL Library gebaut worden. Seit DSM 3 verwendet Synology die 1-er Version von libssl. Habe bei meinem Mailserver auch noch Module welche eine ältere Version von libssl erwarten. Habe dazu einfach einen Symlink im lib Verzeichnis angelegt. Damit libssl.so.0.9.7 auf libssl.so.1.0.0 zeigt

 

[Great Gatsby]

Wegen dem Problem mit libssl: Vermutlich ist dein wget noch mit einer alten SSL Library gebaut worden. Seit DSM 3 verwendet Synology die 1-er Version von libssl. Habe bei meinem Mailserver auch noch Module welche eine ältere Version von libssl erwarten. Habe dazu einfach einen Symlink im lib Verzeichnis angelegt. Damit libssl.so.0.9.7 auf libssl.so.1.0.0 zeigt

Hallo jahlives, vielen Dank für diesen Hinweis!

Ich hatte in der Zwischenzeit mit der Forumssuche schon diesen Beitrag von goetz gefunden, den er in einem anderen Thread auf dieselbe Fehlermeldung als Tipp hatte. Ich bin dem Tipp gefolgt, d.h. ich habe in /opt/lib nur Symlinks auf die libssl.so.0.9.7 und die beiden anderen Bibliotheken, die ja in /lib liegen, angelegt (soweit ich die Befehle richtig interpretiert habe ). Das erschien mir jedenfalls nicht schädlich, weil mir noch auffiel, dass wget nur dann diese Fehlermeldung produziert, wenn man es inklusive absolutem Pfad, d.h. als "/volume1/opt/bin/wget" aufruft - ein einfaches "wget" brachte diese Fehlermeldung hingegen nicht.

Die Meldung wegen der angeblich nicht vorhandenen libssl.so.0.9.7 erscheint nun wie gesagt nicht mehr. Ob es die Symlinks oder die komplette Neuinstallation von IPKG nach Auswechseln der libphp5.so mit der Version des DSM 3.0 waren oder gleich beides, kann ich nicht sagen.

Auf jeden Fall nochmal ganz herzlichen Dank an Euch alle, Ihr habt mir sehr geholfen!

P.S.: Kann ich - zur "Forumspflege" sozusagen - meinen Thread hier irgendwie auf "gelöst" setzten, gibt es da Konventionen?

 

[jahlives]

Wenn der absolute Pfad von wget und nur das Kommando wget nicht denselben Fehler brachten/bringen, dann hast du mit Sicherheit mindestens 2 Versionen von wget auf der Platte. Mach mal ein which wget und schau ob der Pfad identisch ist zu dem Pfad unter opt. Wobei das kann ich mir eigentlich nicht vorstellen. Es sollte unter /usr/syno/bin ebenfalls ein wget der Firmware geben

 

[Great Gatsby]

Hallo jahlives, die Ausgabe von which wget ist bei mir:

BusyBox v1.16.1 (2011-03-24 02:15:54 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

DiskStation> which wget
/opt/bin/wget
DiskStation>

In /usr/syno/bin meiner DS-106j gibt es in der Tat auch noch ein weiteres wget:

DiskStation> cd /usr/syno/bin
DiskStation> ls -l wget
-rwxr-xr-x 1 root root 348336 Mar 23 19:57 wget
DiskStation>