staging.inyokaproject.org

Es funktioniert einfach nicht...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

make-kpkg clean
export CONCURRENCY_LEVEL=2
fakeroot make-kpkg --initrd --append-to-version=-patched kernel_image kernel_headers

......//zwei Stunden später //.....

dpkg-gencontrol: Fehler: Paket linux-image-3.4.9-patched-rt17 nicht in Steuer-Info
make[2]: *** [debian/stamp/binary/linux-image-3.4.9-patched-rt17] Fehler 255
make[2]: Verlasse Verzeichnis '/home/msruser103/linux-3.4.9-rt17'
make[1]: *** [debian/stamp/binary/pre-linux-image-3.4.9-patched-rt17] Fehler 2
make[1]: Verlasse Verzeichnis '/home/msruser103/linux-3.4.9-rt17'
make: *** [kernel_image] Fehler 2
msruser103@MSRPC-103:~/linux-3.4.9-rt17$ dpkg-checkbuilddeps
msruser103@MSRPC-103:~/linux-3.4.9-rt17$ 

Mir ist jetzt erst aufgefallen, dass du das unter Lucid machst. Unter Precise funktionierts:

$ ls -1 ..
linux-3.4.9-rt17
linux-3.4.9.tar.bz2
linux-headers-3.4.9-patched-rt17_3.4.9-patched-rt17-10.00.Custom_amd64.deb
linux-image-3.4.9-patched-rt17_3.4.9-patched-rt17-10.00.Custom_amd64.deb
patch-3.4.9-rt17.patch

Vielleicht ist einfach der Kernel 3.4 zu neu für das make-kpkg von Lucid. Wenn du nicht Precise verwenden kannst, probiers mit einem älteren Kernel.

