[Eisfair] [e1] eiskernel 3.46.0 (Status 'stable') verfügbar - 3.16er Kernel für eisfair-1

[D. Oezbilen]

Hallo Thomas,

danke fuer deine zuegige Antwort.

ldd /sbin/insmod

zeigt:
         linux-vdso.so.1 (0x00007fff20bdf000)
         liblzma.so.5 => /usr/local/lib/liblzma.so.5 (0x00007fd040748000)
         libz.so.1 => /usr/local/lib/libz.so.1 (0x00007fd04052d000)
         libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 
(0x00007fd040062000)
         libc.so.6 => /lib64/libc.so.6 (0x00007fd03fcbb000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd03fa9e000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00007fd03f89a000)
         /lib64/ld-linux-x86-64.so.2 (0x00007fd04097c000)

Die Log-Datei:

  Copying /lib64/ld-linux-x86-64.so.2 to /tmp/initrd_mount.Ad2BOO8DKl/lib64.
  Copying /lib64/libc.so.6 to /tmp/initrd_mount.Ad2BOO8DKl/lib64.
  Copying /lib64/libdl.so.2 to /tmp/initrd_mount.Ad2BOO8DKl/lib64.
  Copying /lib64/libpthread.so.0 to /tmp/initrd_mount.Ad2BOO8DKl/lib64.
--- bis hierhin ident.

--- ab hier nicht mehr.
  Copying /usr/local/lib/libcrypto.so.1.1 to 
/tmp/initrd_mount.Ad2BOO8DKl/usr/local/lib.
  Copying /usr/local/lib/liblzma.so.5 to 
/tmp/initrd_mount.Ad2BOO8DKl/usr/local/lib.
  Copying /usr/local/lib/libz.so.1 to 
/tmp/initrd_mount.Ad2BOO8DKl/usr/local/lib.

Wobei:
/usr/local/lib ist bei mir ein ln -s -> /usr/lib64, es sind somit (s.u., 
bis auch libz.so.1) Org.-eis.-Dateien. Wobei libz.so.1 natuerlich das 
Uebel sein kann.

eis-setup liefert leider nur die zlib-dev.
___Welches Paket beinhaltet die eis-zlib?___

#####################
locate zeigt:

locate libcrypto.so.1.1
	/usr/lib/libcrypto.so.1.1
	/usr/lib64/libcrypto.so.1.1
#####################

obwohl locate (taegliche Ausfuehrung)

#####################
dies anzeigt:
locate liblzma.so.5
	/usr/lib/liblzma.so.5
	/usr/lib/liblzma.so.5.2.3
	/usr/lib64/liblzma.so.5
	/usr/lib64/liblzma.so.5.2.3
ist
	/usr/lib/liblzma.so.5

wech.
Nur die aus /usr/lib64 ist noch vorhanden. Da sowieso ein ln -s ist, so 
what. In der initrd ist eine liblzma.so.5 vorhanden, also nicht nur ein 
toter Link.
#####################

	md5deep /usr/lib64/liblzma.so.5
5a8e26d6e0b020dac1ed480b6ab729e8  /usr/lib64/liblzma.so.5

Selbiges auch fuer
	md5deep /usr/local/lib/libcrypto.so.1.1
f303c1d14ed0bb36c45593b556ba3e31  /usr/local/lib/libcrypto.so.1.1

//
Die Leute mit Problemen haben alle irgendwelche selbst installierten 
Bibliotheken unter /usr/local/lib zu liegen...
//

Nun, das sollte nicht dazu fuehren das System zu zerschiessen, oder?
Die Realitaet ist aber eine andere, es funkt nicht; da hast Du recht.

Zudem es auch das Kernel-dev Paket mit den sourcen gibt. Wozu ist dieses 
Paket, wenn ich nicht andere, die der Plattform fehlen nicht selber 
kompilieren kann, noch dazu ein Vanilla-Kernel?

Ich denke nicht, dass das Paket kernel-dev nur fuer eis-Entwickler 
gedacht ist? Oder doch?
Ich habe einige bins auf der neuen eis64 kompiliert, richtig.

Fuer z.B.
	libcrypto.so.1.1
kann ich belegen, dass kein anderes eigen kompiliertes Prg. (laut der 
installwatch-Logs) diese Datei angelegt hat oder (deswegen logs) eine 
andere libcrypto zu libcrypto.so.1.1 verlinkte.

liblzma.so.5 taucht weder als Datei noch als ein Link in den Log-Dateien 
der nach/eigen installierten Prg. auf.

zlib-1.2.11 ist es anders, ich habe zlib-1.2.11 nachgezogen

Laut Log:

3<----->open<-->/dev/tty<------>#success
3<----->open<-->/dev/tty<------>#success
3<----->open<-->/dev/tty<------>#success
3<----->open<-->/dev/tty<------>#success
3<----->open<-->/dev/tty<------>#success
4<----->open<-->/usr/lib64/libz.a<----->#success
3<----->open<-->/dev/tty<------>#success
3<----->open<-->/dev/null<----->#success
6505760>fopen64>/usr/lib64/sthQ1YiV<--->#success
0<----->rename<>/usr/lib64/sthQ1YiV<--->/usr/lib64/libz.a<----->#success
0<----->chmod<->/usr/lib64/libz.a<----->00644<->#success
0<----->chown<->/usr/lib64/libz.a<----->0<----->0<----->#success
0<----->chmod<->/usr/lib64/libz.a<----->00644<->#success
3<----->open<-->/dev/tty<------>#success
4<----->open<-->/usr/lib64/libz.so.1.2.11<----->#success
0<----->symlink>/data/opt/zlib-1.2.11/libz.so.1.2.11<-->/usr/lib64/libz.so<---->#success
0<----->symlink>/data/opt/zlib-1.2.11/libz.so.1.2.11<-->/usr/lib64/libz.so.1<-->#success
3<----->open<-->/dev/null<----->#success
4<----->open<-->/usr/share/man/man3/zlib.3<---->#success
4<----->open<-->/usr/lib64/pkgconfig/zlib.pc<-->#success
3<----->open<-->/dev/tty<------>#success
4<----->open<-->/usr/include/zlib.h<--->#success
4<----->open<-->/usr/include/zconf.h<-->#success

wird hier auf nachinstalliertes Prg. verlinkt.
0<----->symlink>/data/opt/zlib-1.2.11/libz.so.1.2.11<-->/usr/lib64/libz.so.1<-->#success

Kannst Du bitte angeben, warum es zu diesem Fehlgriff kommt?
Liegt es vllt. daran, dass ldconfig dies ausgibt?
	ldconfig: Path `/usr/lib64' given more than once

Wie kann ich fuer die zukueftigen Kernel-Updates diese Kollision vermeiden?
Doch nicht, in dem ich keine eigens kompilierten bins u. libs mehr dem 
System zufuege? ;-)

Zumindest habe ich einen Fehler, an dem ich wieder was Neues 
erfahren/lernen kann. :-)

Danke Dir vorab.
Derya