Gibbet eigentlich ab und zu mal Patches für aktuelle Kernel von SGI? Die CVS Sourcen sind für mich mit ner ISDN Leitung ein wenig groß. Könnte ist natürlich in der Firma ziehen, aber da habe ich keine Linux
Und dass SGI ständig für AC's und pre-Kernel Patches backt kannst du nicht erwarten.
Würden sie wahrscheinlich auch nie machen, da SGI die offiziellen Patches immer gründlich testet, was Zeit kostet - und du weist ja in welchen Abständen AC's und pre's released werden können ...
>Und warum soll sich ein >Update für ReiserFS >besonders lohnen? Ich habe >damit noch keine Probleme >gehabt!
Ich hab/hatte ein ziemliches Problem mit ReiserFS. Mein Konqeror ist dauernd abgestürzt, als ich ein bestimmten Verzeichnis geöffnet hab. Dann hab ich meinen Rechner mit einem Linux von CD gebootet und von da aus meine HD mit reiserfsck gecheckt. Daraufhin hat dieser auch um die 20Fehler in irgendwelchen "Bitmaps" angezeigt. Dann habe ich reiserfsck mit soner Reparaturoption gestartet. Es kam ne Meldung, dass das Programm Betacode sei und bla bla. Naja, nachdem diese Reparatur (scheinbar) erfolgreich ablief, hab ich mein System neugestartet und mein KDE, und mein X haben ziemlichen schaden genommen. Dann hab ich noch feststellen können, dass mein System plötzlich nen anderen Kernel benutzt (SuSE-StandartKernel) und mein gcc auch ziemlich im Arsch ist....
P.S. Dank an ReiserFS und die ganzen Leute, die es als so ausgereift angepriesen haben. *i*
Bei mir bedeutet dies, dass ich boote, dann ein "bereits installiertes System" von "/dev/hdXX" boote und dann repariere. Hat bei ner neuen IBM-23xer-Server-Maschine geholfen, wo SuSE zwar anstandslos bootete und installierte, danach aber beim ersten booten den Adaptec-Controller nicht mehr erkennen wollte und --> "Kernel Panic". Nach _meiner_ Art des "von CD booten" hab ich nen neuen 2.4.5er Kernel übersetzt und es lief. Wer weiss, was du gemacht hast, fest steht, dass auch SuSE nicht von sich aus den Kernel überschreibt! Hatte noch nie ReiserFS-Probleme und wenn dem bei dir so war, dann haste wohl mit dem FSCK schlicht und ergreifend die lilo.conf überbügelt!
Du Glücklicher. Ich bekam Meldungen wie: "key in inode ... and key in entry ... do not match"
Nach einem Check des Dateisystems (--rebuild-tree) hatte ich den lustigen Effekt, daß an die verschiedensten Dateien irgendeine wilde Zeichenkette angehängt wurde. Unangenehm war das deswegen, weil z.B. X seine Tastaturbelegung nicht mehr laden konnte. Die einzige Möglichkeit, die ich sah, den Schaden zu reparieren, war, die installierten Pakete zu überbügeln. Egal wie, so etwas darf nicht geschehen. Man stelle sich vor, daß wäre nicht mit meinem Heimrechner sondern mit dem Server auf Arbeit passiert - schauder.
@Anonymous Du scheinst dich mit Dateisystemen auszukennen, außerdem benutze ich nie Standartkernel (Ich hab den 2.4.5er von kernel.org benutzt).
@Jens Ich habe eine SuSE-CD (Install, keine Live) eingelegt, und bin von da aus in die Shell gegangen. Dann hab ich mir reiserfsck auf dem temp. FS "installiert" und reiserfsck gestartet. Danach habe ich reiserfsck - dummerweise(?) - mit der Option --rebuild-tree gestartet und da hatte ich den Salat...Lilo hab ich seit mind. zwei Wochen nicht mehr gestartet...
>>Nach einem Check des Dateisystems (--rebuild-tree) hatte ich den lustigen Effekt, daß an die verschiedensten Dateien irgendeine wilde Zeichenkette angehängt wurde. Unangenehm war das deswegen, weil z.B. X seine Tastaturbelegung nicht mehr laden konnte. Die einzige Möglichkeit, die ich sah, den Schaden zu reparieren, war, die installierten Pakete zu überbügeln. Egal wie, so etwas darf nicht geschehen. Man stelle sich vor, daß wäre nicht mit meinem Heimrechner sondern mit dem Server auf Arbeit passiert - schauder.<<
@ddp Dies ist aber kein Problem von reiserfs, sondern am reiserfsck, welches auch als ausdrücklich als Alpha markiert ist. Solche Fehler sind fast garantiert.
>Dies ist aber kein Problem >von reiserfs, sondern am >reiserfsck, welches auch >als ausdrücklich als Alpha >markiert ist. Solche Fehler >sind fast garantiert.
Naja, aber reiserfsck (meine Version ist im Betastadium => also nicht nur für Entwickler) benutzt ja iirc eigentlich fast nur reiserfs-Funktionen, die auch die Kerneltreiber benutzen. Und wenn ich einen Fehler im fs habe, muss ich den ja logischerweise irgendwie korrigieren, sonst hab ich vielleicht noch eher Datenverlust.
Wow, die haben mal wieder beste Arbeit geleistet. BTW: Würde eigentlich (rein hypothetisch) der Windows-Quellcode dem wine-projekt helfen? Oder um ein natives Modul für den Kernel zu coden, um win32 binaries zu startem?
Derzeit sind die auf jede Menge Reverse-Engineering und rumprobieren angewiesen. Mit der Verfügbarkeit der Windows-Quellen würde die Arbeit der Entwickler an bestimmten Stellen sicherlich deutlich erleichtert werden.
werf mal ainen Blick auf: http://phobos.fs.tum.de/acpi/bios.sql
Mein Mainboard (msi6120) läuft mit den Kerneln der letzten sechs Monate sehr stabil, die einzigen Probleme, die ich vorher hatte, waren Shutdownfehler).
bringt mir als Desktop-User eigentlich die Aktualisierung des Kernels etwas ? Ich hab im Moment den SuSE 7.2-Default-Kernel drauf und alls funktioniert. Es heisst doch eigentlich "Never change a running system..."
2.4.5 hatte etwas Probleme mit der Speicherzuteilung, ich glaube da lohnt sich ein Upgrade schon. Zudem ist ein Upgrade nicht schwer, dauert bei mir ca. 10 Minuten. (make oldconfig ist Klasse....)
make oldconfig #bei patch-upgrade sonst make menuconfig make bzImage && make bzImage modules modules_install cp arch/i386/boot/bzimage /boot/bzimage-2.4.6 #dann /etc/lilo.conf anpassen lilo
Fertig.
Aber X-4.1 ist VIEEL besser als X-4.03, da die Schriftenglättung besser schneller und bei mehr Karten funktioniert. Außerdem ist die 3D-Beschleunigung nochmal höher und sauberer.
Vorsicht, für 3D-Beschleunigung muß man sich die Module seperat vom Kernel backen... (In /usr/src/kernel-modules/drm bei SuSE)
Debian User: Bei mir erzeugt der neue 2.4.6er in Verbindung mit den alsa-source0.9+0beta4-5 einen Oops: -- snip -- Trace; c0129413 Trace; c012fb34 Trace; c01b199e Trace; c01b1a04 Trace; c0129672 Trace; c0129698 Trace; c0114d1d Trace; c0106a8b Code; e09ffea6 00000000 : Code; e09ffea6 <===== 0: 0f b6 42 28 movzbl 0x28(%edx),%eax <===== -- snip -- Ich vermute, das hängt mit dem Patch von Collin Park (3. Jul. 23:59 LKML) zusammen. Auf LKML wurde auch mal über eine geänderte PCI-Funktion geredet, Aber jemand meinte, die sei rückwärtskompatibel.
@Stefan: die AC-Patches sind von Alan Cox erstellte Patches der gerade aktuellen Kernel-Version. Da sind sind neue Bugfixes und Features meist schon sehr zeitnah enthalten.
Ach übrigens 2.4.6-ac1 ist grad raus. Nur 12 Stunden nach offiziellem Release von 2.4.6 ;-)
Alan's kernel can be seen as a test bed for Linus' kernels. While Linus is very conservative and only applies obvious and well tested patches to the 2.4 kernel, Alan maintains a set of kernel patches that contains new concepts, more and/or newer drivers, and more intrusive patches. If the patches prove themselves stable, Alan submits them to Linus to include them into the official kernel.
Ist mit Reiser eigentlich ein automatisches verkleinern / vergroessern des Dateisystems im laufenden Betrieb möglich bzw. etwas schlechter im abgeschalteten System ?
Vergroessern geht ohne Probleme im laufenden System. (resize_reiserfs). AFAIK geht verkleinern bis jetzt nur "offline", d.h. wenn das Filesystem nicht gemountet ist.
Mit den Optionen kompiliert mit denen der 2.4.5er noch richtig gut lief. Der nvidia-3d-treiber will auch nicht. RedHat 7.1, gcc 3.0, asus k7v133 Sehr seltsam das.. mal sehen obs noch andere betrifft.
hier keine Probleme! (gleiches Board, gleicher Treiber, hab' aber kein RedHat - selbst der Philips-Webcam-Patch geht ohne Murren, nach Entfernen der "Kernel-Verstümmelungen".
GCC-3.0 ist NICHT binärkompatibel zu GCC-2.XX ! Das heisst, das ALLE Bibliotheken (Libraries) neu übersetzt werden müssen ! Da die nVidia-Treiber nur als Binäre, vorkompilierte Bibliothek vorliegen, funktioniert das Ganze halt nicht mit GCC-3.0 ! Meine Empfehlung: Auf GCC-2.95.3 zurückrüsten und Abwarten bis a) nVidia GCC-3.0 konforme Treiber hat und b) XFree86 GCC-3.0 konform ist und c) KDE ebenfalls GCC-3.0 konform ist.
Mal ne bescheidene Frage, brauche ich diese modutils2.4.6 dann auch? Wenn ja,warum? Hatte bis jetzt auch nie daran gedacht sie zu aktualiesieren. Gruß Udo
Vor dem Kompilieren hab ich nun den Pfad verändert, gcc -v liefert jetzt den gcc 2.96. Der so kompilierte Kernel zeigt die gleichen Probleme: der Nvidia-3d-treiber läßt sich nicht starten "failed to initialize DMA-page". Und andere Programm brechen mit einem segfault ab, ich bekomme die Register/stacks ausgegeben, der Rechner bleibt benutzbar.
Kernelquellen-verzeichnis gelöscht, quellen neu installiert und mit 2.96 kompiliert. Binutils etc. vom redhat7.1 sollten aktuell genug sein, habe trotzdem die neuesten versionen installiert... 246 läuft jetzt.
schon unter scsi devices musst aber glaub ich aktivieren dass du auch teile verwenden willst die nicht ganz ganz ganz sicher durgetestet sind (wie bei reiser auch)
ich habe lvm-0.9beta7 im Einsatz. Ich kann zwar den Kernel 2.4.6 wunderbar übersetzen, bekomme danach aber mein lvm nicht mehr zum laufen (kernel hat di 0.9beta2 drin). Nach patch mit lvm-0.9beta7 bekomme ich aber den kern nicht mehr übersetzt. Hat das Problem schon mal einer gelöst??
G. zooo
Auf jeden Fall heißt es jetzt täglich auf SGIs XFS seite zu luschern, bis ein patch für 2.4.6 da ist
Oder den CVS auschecken:
cvs -d :pserver:cvs@oss.sgi.com:/cvs login (das Passwort ist "cvs")
cvs -z3 -d :pserver:cvs@oss.sgi.com:/cvs co linux-2.4-xfs/linux
Der CVS steht nämlich derzeit auf 2.4.6pre9, und 2.4.6pre9 == 2.4.6 Final.
dann erkläre mir bitte, warum das Changelog der Final leer ist?
Konkreter ?
@ McClane
Für 2.4.5 gibts doch einen Patch:
ftp://oss.sgi.com/projects/xfs/download/patches/
Und dass SGI ständig für AC's und pre-Kernel Patches backt kannst du nicht erwarten.
Würden sie wahrscheinlich auch nie machen, da SGI die offiziellen Patches immer gründlich testet, was Zeit kostet - und du weist ja in welchen Abständen AC's und pre's released werden können ...
z.B. eine komplette Umstellung auf devfs.
Kernel-threads waren auch schon mal im gespräch.
Die SGI'ler haben inzwischen einen Patch gebastelt:
http://oss.sgi.com/projects/xfs/ mail_archive/0107/msg00117.html
ftp://oss.sgi.com/projects/xfs/ download/patches/linux-2.4.6-xfs-07052001.patch.bz2
Aber in der Mail heisst es:
[...]
Note that this is a SNAPSHOT of the DEVELOPMENT tree, and does not represent a stable code release.
[...]
Funktioniert trotzdem bestens, aber für alle Paranoiden ...
Aenderungen gabs in Folgenden Dateien:
: Makefile
drivers/char : Config.in
drivers/mtd/nand : Config.in spia.c
drivers/pcmcia : yenta.c
drivers/sound : i810_audio.c
fs/ext2 : ialloc.c
fs : namei.c
fs/proc : base.c
include/linux : pci.h pci_ids.h
mm : mmap.c
(also ein recht kleines delta, fuer genaueres koennt ihr euch ja auch mal selbst mit diff in verbindung setzen...)
dieses kleine detail ist wichtig für die anwendung der ac-patches, da diese sich auf das letzte stable-release des linus-branch beziehen...
hoffe, geholfen zu haben,
Tosk
Ooopsala, danke für den Hinweis, der Vertipper wurde korrigiert.
Cheers,
Wolfgang
"ReiserFS pre-allocation locking bugfix"
sein.
Ich hab/hatte ein ziemliches Problem mit ReiserFS. Mein Konqeror ist dauernd abgestürzt, als ich ein bestimmten Verzeichnis geöffnet hab. Dann hab ich meinen Rechner mit einem Linux von CD gebootet und von da aus meine HD mit reiserfsck gecheckt. Daraufhin hat dieser auch um die 20Fehler in irgendwelchen "Bitmaps" angezeigt. Dann habe ich reiserfsck mit soner Reparaturoption gestartet. Es kam ne Meldung, dass das Programm Betacode sei und bla bla. Naja, nachdem diese Reparatur (scheinbar) erfolgreich ablief, hab ich mein System neugestartet und mein KDE, und mein X haben ziemlichen schaden genommen. Dann hab ich noch feststellen können, dass mein System plötzlich nen anderen Kernel benutzt (SuSE-StandartKernel) und mein gcc auch ziemlich im Arsch ist....
P.S. Dank an ReiserFS und die ganzen Leute, die es als so ausgereift angepriesen haben. *i*
Bei mir bedeutet dies, dass ich boote, dann ein "bereits installiertes System" von "/dev/hdXX" boote und dann repariere. Hat bei ner neuen IBM-23xer-Server-Maschine geholfen, wo SuSE zwar anstandslos bootete und installierte, danach aber beim ersten booten den Adaptec-Controller nicht mehr erkennen wollte und --> "Kernel Panic". Nach _meiner_ Art des "von CD booten" hab ich nen neuen 2.4.5er Kernel übersetzt und es lief.
Wer weiss, was du gemacht hast, fest steht, dass auch SuSE nicht von sich aus den Kernel überschreibt!
Hatte noch nie ReiserFS-Probleme und wenn dem bei dir so war, dann haste wohl mit dem FSCK schlicht und ergreifend die lilo.conf überbügelt!
jens
> gehabt!
Du Glücklicher.
Ich bekam Meldungen wie: "key in inode ... and key in entry ... do not match"
Nach einem Check des Dateisystems (--rebuild-tree) hatte ich den lustigen Effekt, daß an die verschiedensten Dateien irgendeine wilde Zeichenkette angehängt wurde. Unangenehm war das deswegen, weil z.B. X seine Tastaturbelegung nicht mehr laden konnte. Die einzige Möglichkeit, die ich sah, den Schaden zu reparieren, war, die installierten Pakete zu überbügeln. Egal wie, so etwas darf nicht geschehen. Man stelle sich vor, daß wäre nicht mit meinem Heimrechner sondern mit dem Server auf Arbeit passiert - schauder.
Du scheinst dich mit Dateisystemen auszukennen, außerdem benutze ich nie Standartkernel (Ich hab den 2.4.5er von kernel.org benutzt).
@Jens
Ich habe eine SuSE-CD (Install, keine Live) eingelegt, und bin von da aus in die Shell gegangen. Dann hab ich mir reiserfsck auf dem temp. FS "installiert" und reiserfsck gestartet. Danach habe ich reiserfsck - dummerweise(?) - mit der Option --rebuild-tree gestartet und da hatte ich den Salat...Lilo hab ich seit mind. zwei Wochen nicht mehr gestartet...
@ddp
Dies ist aber kein Problem von reiserfs, sondern am reiserfsck, welches auch als ausdrücklich als Alpha markiert ist. Solche Fehler sind fast garantiert.
Dariush
> Und warum soll sich ein Update für ReiserFS
> besonders lohnen? Ich habe damit noch keine
> Probleme gehabt!
Vielleicht:
Kernel Bug at journal.c:423 ?
Liess sich nach einem bisschen Googeln auch von Hand loesen, aber ein sauberer kerneltree ist schon schoener.
MfG, Gernot
Naja, aber reiserfsck (meine Version ist im Betastadium => also nicht nur für Entwickler) benutzt ja iirc eigentlich fast nur reiserfs-Funktionen, die auch die Kerneltreiber benutzen. Und wenn ich einen Fehler im fs habe, muss ich den ja logischerweise irgendwie korrigieren, sonst hab ich vielleicht noch eher Datenverlust.
BTW: Würde eigentlich (rein hypothetisch) der Windows-Quellcode dem wine-projekt helfen? Oder um ein natives Modul für den Kernel zu coden, um win32 binaries zu startem?
Schön mal der erste in einem Forum zu sein;-)
MfG,
Sascha
Naja, viel wird sich seither nicht geaendert haben...
http://www.404.ch/elite/winsource.htm
Sascha
Derzeit sind die auf jede Menge Reverse-Engineering und rumprobieren angewiesen.
Mit der Verfügbarkeit der Windows-Quellen würde die Arbeit der Entwickler an bestimmten Stellen sicherlich deutlich erleichtert werden.
Hat ACPI schon mal jemand getestet? Bisher, hoerte ich nur man soll es nicht verwenden.
acpi ist afaik noch nicht stabil
Mein Mainboard (msi6120) läuft mit den Kerneln der letzten sechs Monate sehr stabil, die einzigen Probleme, die ich vorher hatte, waren Shutdownfehler).
Dariush
bringt mir als Desktop-User eigentlich die Aktualisierung des Kernels etwas ? Ich hab im Moment den SuSE 7.2-Default-Kernel drauf und alls funktioniert. Es heisst doch eigentlich "Never change a running system..."
So long,
Stefan
Wenn du allerdings ReiserFs einsetzt und die Notwendigkeit hast diese Partitionen per NFS zu exportieren, lohnt sich u.U. schon ein Update.
2.4.5 hatte etwas Probleme mit der Speicherzuteilung, ich glaube da lohnt sich ein Upgrade schon. Zudem ist ein Upgrade nicht schwer, dauert bei mir ca. 10 Minuten.
(make oldconfig ist Klasse....)
make oldconfig
#bei patch-upgrade sonst make menuconfig
make bzImage && make bzImage modules modules_install
cp arch/i386/boot/bzimage /boot/bzimage-2.4.6
#dann /etc/lilo.conf anpassen
lilo
Fertig.
Aber X-4.1 ist VIEEL besser als X-4.03, da die Schriftenglättung besser schneller und bei mehr Karten funktioniert. Außerdem ist die 3D-Beschleunigung nochmal höher und sauberer.
Vorsicht, für 3D-Beschleunigung muß man sich die Module seperat vom Kernel backen... (In /usr/src/kernel-modules/drm bei SuSE)
-- snip --
Trace; c0129413
Trace; c012fb34
Trace; c01b199e
Trace; c01b1a04
Trace; c0129672
Trace; c0129698
Trace; c0114d1d
Trace; c0106a8b
Code; e09ffea6
00000000 :
Code; e09ffea6 <=====
0: 0f b6 42 28 movzbl 0x28(%edx),%eax <=====
-- snip --
Ich vermute, das hängt mit dem Patch von Collin Park (3. Jul. 23:59 LKML) zusammen.
Auf LKML wurde auch mal über eine geänderte PCI-Funktion geredet, Aber jemand meinte, die sei rückwärtskompatibel.
Any hints?
(vieleicht bringt ja 0.9 beta5 was)
-Gregor
http://Hell.WH8.TU-Dresden.De/~gjadm/
tix.64
Danke,
Stefan
die AC-Patches sind von Alan Cox erstellte Patches der gerade aktuellen Kernel-Version. Da sind sind neue Bugfixes und Features meist schon sehr zeitnah enthalten.
Ach übrigens 2.4.6-ac1 ist grad raus. Nur 12 Stunden nach offiziellem Release von 2.4.6 ;-)
tix.64
Von den Alan Cox-Patches:
Aus http://www.kernelnewbies.org/faq/:
What about the ac (Alan Cox) series of patches ?
Alan's kernel can be seen as a test bed for Linus' kernels. While Linus is very conservative and only applies obvious and well tested patches to the 2.4 kernel, Alan maintains a set of kernel patches that contains new concepts, more and/or newer drivers, and more intrusive patches. If the patches prove themselves stable, Alan submits them to Linus to include them into the official kernel.
ftp://ftp.kernel.org/pub/linux/ kernel/people/alan/2.4
http://www.kernelnewbies.org/ changelogs/index.php3?2.4.5ac
http://www.bzimage.org
Vielen Dank für die Infos !!!
Gruß,
Stefan
-pre9:
[...]
- merge with Alan (including MIPS update)
[...]
-pre6:
[...]
- Alan Cox: merging, merging, merging
verkleinern / vergroessern des Dateisystems
im laufenden Betrieb möglich bzw. etwas schlechter im abgeschalteten System ?
System. (resize_reiserfs).
AFAIK geht verkleinern bis jetzt nur "offline", d.h. wenn das Filesystem nicht
gemountet ist.
Der nvidia-3d-treiber will auch nicht.
RedHat 7.1, gcc 3.0, asus k7v133
Sehr seltsam das.. mal sehen obs noch andere betrifft.
Der Kernel scheint gut gelungen zu sein.
Das heisst, das ALLE Bibliotheken (Libraries) neu übersetzt werden müssen !
Da die nVidia-Treiber nur als Binäre, vorkompilierte Bibliothek vorliegen, funktioniert das Ganze halt nicht mit GCC-3.0 !
Meine Empfehlung:
Auf GCC-2.95.3 zurückrüsten und Abwarten bis a) nVidia GCC-3.0 konforme Treiber hat und b) XFree86 GCC-3.0 konform ist und c) KDE ebenfalls GCC-3.0 konform ist.
Gruss
Z. Beeblebrox
Ach was solls, dann hab ich eben 3 Versionen zur Auswahl
brauche ich diese modutils2.4.6 dann auch?
Wenn ja,warum?
Hatte bis jetzt auch nie daran gedacht sie zu aktualiesieren.
Gruß Udo
ich hab gehöhrt das das kernel kompilieren mit gcc 3.0 noch etwas problematisch ist ...
bis denn
Gruss,
djp
Der so kompilierte Kernel zeigt die gleichen Probleme: der Nvidia-3d-treiber läßt sich nicht starten "failed to initialize DMA-page". Und andere Programm brechen mit einem segfault ab, ich bekomme die Register/stacks ausgegeben, der Rechner bleibt benutzbar.
Der Referenzcompiler ist immer noch egcs 1.1.2 / gcc 2.91.66 (kgcc).
Compilier mal mit dem - sollten die Fehler dann immer noch auftreten, kannst du sicher sein, dass es nicht am Compiler liegt.
Binutils etc. vom redhat7.1 sollten aktuell genug sein, habe trotzdem die neuesten versionen installiert... 246 läuft jetzt.
Danke für die Tipps
Mit 2.4.4 gab es dieses Problem nie, hoffentlich ist es beim neuen 2.4.6 Kernel behoben.
gibt es eigenlich eine Unterstützung für Fibrechannel
Karten? ich bin jedenfalls noch
nicht fündig geworden.
mfg Tom
Es gibt schon 2.4.7pre2 und 2.4.6ac1
------------snip------------
-pre2:
- merge with Alan (USB, zoran, sony motion-eye, rio, dmi-scan)
-pre1:
- merge with Alan (irda, s390, mips64, chris, sk98lin, mips/mm)
- rth: fix alpha RTC calibration
- Paul Mackerras: fix PPC typo
-----------snap--------------
Alles klar?
Na dann "happy hacking"
moses
für XFS ist der patch 2.4.6 raus
kann mir jemand erklären was die Option MTD Support auf sich hat
ich dachte mal , die ungraden versionen wären hacker versionen?
Gilt das heute nimmer?
ich habe lvm-0.9beta7 im Einsatz. Ich kann zwar den Kernel 2.4.6 wunderbar übersetzen, bekomme danach aber mein lvm nicht mehr zum laufen (kernel hat di 0.9beta2 drin). Nach patch mit lvm-0.9beta7 bekomme ich aber den kern nicht mehr übersetzt. Hat das Problem schon mal einer gelöst??
Jörg