On Sun, 30 Nov 1997, Robert Frank wrote:

ich wollte mit Hilfe der Kernel-Patches (von ftp.gwdg.de)

41721 Nov 29 21:45 patch-2.0.32.gz 999854 Nov 29 21:44 patch-2.0.31.gz

von 2.0.30 auf 2.0.32. Verwendet habe ich /usr/src/linux/scripts/patch-kernel Wider Erwarten habe ich zig "*.rej" Files bekommen.

War das ein original 2.0.30 Kernel oder die lx-suse, die (nicht ohne Grund) immer wieder empfohlen wird ? Die Quellen aus lx-suse bauen zwar auf 2.0.30 auf, bieten aber einiges mehr: zusaetzliche Treiber, Fixes, ... -- sind also irgendwo zwischen 2.0.30 und 2.0.31. Was patch-kernel tut, weiss ich nicht, aber ich bringe patches lieber zu Fuss an: patch -p0 < wo/das/patchfile/liegt 2>&1 | more Die Option -p0 ist wichtig, dass neue Dateien mit Pfad angelegt werden statt im aktuellen Verzeichnis. Manchmal ist auch -p1 notwendig (wenn der Patch mit "linux/file..." anfaengt und man schon im Verzeichnis linux steht. Im more (less) suche ich dann nach "Hunk" und kontrolliere, ob ueberall "succeeded" steht (geht recht gut zu ueberfliegen -- less stellt die Fundstellen optisch heraus und ein "rejected" faellt aus der Reihe). Das ist zwar bei .31er Patch recht viel gewesen, aber was solls -- fehlerhafte Kernel nach der Uebersetzung fehlgeschlagener Patches kosten sicher mehr Zeit. Man kann im less ja auch nach rejected oder reverse suchen ... In Deinem Fall vermute ich, dass Du die lx-suse Quellen patchen wolltest. Das Kommando patch findet dann, dass die Aenderung so schon vorliegt; vermutet, der Nutzer haette beim Erstellen des Patch nur die Namen der zu vergleichenden Dateien (woher - wohin) vertauscht (das passiert wohl oft genug) und bietet an, den Patch "rueckwaerts" anzubringen -- die Aenderung also zurueckzunehmen. Je nach Aufruf- Optionen wird der Nutzer gefragt oder gar der Patch gleich angebracht (je nach Entscheidung des Programms vorwaerts oder rueckwaerts). Das Ergebnis ist entweder die Unsicherheit, ob alle Stellen herumgezogen sind oder ein Riesendurcheinander, wenn Patches vorwaerts UND rueckwaerts angebracht wurden. Deshalb ist bei "rejected" Files immer manuelle Kontrolle (oder "Do it again von vorn", s.u. :) angesagt. Die Loesung: originale Quellen 2.0.30 installieren, patchen, alles sollte fein sein und durch den Kompilator gehen ... (make config; make dep && make clean && make zImage && make modules && make modules_install; printf "\a"; arch/i386/boot/zImage und System.map kopieren und lilo.conf etc bearbeiten) BTW: Wenn's so passiert, ist der Unterschied nicht klar genug herausgekommen. Ich hab's zwar jetzt nicht nachgeprueft, aber die Pakete linux (?) und lx-suse sind beim Installieren zu weit auseinander, um als Alternativen (inklusive Darstellung der Differenzen und der Konsequenzen) erkannt zu werden. Laesst sich da was mit den Namenskonventionen machen (lexikografische Ordnung in der YaST-Liste) oder ein Fenster bei BEIDEN Kernelvarianten (oder drei inkl. lx-hack ?) aufblenden ("Sie installieren die originalen/erweiterten/allerletzten Kernelquellen") ? Oder man verpasst dem patch-kernel am besten einen Test, wer /usr/src/linux heute gerade ist. Das von mir als allererster Blick benutzte Kommando 'head /usr/src/linux/Makefile' versagt leider bei den SuSE Quellen. Sicher ist's schwierig, eine stimmige Bezeichnung zu finden. Aber WO sucht man nach um festzustellen, WELCHE Quellen denn nun vorliegen ? RPM nach den installierten Paketen zu befragen kann alle Varianten als installiert ausweisen. Den Link dann mit ll anzusehen, muss nicht immer stimmen -- seit den zwei patches liegen bei mir unter /usr/src/linux-2.0.30 die Quellen zur 2.0.32. Falls patch-kernel auch diesen Namen korrigiert, nehme ich natuerlich alles zurueck und behaupte das Gegenteil :) Ansonsten -- was kann man tun bzw welche Kriterien reichen hin, um ein lx-suse als solches zu erkennen ? -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.de schicken, mit dem Text: unsubscribe suse-linux