[DE] Kernel bauen Script - kernelmake

[ralul]

@agaida, das Script, was Du suchst zum Selberbauen des Kernels:

Code: [Select]

#!/bin/bash

E=mcedit
V="2.6.37"
L="linux-$V"
U="http://www.kernel.org/pub/linux/kernel/v2.6/$L.tar.bz2"
H=~/mysrc
S=~/mysrc/slh-patches

set -x
[ -d "$S" ] || mkdir -p "$S"
cd $H || exit
[ -f "$L.tar.bz2" ] || wget "$U"
[ -f "$L.tar.bz2" ] || exit
[ -d "$L" ]         || tar xjf "$L.tar.bz2"
ln -sTf "$H/$L" "$H/linux"
cd $S || exit
if [ -d debian/.svn ] ; then
  cd debian || exit
  svn update
else
  svn co svn://svn.berlios.de/fullstory/linux-aptosid-2.6/trunk/debian/
fi
ln -sTf "$S/debian/patches" "$H/linux/patches"
# [edit]
# @E "$H/linux/patches/series" || exit
$E "$H/linux/patches/series" || exit
cd "$H/linux" || exit
make mrproper
zcat /proc/config.gz >.config
quilt push -a
make oldconfig
make menuconfig
echo " "
echo "now :  "
echo "make deb-pkg"
echo "after this as root:"
echo "cd .. && dpkg -i linux-image*"

Ich habs eben so aus der Hand geschüttelt und noch nicht getestet, weil ich gerade unter Gentoo bin. Deswegen "set -x" eingeschaltet lassen und schauen wie weit es läuft!

[edit]Towos Hinweis $E statt @E - Script noch ungetestet!

[agaida]

Danke für die Scripte, ich hab sie noch nicht probieren können, ich hab noch ein paar kleine andere Großbaustellen.

[ralul]

Towo schrieb gerade
"Kernelbau braucht solch ein Script nicht und ist im Netz zu Hauf dokumentiert"

Ich habe solch eine Doku im ansonsten hervorragenden aptosid Handbuch immer vermisst:
Wie kann ich den 2.6.36 slh Kernel nachbauen, wenn er nicht mehr im Repo vorhanden ist?

[towo]

Code: [Select]

@E "$H/linux/patches/series" || exit
Wird nicht funktionieren, muß $E heissen.

Die patches lassen sich nicht ohne Weiteres auf eine vanilla Source anwenden, weil beim aptosid-kernel die .orig-source schon von unfreiem blob befreit ist.

Ein unbedarfter User wird am Editiren der series und der Kernel-Konfig scheitern, weil er nicht weiss, was er tut.

Code: [Select]

make deb-pkg  was soll das werden?

[agaida]

Im Endeffekt hat Towo nicht ganz unrecht, es wurde in den letzten Jahren viel darüber geschrieben. Da ich mir die Konfiguration vom slh-Kernel ja notgedrungen angeschaut habe, muss ich aber gestehen, dass so was dann aber auch nicht unbedingt meinen Vorstellungen eines idealen Scriptings entspricht.

Einen towo-Kernel kann man sich ja schon längere Zeit nicht mehr laden, also fehlt mir da der Vergleich.

@towo: Wenn ein unbedarfter User anfängt, Kernel zu bauen, ist er im Erfolgsfall kein ganz so unbedarfter User mehr. Im Falle des sehr wahrscheinlichen Misserfolgs trennt sich dann die Spreu vom Weizen. Die drei Möglichkeiten sind dann Lernen, fertiges Zeug nehmen oder zurück zu Windows.

Ich würde sogar so weit gehen, dass jemand, der ohne Probleme und ohne Buchstabe für Buchstabe eine Buidumgebung aufsetzen kann, nicht mehr ganz unbedarft ist. Bevor man das richtig kann, vergeht aber einiges an Zeit. Das Wissen über Linux und Werkzeuge wird in dieser Zeit aber nicht geringer. Gimp, Scribus oder gar OO zu bauen, ist schwieriger.

[towo]

Wie kann ich den 2.6.36 slh Kernel nachbauen, wenn er nicht mehr im Repo vorhanden ist?

Den entspr. Branch aus dem SVN auschecken, und rules lesen und verstehen.

[ralul]

Die patches lassen sich nicht ohne Weiteres auf eine vanilla Source anwenden, weil beim aptosid-kernel die .orig-source schon von unfreiem blob befreit ist.

Dafür ist im svn das Script debian/scripts/dfsg-prune. Aber ich meine, es reicht die linux/.config Option "Do not build binary blobs". Und im Grunde reichen die vanilla .3 patches, weil die meisten patches/upstream das Point-Release nur vorwegnehmen.

Code: [Select]

make deb-pkgwas soll das werden?

Wie man auch am Changelog von slh sehen kann

linux-aptosid-2.6 (2.6.36-19) unstable; urgency=low
...
    - recommend use of 'make deb-pkg' to build custom kernel packages

Die Debian Entwickler haben ganze Arbeit gemacht und schon länger ein Debian spezifisches Target im linux/Makefile durchgesetzt - upstream !

