unp? Interessant. Wusste gar nicht, dass es sowas gibt. Feine Sache.
Description: unpack (almost) everything with one command unp is a small perl script which makes extraction of any archive files a bit easier. It support several compressors and archiver programs, chooses the right one(s) automatically and extracts one or more files in one go.
Zum Kernel bauen, installieren und deinstallieren ist make-kpkg praktisch :-) Nur wann konfigurierst du den kernel? die standart einstellungen kannst du haken ;-) vor das make-kpkg gehoert ein make menueconfig. dann den kernel so konfigurieren, dass er auf moeglichst vielen systemen laeuft.
Von Eduard Bloch am Di, 11. September 2001 um 23:08 #
Ack. Oder xconfig. Oder config. Oder "editor .config". Sei's drum, ich wollte hier nicht das komplette Howto zitieren. Amsonsten ist es gerade für Anfänger empfehlenswert, zuerst die Konfig des Maintainers zu übernehmen:
Von Christoph am Mi, 12. September 2001 um 08:34 #
Was hat das denn da verloren? Erstens suggeriert das die Möglichkeit einer Runtime-Konfiguration des Kernels, zweitens sollte man sowiso nicht als root unter X arbeiten und drittens läßt make menuconfig keine Wünsche offen.
@Christoph: Ob das nun da hingehört oder nicht, ist 'ne Meinungssache, mehr nicht. Zum Konfigurieren und Übersetzen des Kernels muss man mitnichten root sein und daher auch nicht als root unter X arbeiten. Lediglich die Installation eines neuen Kernels (inkl. Module) braucht root-Berechtigung.
Von Anonymous am Mi, 12. September 2001 um 10:04 #
4. Solltest du, nur weil du meinst es hätte da nichts verloren, nicht anderen leuten verbieten wollen das zu nutzen! Man kann das Kontrollzentrum auch mal als root starten weil man was konfigurieren will bzw. man wird nach einem passwort gefragt. Deine Haltung ist so richtig engstirnig! Nur weil DU meinst das DU es nicht brauchst, braucht es niemand ..... ?????
Leider sehe ich diese Haltung bei viel zu vielen Linux-Usern. Bin selbst ein Linux-User und bedaure es sehr das es immer noch solche leute wie dich gibt die so kleinkariert denken!
Von Christoph am Mi, 12. September 2001 um 15:31 #
Hallo Anonymous!
Ich denke nicht, daß es von Engstirnigkeit zeugt, aber die Tatsache, daß die Leute dazu verleitet werden unter KDE mit Superuserrechten zu arbeiten, stimmt mich nachdenklich.
Das hilft auf Dauer doch niemandem weiter, nur weil man jetzt den Kernel klicki-bunti konfigurieren kann.
Das eine Kernelkonfiguration keine triviale Geschichte ist, sollte doch klar sein. Und das übliche Procedere stellt eine gewisse Hemmschwelle für Nutzer dar, die nur mal so nen Kernel kompilieren wollen, ohne diejenigen, die es können, zu beeinträchtigen.
Wie kann denn ein Unwissender, einen Wissenden beeintraechtigen, indem er sich einen Kernel falsch kompiliert? Lass sie doch. Und von "als Root unter X" arbeiten war nicht die Rede. So etwas sollte immer durch eine Passwortabfrage geloest werden.
Apropos, ich denke man sollte hier noch einen Schritt weiter gehen. Z.B. wenn ich ein File per Konqueror nach /usr kopieren moechte, sollte er nicht eine Fehlermeldung bringen, sondern eine Warnung und mich nach dem Passwort fragen. Sonst wird Konqueror NIEMALS ein vernuenftiger Ersatz fuer die Konsole bei einfachen Systemarbeiten sein. Einen Konqueror im Superuser-Modus zu starten ist auch keine gute Alternative, da dann zum einen D&D nicht mehr vernuenftig funktioniert und ich zum anderen dann auch genausogut eine Konsole oeffnen koennte, das ist dann auch nicht mehr umstaendlicher.
Von Christoph am Mi, 12. September 2001 um 19:45 #
@Spark Das mit dem Beeintraechtigen war so gemeint, daß ich make menuconfig als mindestens so komfortabel empfinde wie KDE-Kontrollzentrum.
Das mit dem Konqueror ist zwar unter Usability Gesichtspunkten richtig, aber ich wehre mich dagegen, grafische Oberflächen zur Systemadministration einzusetzen.
Und außerdem, wie oft kopierst Du ne Datei nach /usr, wenn Du nicht sowieso gerade was neu kompilierst oder so.
Gehört zwar nicht in den Thread, ich antworte aber trotzdem mal: von RARSOFT wird eine Shareware-Version (ich glaube mit 30 Tagen-Beschränkung) angeboten, unterstützt werden alle Optionen die RAR auch kennt, daher vermute ich, dass es auch WinRAR -kompatibel. Zu Downloaden gibt's das unter: http://www.rarsoft.com/download.htm
Katakombi, ich würde nächstes Mal aber solche Fragen im passenden Forum/Newsgroup/Mailing-Liste stellen.
Ein wichtiger Aspekt wurde leider nicht erwähnt, die Versionsverwaltung. Mit make-kpkg kernel-image --revision=xx kann mit xx die Version mitgegeben werden.
Ich pflege damit für 3 Rechner die Kernel-debs in dem ich die Version . mitgebe. Somit brauchte ich nur auf einem Rechner die Kernelsourcen zu pflegen.
Von Denny Schierz am Mi, 12. September 2001 um 16:40 #
hi, Ich will nur kurz erklären, wie ich meine Pakete erstelle ,für die jenigen unter euch, die diese Möglichkeit noch nicht kennen. Es werden folgende Pakete benötigt, fakeroot kernel-package und der Rest für den Kernel (make gcc etc.). Zuerst den Kernel nach Bedarf einstellen, dann unter /usr/src/linux folgenden Aufruf starten nach dem "make dep" 1. make-kpkg clean 2. fakeroot make-kpkg kernel_image kernel_headers(wenn gewünscht) --revision=meinlinux
3. unter /usr/src/.deb kann das Paket mit dpkg --install .deb installiert werden.
Öhm, warum soll man die Kernel-Sourcen nicht in /usr/src/linux installieren? Ich glaube, das hat irgendwas mit den Kernel-Headern zu tun, aber wie ist das genau? Ich baue meine Kernels immer in /usr/src/linux und hatte bisher keine Probleme damit.
Von Christoph am Do, 13. September 2001 um 08:25 #
Das ist ein weit verbreitetes Missverständnis. Nach Aussage von Linux soll /usr/src/linux immer auf die Includes desjenigen Kernels zeigen, gegen den die glibc gelinkt ist.
Von Anonymous am Fr, 14. September 2001 um 12:34 #
Christoph: das stimmt so nicht. Siehe http://kt.zork.net/kernel-traffic/kt20000814_80.html#4
Es geht darum, dass die Header in /usr/include eindeutig zur libc gehören, d.h. die gleichen Einstellungen wiedergeben, mit den die libc kompiliert wurde. Ein Programmierer sollte wissen, ob die Definitionen, die er aus Headers holt, in der libc oder im Kernel-Space eine Rolle spielen. Im letzten Fall muss er $CURRENT_KERNELDIR/linux/include nehmen, amsonsten die Headers, die zur libc gehören. /usr/include ist für die libc-Header vorgesehen, nicht für die Kernel-Header. Man darf das auch nicht auf die Kernel-Sources linken, ganz gleich ob die in /usr/src/linux oder woanders liegen. Die Kernel-Sourcen sollten überhaupt positionsunabhängig sein, d.h. es darf nichts auf den Source-Tree referenzieren.
Das raffen die Distributoren nicht immer und verursachen manch einem Kopfschmerzen.
Von Christoph am Fr, 14. September 2001 um 14:47 #
@Anon:
Ja, Du hast natürlich recht, aber bei den meisten Distributionen ist /usr/include/linux ein Link auf /usr/src/linux/include/linux
/usr/src/linux wiederum ist auch meist ein Link und zwar auf die Header des Kernels, mit dem die glibc programmiert wurde. Da /usr/include/linux aber zu glibc passen muss, sollte man sich hüten, /usr/src/linux zu verändern, insbesondere sollte man es nicht auf die gerade verwendeten Kernelsourcen zeigen lassen. Leider führen viele HOWTOs und Standardpakete der Distributoren da in die Irre.
Von Anonymous am Fr, 14. September 2001 um 17:00 #
Naja. So könnte man um den heissen Brei herumreden. Die Tatsache bleibt: wer /usr/include/{linux,asm} durch Links auf sowas wie /usr/src/linux ersetzt, handelt fahrlässig. Wenn das einem Distributor passiert, ist das Schlamperei, und sollte in den Tests auch als solche bewertet werden.
Von Eduard Bloch am Do, 13. September 2001 um 10:11 #
Christoph: fast richtig geraten, aber nur fast. Linus empfiehlt, die Headers! (und nur die), mit den die libc kompiliert wurde, in /usr/include/{linux,asm} zu halten. Damit ist man von der Position der Kernel-Sourcen unabhängig, und die kompilierten Programme kriegen keine Inkompabilitäten mit der Libc. Kernel-Includes sollen nur von Modulen und Low-Level-Programmen (z.B. cdrecord) benutzt werden.
Nur hat es nicht jeder Entwickler von Kernel-Modulen gerafft und benutzt per default /usr/include/linux -> Missverständnusse vorprogrammiert.
Von Anonymous am Do, 13. September 2001 um 15:53 #
Hä? Lern lesen und stell das blöde Grinsen ab. Die Header in /usr/include/{linux,asm} gehören zum libc-dev Paket, so wie es sein soll. Einen Link zu erstellen ist FALSCH - diese Unsitte wurde von schlampigen Programmierern und naiven Distributoren eingeführt.
Hat einer mal Lust, einen Kurztip oder kompletten Artikel zum richtigen Installieren der Kernel-Header zu schreiben? Genug Experten sind ja wohl hier. Ich könnte es auch selbst machen, habe vorher aber noch ein paar andere Dinge zu tun...
Von Anonymous am Fr, 14. September 2001 um 12:43 #
Hjb: es gibt keine Anleitung zum installieren der Kernel-Header. Die werden einfach mit dem Kernel-Source entpackt - einmal "make {menu,x,,}config" ausführen - speichern - fertig.
Was anders sind die libc-Header (*) - diese werden im libc-dev Paket mitgeliefert und gehören auch dorthin.
(*) Diese sehen den Kernel-Header zum verwechseln ähnlich aus und zwar weil Sie zum Kompilieren der libc aus einem Kernel-Sourcetree genommen werden.
Interessant.
Wusste gar nicht, dass es sowas gibt. Feine Sache.
Description: unpack (almost) everything with one command
unp is a small perl script which makes extraction of any archive files
a bit easier. It support several compressors and archiver programs,
chooses the right one(s) automatically and extracts one or more files
in one go.
husky
Nur wann konfigurierst du den kernel? die standart einstellungen kannst du haken ;-)
vor das make-kpkg gehoert ein make menueconfig. dann den kernel so konfigurieren, dass er auf moeglichst vielen systemen laeuft.
Amsonsten ist es gerade für Anfänger empfehlenswert, zuerst die Konfig des Maintainers zu übernehmen:
cp /boot/config-VERSION /usr/src/SRCDIR/.config
Damit läst sichder kernel auch konfigurieren:
System->Einrichtung des Kernels
Ist halt auch eine möglichkein, aber auch gewöhnungs bedürftig :(
aber immerhin, da tut sich auch was...
Erstens suggeriert das die Möglichkeit einer Runtime-Konfiguration des Kernels, zweitens sollte man sowiso nicht als root unter X arbeiten und drittens läßt make menuconfig keine Wünsche offen.
Christoph
Ob das nun da hingehört oder nicht, ist 'ne Meinungssache, mehr nicht. Zum Konfigurieren und Übersetzen des Kernels muss man mitnichten root sein und daher auch nicht als root unter X arbeiten. Lediglich die Installation eines neuen Kernels (inkl. Module) braucht root-Berechtigung.
Jochen
Deine Haltung ist so richtig engstirnig! Nur weil DU meinst das DU es nicht brauchst, braucht es niemand ..... ?????
Leider sehe ich diese Haltung bei viel zu vielen Linux-Usern. Bin selbst ein Linux-User und bedaure es sehr das es immer noch solche leute wie dich gibt die so kleinkariert denken!
Ich denke nicht, daß es von Engstirnigkeit zeugt, aber die Tatsache, daß die Leute dazu verleitet werden unter KDE mit Superuserrechten zu arbeiten, stimmt mich nachdenklich.
Das hilft auf Dauer doch niemandem weiter, nur weil man jetzt den Kernel klicki-bunti konfigurieren kann.
Das eine Kernelkonfiguration keine triviale Geschichte ist, sollte doch klar sein. Und das übliche Procedere stellt eine gewisse Hemmschwelle für Nutzer dar, die nur mal so nen Kernel kompilieren wollen, ohne diejenigen, die es können, zu beeinträchtigen.
Christoph
Lass sie doch.
Und von "als Root unter X" arbeiten war nicht die Rede. So etwas sollte immer durch eine Passwortabfrage geloest werden.
Apropos, ich denke man sollte hier noch einen Schritt weiter gehen.
Z.B. wenn ich ein File per Konqueror nach /usr kopieren moechte, sollte er nicht eine Fehlermeldung bringen, sondern eine Warnung und mich nach dem Passwort fragen.
Sonst wird Konqueror NIEMALS ein vernuenftiger Ersatz fuer die Konsole bei einfachen Systemarbeiten sein.
Einen Konqueror im Superuser-Modus zu starten ist auch keine gute Alternative, da dann zum einen D&D nicht mehr vernuenftig funktioniert und ich zum anderen dann auch genausogut eine Konsole oeffnen koennte, das ist dann auch nicht mehr umstaendlicher.
Das mit dem Beeintraechtigen war so gemeint, daß ich make menuconfig als mindestens so komfortabel empfinde wie KDE-Kontrollzentrum.
Das mit dem Konqueror ist zwar unter Usability Gesichtspunkten richtig, aber ich wehre mich dagegen, grafische Oberflächen zur Systemadministration einzusetzen.
Und außerdem, wie oft kopierst Du ne Datei nach /usr, wenn Du nicht sowieso gerade was neu kompilierst oder so.
Christoph
von RARSOFT wird eine Shareware-Version (ich glaube mit 30 Tagen-Beschränkung) angeboten,
unterstützt werden alle Optionen die RAR auch kennt, daher vermute ich, dass es auch WinRAR -kompatibel.
Zu Downloaden gibt's das unter: http://www.rarsoft.com/download.htm
Katakombi, ich würde nächstes Mal aber solche Fragen im passenden Forum/Newsgroup/Mailing-Liste stellen.
Gruss, Juri.
make-kpkg kernel-image --revision=xx
kann mit xx die Version mitgegeben werden.
Ich pflege damit für 3 Rechner die Kernel-debs in dem ich die Version . mitgebe. Somit brauchte ich nur auf einem Rechner die Kernelsourcen zu pflegen.
Die Versionen lauten "hostname.version" !
Ich will nur kurz erklären, wie ich meine Pakete erstelle ,für die jenigen unter euch, die diese Möglichkeit noch nicht kennen.
Es werden folgende Pakete benötigt, fakeroot kernel-package und der Rest für den Kernel (make gcc etc.). Zuerst den Kernel nach Bedarf einstellen, dann unter /usr/src/linux folgenden Aufruf starten nach dem "make dep"
1. make-kpkg clean
2. fakeroot make-kpkg kernel_image kernel_headers(wenn gewünscht)
--revision=meinlinux
3. unter /usr/src/.deb kann das Paket mit dpkg --install .deb installiert werden.
Hoffe es stört niemanden, das Posting hier.
cu denny
2. fakeroot make-kpkg kernel_image kernel_headers(wenn gewünscht)
--revision=meinlinux(Meine.Version)
und dpkg --install (Kernel-Version).deb
Ich schätze sie werden herausgefiltert.
cu denny
Ich baue meine Kernels immer in /usr/src/linux und hatte bisher keine Probleme damit.
Bitte um Aufklärung
Nach Aussage von Linux soll /usr/src/linux immer auf die Includes desjenigen Kernels zeigen, gegen den die glibc gelinkt ist.
Christoph
Es geht darum, dass die Header in /usr/include eindeutig zur libc gehören, d.h. die gleichen Einstellungen wiedergeben, mit den die libc kompiliert wurde.
Ein Programmierer sollte wissen, ob die Definitionen, die er aus Headers holt, in der libc oder im Kernel-Space eine Rolle spielen. Im letzten Fall muss er $CURRENT_KERNELDIR/linux/include nehmen, amsonsten die Headers, die zur libc gehören.
/usr/include ist für die libc-Header vorgesehen, nicht für die Kernel-Header.
Man darf das auch nicht auf die Kernel-Sources linken, ganz gleich ob die in /usr/src/linux oder woanders liegen. Die Kernel-Sourcen sollten überhaupt positionsunabhängig sein, d.h. es darf nichts auf den Source-Tree referenzieren.
Das raffen die Distributoren nicht immer und verursachen manch einem Kopfschmerzen.
Ja, Du hast natürlich recht, aber bei den meisten Distributionen ist /usr/include/linux ein Link auf /usr/src/linux/include/linux
/usr/src/linux wiederum ist auch meist ein Link und zwar auf die Header des Kernels, mit dem die glibc programmiert wurde.
Da /usr/include/linux aber zu glibc passen muss, sollte man sich hüten, /usr/src/linux zu verändern, insbesondere sollte man es nicht auf die gerade verwendeten Kernelsourcen zeigen lassen. Leider führen viele HOWTOs und Standardpakete der Distributoren da in die Irre.
Sind wir uns soweit einig?
Christoph
Linus empfiehlt, die Headers! (und nur die), mit den die libc kompiliert wurde, in /usr/include/{linux,asm} zu halten. Damit ist man von der Position der Kernel-Sourcen unabhängig, und die kompilierten Programme kriegen keine Inkompabilitäten mit der Libc. Kernel-Includes sollen nur von Modulen und Low-Level-Programmen (z.B. cdrecord) benutzt werden.
Nur hat es nicht jeder Entwickler von Kernel-Modulen gerafft und benutzt per default /usr/include/linux -> Missverständnusse vorprogrammiert.
Also /usr/src/linux auf /usr/include/linux linken und alles wird gut?
Lern lesen und stell das blöde Grinsen ab. Die Header in /usr/include/{linux,asm} gehören zum libc-dev Paket, so wie es sein soll.
Einen Link zu erstellen ist FALSCH - diese Unsitte wurde von schlampigen Programmierern und naiven Distributoren eingeführt.
Was anders sind die libc-Header (*) - diese werden im libc-dev Paket mitgeliefert und gehören auch dorthin.
(*) Diese sehen den Kernel-Header zum verwechseln ähnlich aus und zwar weil Sie zum Kompilieren der libc aus einem Kernel-Sourcetree genommen werden.