Hallo, On Mon, 09 Jun 2003, Al Bogner wrote:
On Sunday 08 June 2003 23:44, David Haller wrote:
Übrigens, mit dem selbst kompilierten 2.4.21-rc7-ac1 hatte ich auch die per PM diskutierten Probleme am Athlon.
*hrmpf* Da sollte man wohl mal einen "debugging" Kernel backen...
Ok, ich bin ja gerade fürs Kernel bauen aufgewärmt :-)
*g*
Bitte? Laesst sich da nicht noch wo ne Partition passend einhaengen?
Schwer. Der Rechner ist auch schon umpartitioniert und wieder installiert und die paar Konfigurationen werde ich morgen zurücksichern.
Achso ;)
Schick mir mal per PM die Ausgabe von 'df' und 'ls -ld /'.
Ich denke das hat sich nach der Neuinstallation erübrigt.
Jep.
Von der SuSE 8.2 habe/hatte ich ca. 3GB (viele Sourcen) installiert, dann kamen ein paar Mal die Kernel-Sourcen und andere Download-Sourcen hinzu, da ist man mit 4GB für root bald voll, wenn man nichts löschen will.
*tsss* Da formatiert man dann eben irgendeine Partition mit ext3, kopiert mittels 'tar cp --atime-preserve | (cd /mnt; tar xp --atime-preserve;)' irgendein "passendes" Verzeichnis (/opt, /usr/src, oder aehnliches) auf die neue Partition, macht ein mv /dir /dir_old[4], und mountet die neue Partition dann eben fortan unter /dir (und loescht nach Vergleich und Test dann /dir_old). Bei mir ist IIRC /var/<irgendwas> durch mindenstens 2 symlink-Ebenen auf irgend eine "passende" Partition verlinkt ;) Und /var/ selbst liegt unterhalb von /data[1]. Und /var/spool/news liegt wiederum auf ner anderen Partition... ;)) "Echt" auf / liegen sollten nur /bin, /dev, /etc, /lib, /root und /sbin, sowie (mindestens als mountpoints) /boot und /proc. Alles andere kann und darf a) ein mountpoint oder b) ein symlink sein. Eine normale /-Partition braucht somit (ohne grosse "Multikernel"-Orgien wie bei mir) nur ca. 200 MB. root@slarty[2]:~ (0)# df | grep '/$' /dev/hda2 1011960 179476 781076 19% / root@slarty[2]:~ (0)# du -hs /boot /tmp /lib/modules 44M /boot 6.4M /tmp 48M /lib/modules root@slarty[2]:~ (0)# du -hs /lib/modules/`uname -r` 4.7M /lib/modules/2.4.16-3 d.h. ca. ~85 MB (/boot + /lib/modules) von den 175 MB sind "Multikernel" bedingt, bleiben noch ~90 MB... Und in meinem /root faehrt einiges unnoetiges herum... Und /tmp kann (und IMO sollte man) nach /var/roottmp verlinken[2], denn wenn einem die /-Partition volllaeuft ist das unschoen, und eine eigene /tmp-Partition halte ich fuer Unfug[3]. Bleiben also noch ca. 80 MB die bei mir auf der /-Partition sinnvoll verwendet werden... Die Partition selbst ist (s.o.) ~1GB gross, ich hab halt im Moment dummerweise auch /tmp drauf, und ein bisschen goenne ich mir halt auch fuer meine alten Kernels ;))
Danach werde ich mich mal mit gdb auseinandersetzen.
Das klappt beim Kernel nicht. Bei anderen Programmen hilft meist schon ein 'strace' und/oder 'ltrace [-S]'...
Die Frage ist ja auch, ob der Kernel schuld ist.
Ja. Eigentlich halte ich das fuer eher unwahrscheinlich. Du scheinst bisher der einzige mit _diesem_ Problem zu sein... Daher mein Tip bzgl. [sl]trace, damit kann man in der Regel zumindest herausfinden, ob's eher an der Hardware, der normalen Software oder eben doch am Kernel liegt...
Nächste Woche besorge ich mir noch mal ein 3. Ram-Modul zum testen. Ich glaube bei mir ist es eine Kombination von Problemen.
Kann gut sein. Zumal bei dem Wetter die HW ja auch naeher am Limit laeuft als ueblich... Ist das zufaellig der erste Sommer fuer deine HW? ;) Das schoene an Linux ist IMO: du _kannst_ herausfinden, wo es "haengt"! Du kannst strace/ltrace verwenden, du hast die Quellen der SW, du hast die Kernelquellen, du kannst dir einen Kernel so geschwaetzig eingestellt kompilieren, dass die HDD kaum noch mit dem loggen hinterherkommt (was wiederum Bugs im HDD-Treiber ausloesen koennte ;))... Kurz: du hast _immer_ eine Chance das Problem zu analysieren -- wenn du dich selbst nicht genug auskennst um z.B. ein 'strace' auszuwerten oder in diversen Kernel-Treibern das Debugging anzuschalten, kannst du dich ja vertrauensvoll an "uns" wenden ;) Eine Loesung allerdings ist (leider) nicht immer moeglich... Wichtig ist v.a. eines: Geduld! "schnell schnell" und "neuinstallieren" bringt dich nicht weiter... -dnh, der sich morgen hoffentlich dazu aufraffen kann, die PMs endlich zu beantworten... *seufz* Hoffentlich kommt mir dann nicht gerade ein Gewitter dazwischen ;( [1] der Mountpoint ist zufaellig und "historisch" durch meine Umpartitioniererei bedingt. [2] Von der Funktion ist /var/tmp != /tmp, /var/tmp ist "persistent", /tmp sollte bei jedem reboot geloescht werden koennen... [3] wichtig ist IMO nur (siehe [2]), dass /tmp/ != /var/tmp ;) [4] Das 'mv' ist nicht "noetig" -- aber sinnvoll. Man kann die neue Partition auch einfach nur passend "drueber" mounten... Nur passiert dann evtl. eben folgendes: Ich hatte IIRC > 1 Jahr ein altes /usr "unter" dem gemounteten neuen /usr ;)) Irgendwann fiel mir auf, dass auf der /-Partition verdaechtig wenig Platz ist, bis es mir wie Schuppen aus den Haaren fiel: hey, da is ja noch das alte /usr "unter" dem neuen... Dummerweise laesst sich ein /usr/ nicht "mal eben" unmounten, ich habe also mal nach 'init S' booten muessen und dort dann das alte /usr/ geloescht (nach einer Kontrolle, ob da noch wichtiges/interessantes rumlag ;)) -- Du meinst, es gibt Menschen die vom Katzen so trainiert sind, das die die Katzen so erziehen das die machen was sie sowieso wollen, die Leute aber glauben lassen das die genau gehorchen. -- Rik Steenwinkel