Insofern kann man sich den debian/rules Teil sparen mit einem einfachen make deb-pkg - das habe ich auch schon erfolgreich ausprobiert - sagte ich nicht irgendwo, es ist einfacher als man denkt!

Am obigen kernelmake Script fehlt nur noch ein allgemeinerer Teil, mit dem man einen Patchbaum des ausgesuchten Backports auschecken kann, zb

Code: [Select]

svn co svn://svn.berlios.de/fullstory/linux-aptosid-2.6/tags/2.6.36-19/debian/

[towo]

Dafür ist im svn das Script debian/scripts/dfsg-prune. Aber ich meine, es reicht die linux/.config Option "Do not build binary blobs.

Nicht ganz! Dieses Script wird beim Erzeugen der orig-Source angewendet.

Es mag ja für Dich einfach klingen, aber trotzdem kann der User mit deinem Script nicht viel anfangen!

1. Aufruf von debian/patches/series im Editor ==> der User weiss nicht, was er damit machen soll.
2. make oldconfig / make menuconfig ==> wer noch nie einen Kernel gebaut hat, kann damit absolut Nix anfangen.

Meiner Meinung nach ist dieses Script ungeignet, einen aptosid-nahen, Costum-Kernel zu bauen. Sicherlich benötigen die Wenigsten User die spezifischen Patches, welche slh benutzt, auch bei mir würde ein Stock-Vanilla-Kernel problemlos laufen.
aptosid hatte schon immer das Bestreben, neueste Entwicklungen zu berücksichtigen, BKL zu deaktivieren ist hier deshalb auch nur konsequent, zumal es, wieder einmal, nur propritären Kram betrifft, welcher damit nicht funktioniert.

Wer Kernel selber bauen will, soll das ruhig tun aber etwas verstehen, was er da macht, sollte $User schon. Wenn der Kernel durch falsche Konfiguration nicht funktioniert, ist das Geschrei dann nämlich groß und Support fast nicht möglich.

[agaida]

Das ist doch mal eine Aussage. Aptosid ist der Kernelentwicklung weit und konsequent voraus und der blöde User muss sehen, wo er bleibt.  :lol: Find ich irgendwie ein wenig elitär, aber man muss auch Opfer bringen. Damit Dürfte Aptosid die einzige Distro sein, die auf den BKL teilweise verzichtet.

Macht aber nichts, da BKL an den entscheidenden Stellen per Script eingeschaltet wird. Oder hab ich in den vergangenen Tagen was verpasst?  Nicht übelnehmen, aber auf Wunsch such ich die Stellen, die nicht proprietär sind, raus. (Duck und weg!)

[towo]

Man kann BKL nicht teilweise deaktivieren.
Entweder der Kernel hat BKL oder eben nicht und im aptosid Kernel ist :

Code: [Select]


towo:Defiant> grep -i bkl config
# CONFIG_BKL is not set

Und ja, auch nicht propritäre Treiber benötig(t)en BKL, als da zum Beispiel wären, cifs, nfs und udf.

[dieres]

heißt das, das cifs, nfs und udf derzeit nicht mit 2.6.37 in aptosid funktionieren ? Oder war das "benötig(t)en" so zu verstehen das diese 3 bkl jetzt nicht mehr brauchen?

[agaida]

Man kann BKL nicht teilweise deaktivieren.
Entweder der Kernel hat BKL oder eben nicht und im aptosid Kernel ist :

Code: [Select]


towo:Defiant> grep -i bkl config
# CONFIG_BKL is not set

Und ja, auch nicht propritäre Treiber benötig(t)en BKL, als da zum Beispiel wären, cifs, nfs und udf.

Jau, Du hast recht, hab das noch mal nachgelesen. In beidem. Aber wer benutzt schon cifs, nfs und udf (Ich geb zu udf benutze ich wirklich kaum)

[towo]

heißt das, das cifs, nfs und udf derzeit nicht mit 2.6.37 in aptosid funktionieren ? Oder war das "benötig(t)en" so zu verstehen das diese 3 bkl jetzt nicht mehr brauchen?

cifs und udf funktioniert sicher, da ich nfs nicht einsetze, kann ich dazu nix sagen. Es gäbe aber mit Sicherheit schon Beschwerden, wenn  nfs nicht funktionieren sollte.

[agaida]

Ich hab mir das jetzt noch nicht angeschaut, aber eine Sache, die ich nachher mal testen werde: Das Bereitstellen der nfs-Dienste. Obwohl das im Desktop-Bereich ja eher selten ist.

[agaida]

Nachdem ich jetzt durch das meiste von dem begriffen habe, was ich grad tue, hab ich nur noch eine entscheidende Frage: Das Paket von SLH bau vom Feinsten, Konfiguration etc ist kein Problem. das Kompilat funktioniert wie gewünscht. Nur so Kleinigkeiten wie .dsc .changes fehlen. Und wie baue ich ein Source-Paket per Hand? Irgendwie ist der Ablauf doch anders als bei debuild bei einfachen Paketen.