Die Installation ist im Wiki auch beschrieben (Kernel/Kompilierung#Kernel-installieren).

barcc schrieb:

Vielleicht ist einfach der Kernel 3.4 zu neu für das make-kpkg von Lucid. Wenn du nicht Precise verwenden kannst, probiers mit einem älteren Kernel. Die Installation ist im Wiki auch beschrieben (Kernel/Kompilierung#Kernel-installieren).

Jo, hier ists auch nicht anders: http://linuxtweaking.blogspot.de/2010/05/how-to-compile-kernel-on-ubuntu-1004.html Hier gehts noch anders: http://wiki.ubuntuusers.de/Kernel/Kompilierung aber das ist wohl für hardy gedacht...

Mal eine andere Frage: Ich nutze noch ne Ubuntu 12.04 Distribution- 64bit. Dort kann ich doch die *.debs erstellen, auf 10.04 kopieren und dort installieren? Das Update über Synaptic ist ja auch nichts anderes oder?

t1m0n schrieb:

barcc schrieb:

Vielleicht ist einfach der Kernel 3.4 zu neu für das make-kpkg von Lucid. Wenn du nicht Precise verwenden kannst, probiers mit einem älteren Kernel. Die Installation ist im Wiki auch beschrieben (Kernel/Kompilierung#Kernel-installieren).

Jo, hier ists auch nicht anders: http://linuxtweaking.blogspot.de/2010/05/how-to-compile-kernel-on-ubuntu-1004.html

Die Kritik im dem Artikel kann ich nicht ganz verstehen, die Verwendung von make-kpkg ist doch eigentlich immer gleich beschrieben und funktioniert auch (zumindest wenn man einen Lucid-Kernel unter Lucid oder einen Hardy-Kernel unter Hardy usw… kompiliert), Backporten von Software (in deinem Fall ein 3.4er Kernel unter Lucid) hingegen ist ofmals keine triviale Angelegenheit.

Hier gehts noch anders: http://wiki.ubuntuusers.de/Kernel/Kompilierung aber das ist wohl für hardy gedacht...

Der Artikel beschreibt zwei Vorgehensweisen, 1. die Ubuntu-Methode, die originale Ubuntukernelpakete erzeugt und 2. die Debian-Methode mit make-kpkg. Beide Vorgehensweisen sind für alle unterstützten Ubuntuversionen getestet …

Mal eine andere Frage: Ich nutze noch ne Ubuntu 12.04 Distribution- 64bit. Dort kann ich doch die *.debs erstellen, auf 10.04 kopieren und dort installieren?

Kann funktionieren oder auch nicht, nicht ausgeschlossen, dass du dein System durcheinander bringst. Solltest du auf jeden Fall vorher auf einem Testsystem ausprobieren.

Das Update über Synaptic ist ja auch nichts anderes oder?

Doch, das ist was völlig anderes. Was auch immer du über Synaptic unter Lucid bekommst wurde unter Lucid und für Lucid gebaut (jedenfalls solange du die normalen Paketquellen verwendest).

barcc schrieb:

Die Kritik im dem Artikel kann ich nicht ganz verstehen, die Verwendung von make-kpkg ist doch eigentlich immer gleich beschrieben und funktioniert auch (zumindest wenn man einen Lucid-Kernel unter Lucid oder einen Hardy-Kernel unter Hardy usw… kompiliert), Backporten von Software (in deinem Fall ein 3.4er Kernel unter Lucid) hingegen ist ofmals keine triviale Angelegenheit.

Ich möchte keinen Lucid-Kernel. Dann würde ich den von Ubuntu ja selbst beziehen. Ich möchte mir den Vanilla-Kernel mit dem RT_PREEMPT-Patch patchen und kompilieren. Ich versuche das nun mit dem Kernel 3.2.

Vanialla-Kernel: http://kernel.org/

RT-Patch: http://www.kernel.org/pub/linux/kernel/projects/rt/

Leider sind 3.2 und 3.0 die letzten Versionen die dort supportet werden- Patch- und Kernelversionsnummer sollten ja zusammen passen. Viel älter geht daher nicht.

barcc schrieb:

Mir ist jetzt erst aufgefallen, dass du das unter Lucid machst. Unter Precise funktionierts:

$ ls -1 ..
linux-3.4.9-rt17
linux-3.4.9.tar.bz2
linux-headers-3.4.9-patched-rt17_3.4.9-patched-rt17-10.00.Custom_amd64.deb
linux-image-3.4.9-patched-rt17_3.4.9-patched-rt17-10.00.Custom_amd64.deb
patch-3.4.9-rt17.patch

Vielleicht ist einfach der Kernel 3.4 zu neu für das make-kpkg von Lucid. Wenn du nicht Precise verwenden kannst, probiers mit einem älteren Kernel.

Die Installation ist im Wiki auch beschrieben (Kernel/Kompilierung#Kernel-installieren).

Könntest du vielleicht detailiert beschrieben welches Vorgehen du genau hattest? Ich hatte nun mit mv den Ordner Umbenannt gehabt 3.4.9-rt17. Das funktionierte nicht. Nun habe ich den Kernel 3.2.28 als Vanilla gezogen, gepatcht und nun nicht umbenannt. Der Ordner hieß daher linux-3.2.28. Nach make-kpkg .... hieß es dann,

linux-image-3.2.28-rt41-rt41 Fehler 255

pre-linux-image-3.2.28-rt41-rt41 Fehler 2

Ich vermute nun eher, dass ich mit der Namensvergabe etwas nicht auf die Reihe bekomme. So ergibt -rt41-rt41 für mich keinen sein, weil ich mit -append-to-version nur -rt41 übergeben habe.

Gruß, Marcel

t1m0n schrieb:

barcc schrieb:

Die Kritik im dem Artikel kann ich nicht ganz verstehen, die Verwendung von make-kpkg ist doch eigentlich immer gleich beschrieben und funktioniert auch (zumindest wenn man einen Lucid-Kernel unter Lucid oder einen Hardy-Kernel unter Hardy usw… kompiliert), Backporten von Software (in deinem Fall ein 3.4er Kernel unter Lucid) hingegen ist ofmals keine triviale Angelegenheit.

Ich möchte keinen Lucid-Kernel. Dann würde ich den von Ubuntu ja selbst beziehen. Ich möchte mir den Vanilla-Kernel mit dem RT_PREEMPT-Patch patchen und kompilieren. Ich versuche das nun mit dem Kernel 3.2.

...

Da war von mir etwas unglücklich formuliert, gemeint war: ...wenn man einen Kernel mit einer ähnlichen Versionsnummer unter Lucid ... kompiliert

t1m0n schrieb:

…

Könntest du vielleicht detailiert beschrieben welches Vorgehen du genau hattest? Ich hatte nun mit mv den Ordner Umbenannt gehabt 3.4.9-rt17. Das funktionierte nicht. Nun habe ich den Kernel 3.2.28 als Vanilla gezogen, gepatcht und nun nicht umbenannt. Der Ordner hieß daher linux-3.2.28. Nach make-kpkg .... hieß es dann,

linux-image-3.2.28-rt41-rt41 Fehler 255

pre-linux-image-3.2.28-rt41-rt41 Fehler 2

Ich vermute nun eher, dass ich mit der Namensvergabe etwas nicht auf die Reihe bekomme. So ergibt -rt41-rt41 für mich keinen sein, weil ich mit -append-to-version nur -rt41 übergeben habe.

Gruß, Marcel

Das Vorgehen ist das in dem von dir anfangs zitierten Artikel, und mit der Debian-Methode aus dem Wiki.

Ich habe es gerade mit 3.2.28 in einer Lucid-Chroot-Umgebung ausprobiert:

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.28.tar.bz2
wget http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.28-rt41.patch.bz2
tar -jxvf linux-3.2.28.tar.bz2
mv linux-3.2.28 linux-3.2.28-rt41
bunzip2 patch-3.2.28-rt41.patch.bz2
cd linux-3.2.28-rt41
patch -p1 <../patch-3.2.28-rt41.patch

Beim Kompilieren kam dann wieder der ominöse Fehler "dpkg-gencontrol: Fehler: Paket linux-image-… nicht in Steuer-Info".

Ich habe dann folgendes gemacht:

echo >localversion-rt #Die Datei localversion-rt enthält vorher die einzelne Zeile "-rt41"

Dann habe in nochmal kompiliert und das jetzt fehlende "-rt41" zusätzlich an die Version angehängt:

make-kpkg clean
export CONCURRENCY_LEVEL=4
fakeroot make-kpkg --initrd --append-to-version=-patched-rt41 kernel_image kernel_headers

Beim letzten Befehl habe ich alle Fragen zur Konfiguration einfach mit [Enter] beantwortet.

Sieht so aus als hätte es funktioniert:

$ ls -1 ..
linux-3.2.28-rt41
linux-3.2.28.tar.bz2
linux-3.4.9-rt17
linux-3.4.9.tar.bz2
linux-headers-3.2.28-patched-rt41_3.2.28-patched-rt41-10.00.Custom_amd64.deb
linux-image-3.2.28-patched-rt41_3.2.28-patched-rt41-10.00.Custom_amd64.deb
patch-3.2.28-rt41.patch
patch-3.4.9-rt17.patch

Da beim 3.4.9er Kernel die gleiche Fehlermeldung kam, könnte es vielleicht da auch funktionieren.