Hallo Leute, ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk und cron festgestellt. Die Ausgabe von strace habe ich unten an die Mail angehängt [2] Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla fast alle der o. g. Programme laufen (außer cron). Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99. Beide Kernel werden mit append = "splash=verbose BOOT_FILE=/boot/vmlinuz vga=771 mem=192M hdc=ide-scsi" gebootet; eine initrd hat allerdings nur der SuSE-Kernel. Der Stand der Updates ist vom letzten Sonntag, da war u. a. ein cron-Update dabei - das hat das Problem aber weder ausgelöst noch beseitigt. Sprich: der Fehler tritt mit Original-cron (von CD) und auch mit dem Update (cron-3.0.1-824) auf. Kennt irgendjemand das Problem oder sogar die Ursache? Gruß Christian Boltz [1] 7.0 -> 7.2 -> 7.3 -> 8.1 -> 8.2 -> 9.0 [2] hier die strace-Logs (jeweils die letzten 20 Zeilen) ==> cron <== (bei beiden getesteten Kerneln gleiche Ausgabe mit Ausnahme der PID) brk(0x806f564) = 0x806f564 brk(0) = 0x806f564 brk(0x8070000) = 0x8070000 fstat64(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 _llseek(3, 0, [0], SEEK_CUR) = 0 flock(3, LOCK_EX|LOCK_NB) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 getpid() = 1777 write(3, "1777\n", 5) = 5 _llseek(3, 0, [5], SEEK_CUR) = 0 ftruncate(3, 5) = 0 setresuid32(0xffffffff, 0, 0xffffffff) = 0 stat64("/var/spool/cron", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 chdir("/var/spool/cron") = 0 stat64("tabs", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 fork() = 1778 --- SIGCHLD (Child exited) @ 0 (0) --- exit_group(0) = ? ==> hwclock <== (geht nur beim SuSE-Kernel schief) open("/usr/lib/locale/de_DE/LC_NUMERIC", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0 mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002f000 close(3) = 0 open("/usr/lib/locale/de_DE@euro/LC_CTYPE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=207996, ...}) = 0 mmap2(NULL, 207996, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40167000 close(3) = 0 geteuid32() = 0 open("/dev/rtc", O_RDONLY|O_LARGEFILE) = 3 close(3) = 0 stat64("/etc/adjtime", {st_mode=S_IFREG|0644, st_size=44, ...}) = 0 open("/etc/adjtime", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40030000 read(3, "0.000000 1067686982 0.000000\n106"..., 4096) = 44 close(3) = 0 munmap(0x40030000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ ==> ps <== (Probleme ebenfalls nur beim SuSE-Kernel) rt_sigaction(SIGABRT, {0x8049850, ~[], SA_RESTORER, 0x4005daa8}, NULL, 8) = 0 rt_sigaction(SIGTRAP, {0x8049850, ~[], SA_RESTORER, 0x4005daa8}, NULL, 8) = 0 rt_sigaction(SIGILL, {0x8049850, ~[], SA_RESTORER, 0x4005daa8}, NULL, 8) = 0 rt_sigaction(SIGHUP, {0x8049850, ~[], SA_RESTORER, 0x4005daa8}, NULL, 8) = 0 open("/proc/self/stat", O_RDONLY) = 3 read(3, "1788 (ps) R 1787 1787 1724 1025 "..., 1023) = 177 close(3) = 0 ioctl(1, TIOCGWINSZ, {ws_row=38, ws_col=118, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 geteuid32() = 0 open("/proc/uptime", O_RDONLY) = 3 lseek(3, 0, SEEK_SET) = 0 read(3, "287.98 244.74\n", 1023) = 14 --- SIGSEGV (Segmentation fault) @ 0 (0) --- write(2, "\n\nSignal 11 (SEGV) caught by ps "..., 133) = 133 exit_group(139) = ? ==> sleep <== (und schon wieder nur beim SuSE-Kernel) mmap2(NULL, 21499, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40028000 close(3) = 0 open("/usr/lib/locale/de_DE.ISO-8859-1/LC_TIME", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/de_DE.iso88591/LC_TIME", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/de_DE/LC_TIME", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2348, ...}) = 0 mmap2(NULL, 2348, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002e000 close(3) = 0 open("/usr/lib/locale/de_DE.ISO-8859-1/LC_NUMERIC", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/de_DE.iso88591/LC_NUMERIC", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/de_DE/LC_NUMERIC", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0 mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002f000 close(3) = 0 open("/usr/lib/locale/de_DE@euro/LC_CTYPE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=207996, ...}) = 0 mmap2(NULL, 207996, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401ef000 close(3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ --
Liegt nicht an meinem .spec. Das sagt jeder ;-) Naja, aber ich zu Recht ;)) Sagt auch jeder ;-) *SCNR* [> David Haller und Christian Boltz in fontlinge-devel]
Hallo, Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk und cron festgestellt. Die Ausgabe von strace habe ich unten an die Mail angehängt [2]
Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla fast alle der o. g. Programme laufen (außer cron). Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99.
Hm. Die strace sind wenig aufschlussreich, zumindest sehe ich da kein Muster... Teste mal, mit 'export LANG=C' (damit es schon mal nicht an den Locales liegen kann... Und dann verwende 'ltrace -f -s 64 -S -o <logdatei>' zum tracen. Und kannst du mal nen Kernel kompilieren? oder memtest laufen lassen? Hm. Hast du evtl. noch Reste der 8.2 glibc im System? -dnh -- Ich gebe meinen Kindern lieber Drogen als Windows -- Scott McNealy
Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk und cron festgestellt. [...]
SIGSEGV = segmentation fault = Sig 11 Die Programme versuchen, Speicher zu lesen (benutzen), der ihnen nicht zugewiesen wurde. Das ist oft ein Hinweis darauf, dass mit dem Speicher etwas nicht stimmt (wenn ein Bit kippt, dann kann schon mal ein Pointer, der in einem Programm benutzt wird, auf einmal ins Nirvana weisen, und Lesen oder Schreiben ins Nirvana geht selten gut). Schau Dir mal http://www.BitWizard.nl/sig11/ an, aber das kennst Du vielleicht schon. Evtl. findest Du da ja weitere Hinweise... Es koennte, wie David schon schrieb, auch an "Ueber- bleibseln" von aelteren Installationen liegen, wobei da wohl insb. die glibc in Frage kommt. IMHO ist es, genau wegen solchen Pro- blemen, oft besser, neu zu installieren - wenn $HOME auf einer eigenen Platte liegt und man Backups von Konfigurationseinstel- lungen hat, eigentlich relativ schnell erledigt... CU, Th.
Hallo David, hallo Leute, Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk und cron festgestellt. Die Ausgabe von strace habe ich unten an die Mail angehängt [2]
Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla fast alle der o. g. Programme laufen (außer cron). Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99.
Hm. Die strace sind wenig aufschlussreich, zumindest sehe ich da kein Muster... Teste mal, mit 'export LANG=C' (damit es schon mal nicht an den Locales liegen kann...
Das gibt bei cron (bis auf die PID) exakt dieselbe Ausgabe. Die anderen Programme kann ich gerade nicht testen, da ich mit dem funktionierenden Kernel arbeite ;-)
Und dann verwende 'ltrace -f -s 64 -S -o <logdatei>' zum tracen.
ltrace musste ich erst nachinstallieren ;-) Ich spar mir die Logdatei vorläufig mal, Grund siehe unten.
Und kannst du mal nen Kernel kompilieren?
Prinzipiell ja, aber heute nicht mehr ;-)
oder memtest laufen lassen?
siehe etwas weiter oben ;-) Und über Nacht will ich den memtest nicht laufen lassen, da der Computer recht nahe am Bett steht... Allerdings glaube ich eher weniger, dass es am RAM liegt. Grund: die Angaben meiner gestrigen Mail habe ich sofort nach dem Booten zusammengesammelt (hochgefahren, als root eingeloggt und gleich strace aufgerufen). Diesmal habe ich den ganzen Mittag am Computer gearbeitet, dabei auch munter den Swap gefüllt [1]. Es wäre schon mehr als Zufall, wenn cron genau am gleichen defekten (?) byte meines RAM scheitern würde ;-)
Hm. Hast du evtl. noch Reste der 8.2 glibc im System?
Laut rpm -V sind alle glibc-Pakete in Ordnung. "Alle" heißt dabei: glibc-locale-2.3.2-87 glibc-html-2.3.2-87 glibc-2.3.2-88 glibc-i18ndata-2.3.2-87 glibc-info-2.3.2-87 glibc-devel-2.3.2-87 rpm -qi auf diese Pakete meldet, dass sie alle zu SuSE 9.0 gehören. So, im Hintergrund lass ich gerade ein rpm -qf auf alle Dateien laufen, die bei pin -v 82 glibc gelistet wurden. Mal sehen, ob sich da was interessantes dabei findet... Erstmal das Uninteressante: außer einigen "file not found" (wie gesagt, die Dateiliste stammte (absichtlich) von der 8.2) habe ich nur Dateien gefunden, die auch zu den 9.0-RPMs gehören. Also keine unerwünschten Überbleibsel der 8.2 ;-) Hmm, mir ist wirklich gerade ein Fehler aufgefallen: /etc/cron.d, /etc/cron.hourly und /etc/cron.monthly haben gefehlt :-| Ich habe das filesystem.rpm neu installiert [2] und aus /root/.cvsrc die Option -P bei update entfernt (daher stammte das Problem vermutlich, Ratti dürfte sich über diese Mail freuen ;-) Inzwischen sieht es (mit meinem "alten" Kernel) wesentlich besser aus: root@tux:/tmp/segfault> rccron status Checking for Cron: running :-))) Was mit dem SuSE-Kernel der 9.0 passiert, prüf ich dann morgen nach, ich hab gerade keine Lust zum Rebooten ;-) Gruß Christian Boltz [1] kein Wunder, schließlich hatte ich Gimp (1.3), Konqueror, KMail, Mozilla und Netscape 4 gleichzeitig offen ;-) [3] Inzwischen sind Gimp, Mozilla und Netscape 4 wieder zu und der RAM wird munter fürs Caching benutzt, während noch einiges im Swap schlummert ;-) total used free shared buffers cached Mem: 191156 186744 4412 0 57208 55556 -/+ buffers/cache: 73980 117176 Swap: 417640 95728 321912 [2] das geht übrigens nur, wenn man das rpm auf die Platte kopiert und die CD vor dem Installieren umounted. Ansonsten bekommt man die folgende Fehlermeldung: root@tux:/tmp> rpm -Uhv --force filesystem-9.0-6.i586.rpm Preparing... ########################################### [100%] 1:filesystem ########################################### [100%] Fehler: unpacking of archive failed on file /media/cdrom: cpio: chown failed - Das Dateisystem ist nur lesbar Ach so, das --force ist natürlich nur, weil vorher die Meldung "already installed" erschienen ist ;-) [3] Ich bastle gerade an meiner privaten Homepage, und die soll unter möglichst vielen Browsern funktionieren ;-) (ich hab allerdings nix von "exakt gleich aussehen" gesagt, insbesondere was Netscape 4 angeht *g*) -- Was ist eine Diskette? Sind das die Dinger, die immer, wenn man sie braucht irgendeinen Fehler haben? [Timo Nentwig in suse-linux]
Hallo Leute, ich antworte mir mal selbst, das Problem ist nämlich noch nicht gelöst. Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk [...] festgestellt.
Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla [...] o. g. Programme laufen. Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99.
Der Meinung bin ich übrigens immer noch ;-)
Hm. Die strace sind wenig aufschlussreich, zumindest sehe ich da kein Muster... Teste mal, mit 'export LANG=C' (damit es schon mal nicht an den Locales liegen kann...
Und dann verwende 'ltrace -f -s 64 -S -o <logdatei>' zum tracen.
Hier die je letzten 30 Zeilen der ltrace-Ausgabe bei sleep und ps
(Parameter wie von Dir gewünscht, LANG=C, SuSE-Kernel 2.4.21-99)
==> ps_ltrace_LANG_C <==
1769 strcasecmp("unknown", "unix95") = 2
1769 strcasecmp("unknown", "unknown") = 0
1769 <... bsearch resumed> ) = 0x08057f88
1769 getenv("UNIX95") = NULL
1769 getenv("POSIXLY_CORRECT") = NULL
1769 getenv("POSIX2") = NULL
1769 geteuid(
Und kannst du mal nen Kernel kompilieren?
Hab ich gestern getestet (ebenfalls mit dem 2.4.16) - mehrere Durchläufe gingen problemlos, auch die Ausgabe von make war exakt gleich. Heute Abend hab ich übrigens die Kompilierung der kdelibs (CVS) laufen, läuft problemlos. (Ich brauch wohl nicht zu erwähnen, dass ich wieder meinen 2.4.16 in Betrieb habe?
oder memtest laufen lassen?
ca. 6 1/2 Stunden, ohne Befund
[...]
Gruß Christian Boltz PS@Thomas: Dein Link zu sig11-Ursachen ist eine interessante Lektüre, allerdings hab ich auf Anhieb nix "passendes" gefunden ;-) -- "Lege die eine Hand in die Gefriertruhe und die andere auf eine heiße Herdplatte. Im Durchschnitt ist das dann ein angenehmes Gefühl." [so erklärt mein Lehrer den "Durchschnitt"]
Hallo, Am Thu, 06 Nov 2003, Christian Boltz schrieb:
ich antworte mir mal selbst, das Problem ist nämlich noch nicht gelöst.
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk [...] festgestellt.
Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla [...] o. g. Programme laufen. Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99.
Der Meinung bin ich übrigens immer noch ;-)
Scheint so. Dummerweise kenne ich die SuSE-Kernels nicht genau genug. Aehm, sind dein *utils (bes. procps) usw. auf dem noetigen Stand? Und koenntest du evtl. einen Vanilla 2.4.21 mal testen?
Hm. Die strace sind wenig aufschlussreich, zumindest sehe ich da kein Muster... Teste mal, mit 'export LANG=C' (damit es schon mal nicht an den Locales liegen kann...
Und dann verwende 'ltrace -f -s 64 -S -o <logdatei>' zum tracen.
Hier die je letzten 30 Zeilen der ltrace-Ausgabe bei sleep und ps (Parameter wie von Dir gewünscht, LANG=C, SuSE-Kernel 2.4.21-99)
==> ps_ltrace_LANG_C <== [Anscheinend normaler Programmablauf, also kein Fehlerhandling etc.] 1769 setlocale(1, NULL) = "C" 1769 setlocale(1, "C") = "C" 1769 sscanf(0x080c4240, 0x0805dc82, 0xbffff3a8, 0xbffff3b0, 0x40038c9c
1769 --- SIGSEGV (Segmentation fault) --- 1769 fprintf(0x40160ee0, "\n\nSignal %d (%s) caught by ps (%s).\nPlease send bug reports t"..., 11, "SEGV", "procps version 3.1.11" 1769 SYS_write(2, "\n\nSignal 11 (SEGV) caught by ps (procps version 3.1.11).\nPlease "..., 133) = 133 1769 <... fprintf resumed> ) = 133 1769 _exit(139 1769 SYS_252(139, 0, 133, 0xbfffed30, 0x4008be4b) = -38 1769 SYS_exit(139 1769 +++ exited (status 139) +++ ==> sleep_ltrace_LANG_C <== [Anscheinend normaler Programmablauf, also kein Fehlerhandling etc.] 1764 getopt_long(2, 0xbffff4c4, "+", 0x0804a680, NULL) = -1 1764 getopt_long(2, 0xbffff4c4, "", 0x0804a3a8, NULL) = -1 1764 __errno_location() = 0x4019a360 1764 __strtod_internal(0xbffff65f, 0xbffff404, 0, 0x401311f1, 2
1764 --- SIGSEGV (Segmentation fault) --- 1764 +++ killed by SIGSEGV +++ Wenn ich mit meinem 2.4.16-vanilla boote, läuft alles problemlos
Das spricht dann fuer nen Kernel-Bug (und eben einem in einem der zwischen 2.4.16-vanilla und 2.4.21-SuSE)... Waere also gut, wenn du das eingrenzen koenntest. An der glibc hast du nicht geschraubt, oder? Denn sscanf bzw. __strod_internal sind glibc-Funktionen (bei syscalls wuerde die Praefix SYS_ verwendet werden, wie oben beim SYS_exit)... Und wie man weiter oben sieht werden syscalls aus der glibc beim 'ltrace -S' schoen aufgefuehrt (zu sehen z.B. am fprintf nach dem Segfault in ps). Der Segfault tritt also in der glibc auf... Da ich hier auch noch 2.4.16 (vanilla) verwende kann ich da auch nicht viel zu sagen (2.6.0-test* werde ich aber dann demnaechst mal testen, ich muss halt erst noch einiges andere aktualisieren ;)
Und kannst du mal nen Kernel kompilieren?
Hab ich gestern getestet (ebenfalls mit dem 2.4.16) - mehrere Durchläufe gingen problemlos, auch die Ausgabe von make war exakt gleich.
Heute Abend hab ich übrigens die Kompilierung der kdelibs (CVS) laufen, läuft problemlos. (Ich brauch wohl nicht zu erwähnen, dass ich wieder meinen 2.4.16 in Betrieb habe?
oder memtest laufen lassen?
ca. 6 1/2 Stunden, ohne Befund
Ein HW (speziell RAM) Problem kann man dann wohl auch erstmal auschliessen.
PS@Thomas: Dein Link zu sig11-Ursachen ist eine interessante Lektüre, allerdings hab ich auf Anhieb nix "passendes" gefunden ;-)
Hmjo, ich denke, hier sind die SuSEianer gefordert, speziell Thorsten und Philipp, die sich mit glibc und Kernel besser auskennen als ich. -dnh PS: Gibt's nen besonderen Grund fuer den neuen Kernel? Und dann fuer nen SuSE-Kernel? Und warum nicht gleich 2.6.*? -- Quatsch! Alle Spermien schwimmen zur Gebärmutter. Aber da die Gebärmutter nur ein Eheliches kind hatt, nämlich das mit dem gebärvater, darf auch nur dieses nach Hause kommen. Zusammen stellen sie dann den Neuen Menschen her. Oder so ähnlich. [WoKo in dag°]
David Haller schrieb:
[...] Das spricht dann fuer nen Kernel-Bug (und eben einem in einem der zwischen 2.4.16-vanilla und 2.4.21-SuSE)... Waere also gut, wenn du das eingrenzen koenntest.
Aber wie kann das ein Kernel-Bug sein beim SuSE 9.0 Standardkernel? Ich weiss, was Du denkst: mit dem Vanilla-Kernel geht es, dann muss es wohl am SuSE-Kernel liegen. So gesehen eine logische Schlussfol- gerung. Aber immerhin haben viele andere Leute ja nicht das Problem, dass die von Christian genannten Programme abstuerzen bei einer SuSE 9.0. Wenn dem so waere, dann haetten wir das auf suse-linux sicher schon mitbekommen, die SuSE 9.0 ist ja nun doch schon genug in Umlauf. Insofern kann es zumindest kein einfacher Bug sein, sondern muss ir- gendwie mit dem System von Christian verknuepft sein, sei es, dass die Hardware da eine entscheidende Rolle spielt oder aber die Tat- sache, dass nicht frisch installiert sondern upgedatet wurde... Ich kann mir daraus nicht wirklich einen Reim machen. Gruesse, Th.
Hallo David, hallo Thomas, hallo Leute, da bin ich wieder mit meinem Kernel ;-) Am Donnerstag, 06. November 2003 01:31 schrieb David Haller:
Am Thu, 06 Nov 2003, Christian Boltz schrieb:
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk [...] festgestellt.
Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla [...] o. g. Programme laufen. Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99.
Der Meinung bin ich übrigens immer noch ;-)
Scheint so. Dummerweise kenne ich die SuSE-Kernels nicht genau genug.
Aehm, sind dein *utils (bes. procps) usw. auf dem noetigen Stand
Das will ich bei SuSE 9.0 doch hoffen ;-) Ich hab grad mal ein for file in `rpm -qa` ; do rpm -qi $file | \ grep "Distribution: SuSE Linux 9.0" >/dev/null || echo $file ; done durchlaufen lassen - gibt eine Liste mit 27 Paketen. Wenn ich davon die uninteressanten Pakete (also Perl-Module, Doku usw.) rausstreiche, bleibt an möglicherweise interessanten Paketen: cdfs-0.5c-1 (für den "alten" vanilla kompiliert + checkinstall *duck*) idesmart-1.4-41 (von SuSE 8.2) nssv1-2.1.3-141 (stammt noch von SuSE 7.0 und enthält: (rpm -ql) /lib/libnss_compat.so.1 /lib/libnss_db.so.1 /lib/libnss_dns.so.1 /lib/libnss_files.so.1 /lib/libnss_nis.so.1 Alle anderen Pakete gehören zu SuSE 9.0
Und koenntest du evtl. einen Vanilla 2.4.21 mal testen?
Hatte ich vor und hab mir dann bei einem Bekannten mit DSL die Vanilla-Sourcen runtergeladen. Ich hab nur scheinbar schlecht gezielt, es ist ein 2.4.22 ;-) Jedenfalls: Auch mit dem neuen Vanilla-Kernel tauchen keine SegFaults auf - irgendwie hab ich das Gefühl, dass die Schuld wirklich beim SuSE-Kernel liegt... BTW, um auch das auszuschließen: rpm -V k_deflt findet keine Veränderungen am SuSE-Kernel. [...]
Und dann verwende 'ltrace -f -s 64 -S -o <logdatei>' zum tracen. [...] [Anscheinend normaler Programmablauf, also kein Fehlerhandling etc.]
1764 getopt_long(2, 0xbffff4c4, "+", 0x0804a680, NULL) = -1 1764 getopt_long(2, 0xbffff4c4, "", 0x0804a3a8, NULL) = -1 1764 __errno_location() = 0x4019a360 1764 __strtod_internal(0xbffff65f, 0xbffff404, 0, 0x401311f1, 2
1764 --- SIGSEGV (Segmentation fault) --- 1764 +++ killed by SIGSEGV +++ Wenn ich mit meinem 2.4.16-vanilla boote, läuft alles problemlos
Das spricht dann fuer nen Kernel-Bug (und eben einem in einem der zwischen 2.4.16-vanilla und 2.4.21-SuSE)... Waere also gut, wenn du das eingrenzen koenntest.
Wie gesagt, mit einem neuen Vanilla 2.4.22 läuft es. Die Kernelconfig habe ich weitgehend vom SuSE-Kernel übernommen, neue Optionen auf den Defaultwert. Einzige Änderung: ext3 und jfs sind fest einkompiliert.
An der glibc hast du nicht geschraubt, oder?
Nö, da lass ich die Finger davon ;-)
Denn sscanf bzw. __strod_internal sind glibc-Funktionen (bei syscalls wuerde die Praefix SYS_ verwendet werden, wie oben beim SYS_exit)... Und wie man weiter oben sieht werden syscalls aus der glibc beim 'ltrace -S' schoen aufgefuehrt (zu sehen z.B. am fprintf nach dem Segfault in ps). Der Segfault tritt also in der glibc auf...
Das macht die Sache wohl nicht einfacher ;-)
PS@Thomas: Dein Link zu sig11-Ursachen ist eine interessante Lektüre, allerdings hab ich auf Anhieb nix "passendes" gefunden ;-)
Hmjo, ich denke, hier sind die SuSEianer gefordert, speziell Thorsten und Philipp, die sich mit glibc und Kernel besser auskennen als ich.
Jepp - würde mich freuen, wenn jemand von SuSE mal drüberschaut ;-)
PS: Gibt's nen besonderen Grund fuer den neuen Kernel?
Naja, ich hab die SuSE 9.0 installiert und dann mal mehr spasseshalber den zugehörigen Kernel gebootet. Und die segfaults in so grundlegenden Programmen machen einen dann schon stutzig...
Und dann fuer nen SuSE-Kernel?
Gilt "Der bunte Rahmen gefällt mir"? ;-) Ansonsten s. o.
Und warum nicht gleich 2.6.*?
So experimentierfreudig bin ich beim Kernel nicht - wenn ich eine Beta [1] will, dann bei KDE ;-) Gruß Christian Boltz [1] Klar, Kernel 2.6.0 ist wohl offiziell nicht "Beta", aber eben auch noch verhältnismäßig wenig getestet. Und eine .0 beim Kernel versuche ich zu vermeiden ;-) --
Habe auch vor die Festplatte zu tauchen. Aber bevor ich diesen Tauch- prozess durchziehe, will ich auch eine andere Ursache nicht aus- schliessen, dass evtl. auch die Festplatte einen latenten Defekt hat. Hm, und in was taucht ihr die Festplatten? Heißwachs, Leinöl, ..? [> Pieter Wenk und Matthias Houdek in suse-linux]
Hallo, Am Fri, 21 Nov 2003, Christian Boltz schrieb:
Am Donnerstag, 06. November 2003 01:31 schrieb David Haller:
Am Thu, 06 Nov 2003, Christian Boltz schrieb:
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk [...] festgestellt. [..] Aehm, sind dein *utils (bes. procps) usw. auf dem noetigen Stand
Das will ich bei SuSE 9.0 doch hoffen ;-)
Ich hab grad mal ein for file in `rpm -qa` ; do rpm -qi $file | \ grep "Distribution: SuSE Linux 9.0" >/dev/null || echo $file ; done
*tsk* rpm -qa --queryformat "%{distribution}\t%{name}\n" | grep -vi '^suse' *scnr*
cdfs-0.5c-1 (für den "alten" vanilla kompiliert + checkinstall *duck*)
Sollte irrelevant sein.
idesmart-1.4-41 (von SuSE 8.2)
Ebenso.
nssv1-2.1.3-141 (stammt noch von SuSE 7.0 und enthält: (rpm -ql) /lib/libnss_compat.so.1 /lib/libnss_db.so.1 /lib/libnss_dns.so.1 /lib/libnss_files.so.1 /lib/libnss_nis.so.1
Was sagt ein 'rpm -qlv nssv1'? Und was ein 'ls -l /lib/libnss*1'? Und wenn das keine symlinks sind, was spuckt ein 'ldd lib/libnss_files.so.1' aus? Und das nssv1-2.1.3 ist ja offenbar von der glibc-2.1.3, das koennte mitbeteiligt sein...
Und koenntest du evtl. einen Vanilla 2.4.21 mal testen?
Hatte ich vor und hab mir dann bei einem Bekannten mit DSL die Vanilla-Sourcen runtergeladen. Ich hab nur scheinbar schlecht gezielt, es ist ein 2.4.22 ;-)
Passt schon. Waere halt geschickter gewesen wg. dem direkten Vergleich SuSE- vs. Vanilla-Kernel...
Jedenfalls: Auch mit dem neuen Vanilla-Kernel tauchen keine SegFaults auf - irgendwie hab ich das Gefühl, dass die Schuld wirklich beim SuSE-Kernel liegt...
BTW, um auch das auszuschließen: rpm -V k_deflt findet keine Veränderungen am SuSE-Kernel.
Hm. Ich kenn unpraktischerweise keine SuSE-Kernels mehr. Insbesondere, welche patches da alle reingepatcht werden... [..]
Das spricht dann fuer nen Kernel-Bug (und eben einem in einem der zwischen 2.4.16-vanilla und 2.4.21-SuSE)... Waere also gut, wenn du das eingrenzen koenntest.
Wie gesagt, mit einem neuen Vanilla 2.4.22 läuft es. Die Kernelconfig habe ich weitgehend vom SuSE-Kernel übernommen, neue Optionen auf den Defaultwert. Einzige Änderung: ext3 und jfs sind fest einkompiliert.
Wie gesagt, ein Test zwischen Vanilla 2.4.21 und SuSE 2.4.21 wuerde die Moeglichkeiten eben weiter einengen. Du koenntest evtl. nur den patch vanilla-2.4.21 -> vanilla-2.4.22 saugen und dann mit patch -R das Downgrade machen ;)
An der glibc hast du nicht geschraubt, oder?
Nö, da lass ich die Finger davon ;-)
S.o. libnss* gehoeren zur glibc. [..]
ps). Der Segfault tritt also in der glibc auf...
Das macht die Sache wohl nicht einfacher ;-)
Jup.
PS: Gibt's nen besonderen Grund fuer den neuen Kernel?
Naja, ich hab die SuSE 9.0 installiert und dann mal mehr spasseshalber den zugehörigen Kernel gebootet. Und die segfaults in so grundlegenden Programmen machen einen dann schon stutzig...
Jep.
Und dann fuer nen SuSE-Kernel?
Gilt "Der bunte Rahmen gefällt mir"? ;-) Ansonsten s. o.
Den patch fuer das bunte Zeug gibt's auch einzeln ;)
Und warum nicht gleich 2.6.*?
So experimentierfreudig bin ich beim Kernel nicht - wenn ich eine Beta [1] will, dann bei KDE ;-) [..] [1] Klar, Kernel 2.6.0 ist wohl offiziell nicht "Beta", aber eben auch noch verhältnismäßig wenig getestet. Und eine .0 beim Kernel versuche ich zu vermeiden ;-)
Och, ich hab damit eigentlich ganz gute Erfahrungen gemacht. 2.4.0-test1 lief bei mir gut, -test4 dann ueber nen Jahr problemlos. Der Aerger bei 2.4.x kam erst nach 2.4.2 IIRC. Naja, wenn ich mal die noetigen Tools aktualisiert habe und dann den 2.6.0 getestet habe kann ich ja berichten. -dnh -- Es kursiert ja immer noch die Behauptung, dass sendmail geschrieben wurde, weil sich jemand sein root-Passwort nicht merken konnte. -- A. Schreiber
Hallo David, hallo Leute, Am Samstag, 22. November 2003 00:05 schrieb David Haller:
Am Fri, 21 Nov 2003, Christian Boltz schrieb:
Am Donnerstag, 06. November 2003 01:31 schrieb David Haller:
Am Thu, 06 Nov 2003, Christian Boltz schrieb:
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb: >ich habe hier seit kurzem SuSE 9.0 Pro installiert (als > Update [1]) und das Problem, dass sich einige Programme mit > segfault "verabschieden". Bisher habe ich das Problem bei > den Programmen sleep, hwclock, ps, awk [...] festgestellt.
[..]
Aehm, sind dein *utils (bes. procps) usw. auf dem noetigen Stand
Das will ich bei SuSE 9.0 doch hoffen ;-)
Ich hab grad mal ein for file in `rpm -qa` ; do rpm -qi $file | \ grep "Distribution: SuSE Linux 9.0" >/dev/null || echo $file ; done
*tsk*
rpm -qa --queryformat "%{distribution}\t%{name}\n" | grep -vi '^suse'
*scnr*
Stimmt, das wäre schneller gegangen, wenn ich rpm besser kennen würde. Aber bevor ich sowas (für den einmaligen Gebrauch) im Manual nachschlage, lass ich lieber im Hintergrund einen lahmen Befehl laufen ;-)
nssv1-2.1.3-141 (stammt noch von SuSE 7.0 und enthält: (rpm -ql) /lib/libnss_compat.so.1 /lib/libnss_db.so.1 /lib/libnss_dns.so.1 /lib/libnss_files.so.1 /lib/libnss_nis.so.1
Was sagt ein 'rpm -qlv nssv1'?
cb@tux:~> rpm -qlv nssv1 -rwxr-xr-x 1 root root 142563 Jul 30 2000 /lib/libnss_compat.so.1 -rwxr-xr-x 1 root root 151798 Jul 30 2000 /lib/libnss_db.so.1 -rwxr-xr-x 1 root root 61648 Jul 30 2000 /lib/libnss_dns.so.1 -rwxr-xr-x 1 root root 205715 Jul 30 2000 /lib/libnss_files.so.1 -rwxr-xr-x 0 root root 204383 Jul 30 2000 /lib/libnss_nis.so.1
Und was ein 'ls -l /lib/libnss*1'? Und
cb@tux:~> ls -l /lib/libnss*1 -rwxr-xr-x 1 root root 142563 2000-07-30 21:42 /lib/libnss_compat.so.1* -rwxr-xr-x 1 root root 151798 2000-07-30 21:42 /lib/libnss_db.so.1* -rwxr-xr-x 1 root root 61648 2000-07-30 21:42 /lib/libnss_dns.so.1* -rwxr-xr-x 1 root root 205715 2000-07-30 21:42 /lib/libnss_files.so.1* -rwxr-xr-x 1 root root 204383 2000-07-30 21:42 /lib/libnss_nis.so.1*
wenn das keine symlinks sind, was spuckt ein 'ldd lib/libnss_files.so.1' aus?
cb@tux:~> ldd /lib/libnss_files.so.1 libc.so.6 => /lib/i686/libc.so.6 (0x40034000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Zur Info: cb@tux:~> rpm -qf /lib/i686/libc.so.6 glibc-2.3.2-88 cb@tux:~> rpm -qf /lib/ld-linux.so.2 glibc-2.3.2-88 cb@tux:~> rpm -q glibc glibc-2.3.2-88
Und das nssv1-2.1.3 ist ja offenbar von der glibc-2.1.3, das koennte mitbeteiligt sein...
Wie gesagt, das Paket stammt noch von der SuSE 7.0 und ist laut rpm -qi ein Kompatibilitätspaket: cb@tux:~> rpm -qi nssv1 # gekürzt Name : nssv1 Version : 2.1.3 Install date: Fr 13 Apr 2001 21:23:15 CEST Fällt mir jetzt erst auf - ich habe an einem Freitag, 13. mit Linux angefangen. Dafür läuft es aber erstaunlich gut ;-) Summary : NSS v1 libraries Description : With these libraries you should be able to execute glibc-2.0 programs in a glibc-2.1 environment. SuSE series: a Distribution: SuSE Linux 7.0 (i386) Frage zwischendurch: Würde es helfen, dieses Paket zu deinstallieren? IMHO nein, da ja die Vanilla-Kernel keine Probleme damit haben, oder? (und "einfach so" will ich nicht, es ist nämlich das letzte Paket, das noch von der 7.0 übrig ist ;-)
Und koenntest du evtl. einen Vanilla 2.4.21 mal testen?
Hatte ich vor und hab mir dann bei einem Bekannten mit DSL die Vanilla-Sourcen runtergeladen. Ich hab nur scheinbar schlecht gezielt, es ist ein 2.4.22 ;-)
Passt schon. Waere halt geschickter gewesen wg. dem direkten Vergleich SuSE- vs. Vanilla-Kernel...
Tja, knapp vorbei ist auch daneben ;-)
Jedenfalls: Auch mit dem neuen Vanilla-Kernel tauchen keine SegFaults auf - irgendwie hab ich das Gefühl, dass die Schuld wirklich beim SuSE-Kernel liegt...
BTW, um auch das auszuschließen: rpm -V k_deflt findet keine Veränderungen am SuSE-Kernel.
Hm. Ich kenn unpraktischerweise keine SuSE-Kernels mehr. Insbesondere, welche patches da alle reingepatcht werden...
Sehr viele ;-) In people/mantel/next: 35M linux-2.4.21.SUSE-19.tar.bz2 11M suse-2.4.21-19.bz2 Die Patches scheinen übrigens alle als ein großer Patch vorzuliegen - das macht mir das Experimentieren a la "nächster Patch rein, kompilieren, reboot" quasi unmöglich :-( Früher[tm] war das mal anders, da gabs einen Tarball mit einer Reihe von Einzelpatches, die man (soweit man durchblickte, was welcher Patch macht) selektiv einbauen konnte. Zumindest konnte man einen nach dem anderen integrieren, um nach Fehlern zu suchen.
Das spricht dann fuer nen Kernel-Bug (und eben einem in einem der zwischen 2.4.16-vanilla und 2.4.21-SuSE)... Waere also gut, wenn du das eingrenzen koenntest.
Wie gesagt, mit einem neuen Vanilla 2.4.22 läuft es. Die Kernelconfig habe ich weitgehend vom SuSE-Kernel übernommen, neue Optionen auf den Defaultwert. Einzige Änderung: ext3 und jfs sind fest einkompiliert.
Wie gesagt, ein Test zwischen Vanilla 2.4.21 und SuSE 2.4.21 wuerde die Moeglichkeiten eben weiter einengen. Du koenntest evtl. nur den patch vanilla-2.4.21 -> vanilla-2.4.22 saugen und dann mit patch -R das Downgrade machen ;)
Der Patch ist AFAIK auch einige MB groß - man merkt, dass Du DSL hast *g*
An der glibc hast du nicht geschraubt, oder?
Nö, da lass ich die Finger davon ;-)
S.o. libnss* gehoeren zur glibc.
Deshalb hab ich das Paket ja auch genannt. Allerdings dürfte es sich ja nicht mit der aktuellen glibc beißen, oder? Und vor allem: Wieso kommt der Fehler nur beim SuSE-Kernel?
[..]
ps). Der Segfault tritt also in der glibc auf...
Das macht die Sache wohl nicht einfacher ;-)
PS: Gibt's nen besonderen Grund fuer den neuen Kernel?
Naja, ich hab die SuSE 9.0 installiert und dann mal mehr spasseshalber den zugehörigen Kernel gebootet. Und die segfaults in so grundlegenden Programmen machen einen dann schon stutzig...
Jep.
Und dann fuer nen SuSE-Kernel?
Gilt "Der bunte Rahmen gefällt mir"? ;-) Ansonsten s. o.
Den patch fuer das bunte Zeug gibt's auch einzeln ;)
Wie gesagt, war teilweise auch Neugier ;-)
Und warum nicht gleich 2.6.*?
So experimentierfreudig bin ich beim Kernel nicht - wenn ich eine Beta [1] will, dann bei KDE ;-) [..] [1] Klar, Kernel 2.6.0 ist wohl offiziell nicht "Beta", aber eben auch noch verhältnismäßig wenig getestet. Und eine .0 beim Kernel versuche ich zu vermeiden ;-)
Och, ich hab damit eigentlich ganz gute Erfahrungen gemacht. 2.4.0-test1 lief bei mir gut, -test4 dann ueber nen Jahr problemlos. Der Aerger bei 2.4.x kam erst nach 2.4.2 IIRC. Naja, wenn ich mal die noetigen Tools aktualisiert habe und dann den 2.6.0 getestet habe kann ich ja berichten.
Jepp, würde mich auch mal interessieren. Aber ich glaube nicht, dass ich auf die Schnelle auf 2.6 umsteige - warum sollte ich? Gruß Christian Boltz --
... und der bildschirm unter kde3 ist sauschnell geworden im vergleich zur 7.3. Upps. Muß ich 'was b'sonderes beachten? Ich dachte eigentlich, daß der Monitor mit seinen 34 Kg nicht so schnell abhaut ... :-) [> Holger Poggel und Michael Nausch in suse-linux]
Hallo, Am Sun, 23 Nov 2003, Christian Boltz schrieb:
Am Samstag, 22. November 2003 00:05 schrieb David Haller:
Am Fri, 21 Nov 2003, Christian Boltz schrieb:
Am Donnerstag, 06. November 2003 01:31 schrieb David Haller:
Am Thu, 06 Nov 2003, Christian Boltz schrieb:
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller: > Am Sat, 01 Nov 2003, Christian Boltz schrieb: > >ich habe hier seit kurzem SuSE 9.0 Pro installiert (als > > Update [1]) und das Problem, dass sich einige Programme mit > > segfault "verabschieden". Bisher habe ich das Problem bei > > den Programmen sleep, hwclock, ps, awk [...] festgestellt. [..] Ich hab grad mal ein for file in `rpm -qa` ; do rpm -qi $file | \ grep "Distribution: SuSE Linux 9.0" >/dev/null || echo $file ; done
*tsk*
rpm -qa --queryformat "%{distribution}\t%{name}\n" | grep -vi '^suse'
*scnr*
Stimmt, das wäre schneller gegangen, wenn ich rpm besser kennen würde.
Merk dir einfach mal die beiden folgenden (zusammenhaengenden): rpm --querytags rpm -q --queryformat "%{TAG} ... \n" [ -a | paketname ] Die Abfragen, die du so machen kannst sind doch immer wieder erstaunlich praktisch. Beispiele findest du v.a. von mir einige in der Liste. Such mal nach 'From:.*dhaller' und nach 'queryformat' im body ;)
Aber bevor ich sowas (für den einmaligen Gebrauch) im Manual nachschlage, lass ich lieber im Hintergrund einen lahmen Befehl laufen ;-)
Jo, passt schon ;) Aber, gerade bei RPM denke ich mir eben auch: wozu setze ich das denn ueberhaupt ein? Genau, um eben solche Abfragen machen zu koennen! :)
nssv1-2.1.3-141 (stammt noch von SuSE 7.0 und enthält: (rpm -ql) /lib/libnss_compat.so.1 /lib/libnss_db.so.1 /lib/libnss_dns.so.1 /lib/libnss_files.so.1 /lib/libnss_nis.so.1
Was sagt ein 'rpm -qlv nssv1'?
cb@tux:~> rpm -qlv nssv1 -rwxr-xr-x 1 root root 142563 Jul 30 2000 /lib/libnss_compat.so.1 -rwxr-xr-x 1 root root 151798 Jul 30 2000 /lib/libnss_db.so.1 -rwxr-xr-x 1 root root 61648 Jul 30 2000 /lib/libnss_dns.so.1 -rwxr-xr-x 1 root root 205715 Jul 30 2000 /lib/libnss_files.so.1 -rwxr-xr-x 0 root root 204383 Jul 30 2000 /lib/libnss_nis.so.1
Und was ein 'ls -l /lib/libnss*1'? Und [.. praktisch das gleiche nochmal..]
wenn das keine symlinks sind, was spuckt ein 'ldd lib/libnss_files.so.1' aus?
cb@tux:~> ldd /lib/libnss_files.so.1 libc.so.6 => /lib/i686/libc.so.6 (0x40034000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Hm. [..]
Und das nssv1-2.1.3 ist ja offenbar von der glibc-2.1.3, das koennte mitbeteiligt sein...
Wie gesagt, das Paket stammt noch von der SuSE 7.0 und ist laut rpm -qi ein Kompatibilitätspaket:
cb@tux:~> rpm -qi nssv1 # gekürzt Name : nssv1 Version : 2.1.3 Install date: Fr 13 Apr 2001 21:23:15 CEST
Fällt mir jetzt erst auf - ich habe an einem Freitag, 13. mit Linux angefangen. Dafür läuft es aber erstaunlich gut ;-)
*g*
Summary : NSS v1 libraries Description : With these libraries you should be able to execute glibc-2.0 programs in a glibc-2.1 environment. SuSE series: a Distribution: SuSE Linux 7.0 (i386)
Uhoh. Les dir mal den "description"-Tag genau durch. Und schau dir an, was fuer eine glibc du verwendest...
Frage zwischendurch: Würde es helfen, dieses Paket zu deinstallieren?
Dazu kenn ich mich leider nicht gut genug mit der glibc aus. Ausschliessen, dass diese libnss* an deinen Problemen zumindest beteiligt sind wuerde ich jedenfalls nicht. "Eigentlich"[tm] sollte es ein libnss1-compat-2.3.2 geben... Und da bei der glibc die minor-Version so zu betrachten ist, wie bei anderen libs die major version und es bei dir also schon 2 stufen sind... Ich weiss noch, als ich ausversehen die glibc-2.2 in mein glibc-2.1.3 System installiert hab, hatte ich _arge_ Probleme... Hast du denn Programme, die diese libs brauchen? Und die du nicht "mal eben" neukompilieren kannst?
IMHO nein, da ja die Vanilla-Kernel keine Probleme damit haben, oder?
Im Zusammenhang mit der glibc ist das leider nicht eindeutig. Da sind aber wohl Philipp und insbes. Thorsten die besseren Ansprechpartner. Von Thorsten sind ja IIRC gerade Teile der (aktuellen) libnss* (oder verwechsel ich da jetzt libnss* mit nis[+]? ;)
(und "einfach so" will ich nicht, es ist nämlich das letzte Paket, das noch von der 7.0 übrig ist ;-)
Hm. Dann sollte ja eigentlich nix mehr diese libs brauchen... Wie oben angedeutet, es kann AFAIK durchaus sein, dass dir diese alten libnss dazwischenfunken. Mach doch ein Backup, und deinstalliere das RPM mal testhalber... [..]
Früher[tm] war das mal anders, da gabs einen Tarball mit einer Reihe von Einzelpatches, die man (soweit man durchblickte, was welcher Patch macht) selektiv einbauen konnte. Zumindest konnte man einen nach dem anderen integrieren, um nach Fehlern zu suchen.
ACK. Naja, ich verwende eh schon seit ca. 4 Jahren nur noch vanilla-Kernels, meist sogar ohne jegliche patches ;)
Wie gesagt, ein Test zwischen Vanilla 2.4.21 und SuSE 2.4.21 wuerde die Moeglichkeiten eben weiter einengen. Du koenntest evtl. nur den patch vanilla-2.4.21 -> vanilla-2.4.22 saugen und dann mit patch -R das Downgrade machen ;)
Der Patch ist AFAIK auch einige MB groß - man merkt, dass Du DSL hast *g*
Ich hab zwar ne DSL-Flatrate, ja, _ich_ lade mir (inzwischen(!)) auch "mal eben" nen neuen Kernel runter, der Patch 2.4.21-2.4.22 duerfte immernoch nur etwa 10% des kompletten 2.4.21 umfassen. Anders gesagt: ich habe das "wie mit 14.4 oder auch 56kbit Modem denken" nach wie vor "intus"[1]. Andersgesagt: was meinst du warum ich nicht geschrieben habe: saug dir bitte den 2.4.21... Wie gesagt, wenn du mal mit dem Vanilla 2.4.21 testen koenntest wuerde das die Menge der Moeglichen Ursachen von den 4-5 MB (als tar.bz2) 2.4.21-2.4.22 + SuSE patches auf nur noch die SuSE-patches einengen. Praktisch sage ich mir aber: wenn der Vanilla-2.4.22er bei dir laeuft, dann verwende einfach den ;)
An der glibc hast du nicht geschraubt, oder?
Nö, da lass ich die Finger davon ;-)
S.o. libnss* gehoeren zur glibc.
Deshalb hab ich das Paket ja auch genannt. Allerdings dürfte es sich ja nicht mit der aktuellen glibc beißen, oder?
"duerfte" nicht, aber moeglicherweise ist genau das der Fall...
Und vor allem: Wieso kommt der Fehler nur beim SuSE-Kernel?
Gute Frage, das, die ich dann gleich mal weiterreichen moechte ;)
PS: Gibt's nen besonderen Grund fuer den neuen Kernel? [..] Gilt "Der bunte Rahmen gefällt mir"? ;-) Ansonsten s. o. Den patch fuer das bunte Zeug gibt's auch einzeln ;) Wie gesagt, war teilweise auch Neugier ;-)
Achso. Na, dann biege deine Neugier mal besser von SuSE-Kernel auf 2.6 um, das lohnt sich eher ;)
Und warum nicht gleich 2.6.*? [..] Jepp, würde mich auch mal interessieren. Aber ich glaube nicht, dass ich auf die Schnelle auf 2.6 umsteige - warum sollte ich?
Es gibt einige gute Gruende... Zu einem Aspekt siehe z.B. http://bulk.fefe.de/scalability/. Ich denke jedenfalls, es lohnt sich, den (aktuellen!) vanilla(!) 2.6er mal zu testen... Ich muss halt bei mir wiedermal ein paar Utils aktualisieren, aber da kann ich diesmal die .specs der letzten Updates fuer 2.4.0-test* wiederverwerten :)) Es kann allerdings sein, dass ich wegen Hardware den 2.6er nur teste, und dann doch den 2.4er weiterverwende. Naja, mal schauen :) -dnh np: Blood, Sweat & Tears, Greatest Hits (fast alles live Aufnahmen)... Angefangen hab ich die Mail zu "I love you more than you'll ever know", inzwischen liefen "Lucretia McEvil", "And When I Die", "One Room Country Shack", "(I can recall) Spain", und grad laeuft "Hi-De-Ho"... :)) und ich war mal bei denen auf nem Konzert... zu 11en auf einer kleine Buehne IIRC ;) Whohohohouuyeaaahhh... [1] trotz Flatrate bin ich meist nur so lange wie noetig online, auch wenn ich dann auch mal ein paar GB ISO-Images am Stueck sauge. Mein erstes Modem war damals[tm] ein 14.4er, dann kam das 56k Modem, das ich auch noch regelmaessig verwende, wenn ich bei meiner Mutter bin. Und ich kann mich noch sehr gut an meine prae-DSL Zeiten erinnern, wenn ich fast jedes Byte einzeln per Handschlag habe begruessen koennen... Ich bin aber froh, dass ich hier DSL habe. -- You're right - what should we care about silly things like counting votes when we're in a war to preserve democracy. And mind that you don't say anything against the current resident because that would undermine our efforts to preserve freedom. -- Paul Tomblin
Hallo David, hallo Leute, vorweg: das Problem ist gelöst ;-) Am Sonntag, 23. November 2003 03:09 schrieb David Haller:
Am Sun, 23 Nov 2003, Christian Boltz schrieb:
Am Samstag, 22. November 2003 00:05 schrieb David Haller:
Am Fri, 21 Nov 2003, Christian Boltz schrieb:
Am Donnerstag, 06. November 2003 01:31 schrieb David Haller:
Am Thu, 06 Nov 2003, Christian Boltz schrieb:
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz: > Am Sonntag, 2. November 2003 00:13 schrieb David Haller: > > Am Sat, 01 Nov 2003, Christian Boltz schrieb: > > >ich habe hier seit kurzem SuSE 9.0 Pro installiert (als > > > Update [1]) und das Problem, dass sich einige Programme > > > mit segfault "verabschieden". Bisher habe ich das > > > Problem bei den Programmen sleep, hwclock, ps, awk [...] > > > festgestellt.
[..]
Ich hab grad mal ein for file in `rpm -qa` ; do rpm -qi $file | \ grep "Distribution: SuSE Linux 9.0" >/dev/null || echo $file ; done [...] rpm --querytags rpm -q --queryformat "%{TAG} ... \n" [ -a | paketname ]
Die Abfragen, die du so machen kannst sind doch immer wieder erstaunlich praktisch. Beispiele findest du v.a. von mir einige in der Liste. Such mal nach 'From:.*dhaller' und nach 'queryformat' im body ;)
Inzwischen hab ich das auch einigermaßen kapiert ;-)
Und das nssv1-2.1.3 ist ja offenbar von der glibc-2.1.3, das koennte mitbeteiligt sein...
Wie gesagt, das Paket stammt noch von der SuSE 7.0 und ist laut rpm -qi ein Kompatibilitätspaket:
cb@tux:~> rpm -qi nssv1 # gekürzt Name : nssv1 Version : 2.1.3 Install date: Fr 13 Apr 2001 21:23:15 CEST
Fällt mir jetzt erst auf - ich habe an einem Freitag, 13. mit Linux angefangen. Dafür läuft es aber erstaunlich gut ;-)
*g*
Summary : NSS v1 libraries Description : With these libraries you should be able to execute glibc-2.0 programs in a glibc-2.1 environment. SuSE series: a Distribution: SuSE Linux 7.0 (i386)
Uhoh. Les dir mal den "description"-Tag genau durch. Und schau dir an, was fuer eine glibc du verwendest...
Ich weiß.
Frage zwischendurch: Würde es helfen, dieses Paket zu deinstallieren?
Dazu kenn ich mich leider nicht gut genug mit der glibc aus.
Ausschliessen, dass diese libnss* an deinen Problemen zumindest beteiligt sind wuerde ich jedenfalls nicht. "[...]
Wie es aussieht, ist die libnss* unschuldig ;-)
Hast du denn Programme, die diese libs brauchen? Und die du nicht "mal eben" neukompilieren kannst?
Das nicht, aber...
"einfach so" will ich nicht, es ist nämlich das letzte Paket, das noch von der 7.0 übrig ist ;-)
... das sind einfach "historische" Gründe ;-)
[..]
Früher[tm] war das mal anders, da gabs einen Tarball mit einer Reihe von Einzelpatches, die man (soweit man durchblickte, was welcher Patch macht) selektiv einbauen konnte. Zumindest konnte man einen nach dem anderen integrieren, um nach Fehlern zu suchen.
ACK. Naja, ich verwende eh schon seit ca. 4 Jahren nur noch vanilla-Kernels, meist sogar ohne jegliche patches ;)
Oder so ;-)
Wie gesagt, ein Test zwischen Vanilla 2.4.21 und SuSE 2.4.21 wuerde die Moeglichkeiten eben weiter einengen. Du koenntest evtl. nur den patch vanilla-2.4.21 -> vanilla-2.4.22 saugen und dann mit patch -R das Downgrade machen ;)
Der Patch ist AFAIK auch einige MB groß - man merkt, dass Du DSL hast *g*
Ich hab zwar ne DSL-Flatrate, ja, _ich_ lade mir (inzwischen(!)) auch "mal eben" nen neuen Kernel runter, der Patch 2.4.21-2.4.22 duerfte immernoch nur etwa 10% des kompletten 2.4.21 umfassen. Anders gesagt: ich habe das "wie mit 14.4 oder auch 56kbit Modem denken" nach wie vor "intus"[1]. [...]
Schon klar, aber ich versuche Downloads > 2 MB zu vermeiden. Für (deutlich) größere Sachen fahr ich dann lieber ein paar km zu einem Bekannten mit DSL-Flat ;-)
Praktisch sage ich mir aber: wenn der Vanilla-2.4.22er bei dir laeuft, dann verwende einfach den ;)
*g*
Und vor allem: Wieso kommt der Fehler nur beim SuSE-Kernel?
Gute Frage, das, die ich dann gleich mal weiterreichen moechte ;)
Der Fehler stammte wohl eindeutig vom SuSE-Kernel. Lösung: Ich hab heute mal die neuesten Updates eingespielt, u. a. auch ein Kernel-Update - und siehe da, Problem gelöst.
PS: Gibt's nen besonderen Grund fuer den neuen Kernel? [..] Gilt "Der bunte Rahmen gefällt mir"? ;-) Ansonsten s. o.
Den patch fuer das bunte Zeug gibt's auch einzeln ;)
Wie gesagt, war teilweise auch Neugier ;-)
Achso. Na, dann biege deine Neugier mal besser von SuSE-Kernel auf 2.6 um, das lohnt sich eher ;)
Mal sehen. Derzeit fehlt mir aber leider die Zeit dazu.
Und warum nicht gleich 2.6.*? [..] Jepp, würde mich auch mal interessieren. Aber ich glaube nicht, dass ich auf die Schnelle auf 2.6 umsteige - warum sollte ich?
Es gibt einige gute Gruende... Zu einem Aspekt siehe z.B. http://bulk.fefe.de/scalability/.
Muss ich mir irgendwann mal durchsehen.
np: Blood, Sweat & Tears, Greatest Hits (fast alles live Aufnahmen)... Angefangen hab ich die Mail zu "I love you more than you'll ever know", inzwischen liefen "Lucretia McEvil", "And When I Die", "One Room Country Shack", "(I can recall) Spain", und grad laeuft "Hi-De-Ho"... :)) und ich war mal bei denen auf nem Konzert... zu 11en auf einer kleine Buehne IIRC ;) Whohohohouuyeaaahhh...
Tja, lange Mails brauchen ihre Zeit ;-)
[1] [...] Und ich kann mich noch sehr gut an meine prae-DSL Zeiten erinnern, wenn ich fast jedes Byte einzeln per Handschlag habe begruessen koennen...
*g* Gruß Christian Boltz -- [Grundrechte] Natürlich gibt's da auch das berühme Recht auf freie Entfaltung. Andererseits: setzt das nicht auch zwingend vorraus, daß man vorher auch gehörig zusammengefaltet wurde? ;-) [Gerard Jensen in suse-linux]
participants (3)
-
Christian Boltz -
David Haller -
Thomas Hertweck