Hallo, On Sun, 08 Jun 2003, Al Bogner wrote: [..]

Hat vielleicht jemand auf meine 2. Frage auch eine Antwort: Was müsste man alternativ machen um den grsecurity-patch in einen 2.4.21-rc7-ac1-Kernel zu integrieren? Die "latest stable" bezieht sich ja auf 2.4.20

Ausprobieren. Falls es nicht klappt, versuchen es per Hand einzubauen. Oder abwarten, bis es einen aktualisierten patch gibt. -dnh --

(void *)'\0' Didn't you see the sign? It said VOID WHERE PROHIBITED Don't tell me you can't C. -- the Internet Oracle [#1307-01]

Hallo, On Sun, 08 Jun 2003, Al Bogner wrote:

On Sunday 08 June 2003 21:42, David Haller wrote:

...

On Sun, 08 Jun 2003, Al Bogner wrote:

...

Was müsste man alternativ machen um den grsecurity-patch in einen 2.4.21-rc7-ac1-Kernel zu integrieren? Die "latest stable" bezieht sich ja auf 2.4.20

Ausprobieren. Falls es nicht klappt, versuchen es per Hand einzubauen. Oder abwarten, bis es einen aktualisierten patch gibt.

schön, dass du dich wieder meldest.

Ja, sorry, ich bin irgendwie doch nicht dazugekommen, dir zu antworten... Hol ich noch nach...

In welcher Reihenfolge würdest du es probieren?

grsecurity-1.9.9h-2.4.20.patch dann patch-2.4.21-rc7.gz dann patch-2.4.21-rc7-ac1.gz?

Hm. Generell gilt beim patchen wohl eher: "die grossen zuerst"... Also wohl: -rc7, dann -rc7-ac1, dann den grsecurity... Bei Konflikten kann man dann noch variieren, z.B. den grsecurity zuerst. Wenn dessen Aenderungen dann von den weiteren dann unters "fuzz"/"offset"-limit fallen kann das patchen in der Reihenfolge klappen ;) Zur Not wuerde ich den grsecurity-patch per Hand einpflegen...

Ü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... Das loggt einem dann zwar wohl die logs voll, aber vielleicht findet man dort dann Hinweise auf das eigentliche Problem. Weiteres dann in den PMs, ok?

Ich habe auch mittlerweile die cvs-Version der mjpegtools installiert und nach wie vorzeitiges Abbrechen von mpeg2enc oder Crash. Da die Root-Partition aufgrund der vielen unterschiedl. Kernel, etc. voll geworden ist, muß ich umpartitionieren und neu installieren.

Bitte? Laesst sich da nicht noch wo ne Partition passend einhaengen? Schick mir mal per PM die Ausgabe von 'df' und 'ls -ld /'.

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]'...

Ich würde mich freuen, wenn du dir bei Gelegenheit mein PM ansiehst, und Vermutungen äußerst, warum es mit dem Laden des Soundkartenmoduls beim Hochfahren Probleme gibt.

Mach ich. -dnh -- 55: Fachhändler Student, 24 Jahre, Geologie (vormals Informatik), Gewerbeschein (15 DM), wohnt bei den Eltern (Kristian Köhntopp)

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

On Monday 09 June 2003 20:19, Thomas Hertweck wrote:

Auf LKML wurde vor kurzem ein neues Tool vorgestellt. Es heisst "Wiggle" und koennte hier von Nutzem sein:

Wiggle is a program for applying patches that 'patch' cannot apply due to conflicting changes in the original.

Download und weitere Beschreibung gibt es unter http://cgi.cse.unsw.edu.au/~neilb/source/wiggle/

Es gibt auch nun folgende Patches (siehe Forum): http://grsecurity.net/grsecurity-1.9.10-2.4.21.patch http://grsecurity.net/grsecurity-2.0-pre5-2.4.21.patch You will need the current cvs of gradm or gradm2 as well. Al