Wie Linux-Kern 3.0.4 installieren?

[MagicJohnson]

Ich habe mir mit Git den Kern 3.0.4 gesaugt. Ihn zu kompilieren, scheiterte mehrfach mit verschiedenen Fehlermeldungen, die ich hier nicht im einzelnen ausführen möchte. Ich habe nun neun Jahre Erfahrungen damit, den Kern zu konfigurieren und zu kompilieren, finde aber nichts konkretes über die GGC-Version, die ich verwenden soll. Ich habe sowohl Gcc 4.4 als auch 4.3 ausprobiert. Beides hat nicht geklappt, weil irgendwelche Symbole nicht gefunden werden konnten. Irgendwas konnte nicht gebunden werden. Das einzige, was ich bisher zu diesem Thema finden konnte, war, man möge doch "gcc latest version" (http://www.howopensource.com/2011/08/ho ... and-10-04/) verwenden.

Welche GCC-Version benötige ich? Oder muss ich vielleicht bestimmte Optimierung sein lassen?

[syssi]

Der aktuelle Kernel in Testing (3.0.0) wurde mittels gcc-4.6.1 gebaut. In den Build-Deps findet sich gcc (>= 4:4.4.3). Ob dies exakt so auch auf Kernel 3.0.4 zutrifft moechte ich nicht beschwoeren aber es ist schonmal ein Anhaltspunkt. Trotzdem waeren bei solchen Problemen Fehlermeldungen aussagekraeftiger.

Tipp: apt-get build-dep linux-image-3.0.0-1-686-pae

Damit werden alle Abhaengigkeiten installiert, die zum Bau des Debian-Pakets notwendig waeren ggf. loest sich damit so manches Problem deines Git-Checkouts.

[Milbret]

Welches System wird den verwendet?
Ich hab bei mir ein etwas neueres System mit dem Kernel laufen.
Hab dort Debian Squeeze 64 Bit laufen und kann mich nicht über Probleme beim kompilieren beschweren.

Hast du mal versucht die tar.gz von kernel.org zusaugen und dann per yes"" | make oldconfig zu konfigurieren und zuletzt per make zu erstellen?
Hab das bisher ohne Probleme gemacht.
Dann einfach per update-initramfs die initrd anlegen lassen und update-grub um schon ist der Kernel fertig.

Martin

[cosmac]

hi,

baust du den Kernel vielleicht unter /usr/src? Davon wurde schon vor 10 Jahren abgeraten; außerdem:

INSTALLING the kernel source:

- If you install the full sources, put the kernel tarball in a directory where you have permissions (eg. your home directory) and unpack it:
(...)
Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be.

Ich würde das auch aus anderen Gründen so machen:
- ich brauche keine root-Rechte (außer für die eigentliche Installation)
- alles unter /usr gehört der Distribution, ein selbstgebauter Kernel gehört mir
- auf meiner /usr-Partition ist nicht genug Platz und sie ist oft read-only gemountet

[Evox]

Der aktuelle Kernel in Testing (3.0.0) wurde mittels gcc-4.6.1 gebaut. In den Build-Deps findet sich gcc (>= 4:4.4.3). Ob dies exakt so auch auf Kernel 3.0.4 zutrifft moechte ich nicht beschwoeren aber es ist schonmal ein Anhaltspunkt. Trotzdem waeren bei solchen Problemen Fehlermeldungen aussagekraeftiger.

Tipp: apt-get build-dep linux-image-3.0.0-1-686-pae

Damit werden alle Abhaengigkeiten installiert, die zum Bau des Debian-Pakets notwendig waeren ggf. loest sich damit so manches Problem deines Git-Checkouts.

Es wird immer noch mit GCC-4.5.x gebaut bei Debian nur 3rd Distris verwenden GCC-4.6.x was aber nicht ohne ist!
Warum sollte man in Testing eine andere GCC Version nehmen als in SID / Experimental ?
Die Probleme mit "make deb-pkg" sind aber nicht ohne

hi,

baust du den Kernel vielleicht unter /usr/src? Davon wurde schon vor 10 Jahren abgeraten; außerdem:

INSTALLING the kernel source:.

Was soll passieren ? Ich übersetze immer nur als Normaler Nutzer in /usr/src*. Auf "Suchmaschinen höre ich nur sehr selten" da zu oft zu viel Blödsinn geschrieben wird. Habe so schon was weiß ich wie viele Pakete so gebaut.

[syssi]

Der aktuelle Kernel in Testing (3.0.0) wurde mittels gcc-4.6.1 gebaut. In den Build-Deps findet sich gcc (>= 4:4.4.3). Ob dies exakt so auch auf Kernel 3.0.4 zutrifft moechte ich nicht beschwoeren aber es ist schonmal ein Anhaltspunkt. Trotzdem waeren bei solchen Problemen Fehlermeldungen aussagekraeftiger.

Tipp: apt-get build-dep linux-image-3.0.0-1-686-pae

Damit werden alle Abhaengigkeiten installiert, die zum Bau des Debian-Pakets notwendig waeren ggf. loest sich damit so manches Problem deines Git-Checkouts.

Es wird immer noch mit GCC-4.5.x gebaut bei Debian nur 3rd Distris verwenden GCC-4.6.x was aber nicht ohne ist!

Noe, das ist falsch. In Squeeze wird 4.4.5 als Default eingesetzt. In Testing sind wir bei 4.6.1 angekommen.

Warum sollte man in Testing eine andere GCC Version nehmen als in SID / Experimental ?

Ganz einfach.. man kann eine ganze Hand voll GCC Versionen installieren / installiert haben. Stelle ich fest, dass eine Software sich noch nicht mittels gcc-4.6.1 bauen laesst, dann setze ich eine Umgebungsvariable auf 4.5 und versuche mein Glueck erneut. Nicht jeder Compilierfehler zwischen Compilerversionen ist trivial zu loesen. Aus diesem Grund kann es auch gerne mal vorkommen, dass ein Debian-Entwickler GCC-Versionen in den Build-Deps ausschliesst.

hi,

baust du den Kernel vielleicht unter /usr/src? Davon wurde schon vor 10 Jahren abgeraten; außerdem:

INSTALLING the kernel source:.

Was soll passieren ? Ich übersetze immer nur als Normaler Nutzer in /usr/src*. Auf "Suchmaschinen höre ich nur sehr selten" da zu oft zu viel Blödsinn geschrieben wird. Habe so schon was weiß ich wie viele Pakete so gebaut.

Die Gruende wurden schon genannt. Aber drehen wir mal die Argumentation um, wieso sollte dein Benutzer irgendwo im System schreiben koennen, ausser in seinem Homeverzeichnis?

[Evox]

Noe, das ist falsch. In Squeeze wird 4.4.5 als Default eingesetzt. In Testing sind wir bei 4.6.1 angekommen.

Nutze kein Squeeze sondern ein Mix aus Testing - Experimental
linux-headers-3.0.0-1-amd64 dep: gcc-4.5

Ganz einfach.. man kann eine ganze Hand voll GCC Versionen installieren / installiert haben. Stelle ich fest, dass eine Software sich noch nicht mittels gcc-4.6.1 bauen laesst, dann setze ich eine Umgebungsvariable auf 4.5 und versuche mein Glueck erneut. Nicht jeder Compilierfehler zwischen Compilerversionen ist trivial zu loesen. Aus diesem Grund kann es auch gerne mal vorkommen, dass ein Debian-Entwickler GCC-Versionen in den Build-Deps ausschliesst.

Klar kann man mehrere GCC Versionen installieren und nutzen aber wieso sollte man ? Hardware / Programme von den Eingerichten Rechner funktionieren bestens mit GCC 4.4. Umstieg auf eine neuere GCC Version folgt nach und nach wenn nötig.
Verwende immer nur eine GCC Version das hat mir ein Unix System beigebracht und diese Prinzip verwende ich auch hier mit Erfolg. Update Link auf die bevorzugte Version und Ruhe ist.

Die Gruende wurden schon genannt. Aber drehen wir mal die Argumentation um, wieso sollte dein Benutzer irgendwo im System schreiben koennen, ausser in seinem Homeverzeichnis?

Mein Fehler!
Bei mir kann kein einfacher Nutzer in System rumspazieren wie es per Default möglich ist ,soviel zum "Sicheren" Debian. Beschränkungen wie "ro , noexec,..usw" werden auch verwendet.
"Arbeit und Vergnügen" wird konsequent getrennt d.h. auch das der Zugang zu diesen speziellen Verzeichnis bzw Source Code zu übersetzten ist nur mein Nutzer möglich. Es gibt auch kein Quatsch wie Sudo, ..usw.
Wieso das Ganze ? Kontrolle und Stabilität sind sehr wichtig gerade wenn es sich um Multi Nutzer System handelt.
Wie der Zufall will sind es nur noch 64 Bit Systeme dadurch ist auch ein kleines Non-public Repro möglich.

[rendegast]

In Testing sind wir bei 4.6.1 angekommen.

'cat /proc/version' unter 3.0.0-1 gibt "gcc 4.5.3".

[syssi]

In Testing sind wir bei 4.6.1 angekommen.

'cat /proc/version' unter 3.0.0-1 gibt "gcc 4.5.3".

Wohl wahr. Da lag ich wohl falsch... hatte die Tage ein build-log ueberflogen und hab mich von einer Zeile mit gcc-4.6 blenden lassen. So wie es aussieht ist der Kernel aber momentan gegen gcc-4.5 gepinnt: https://buildd.debian.org/status/fetch. ... 1314471785

[ELw]

Hi!

Ich baue den Kern 3.0.4 mit den Konfig-Dateien von meinem 2.6.39er Kern.

Mein Kern ist ein Maximal-Kern, wobei möglichst alles in Modulen lauft.
Früher baute ich fix kompilierte Minimalkerne.

Der Kern baut sauber durch, ohne über unbekannte Symbole zu jammern.

Meine Umgebung:
- INTEL ATOM Board
- gcc 4.6.1 (selbst gebaut)
- binutils 2.21.1 (selbst gebaut)
- Suse 11.2 (32bit); die konkret eingesetzte Distri ist wahrscheinlich nicht das Problem.
- Meine eigenen Dateien .config, Makefile, sem.h, shm.h
- lilo 23.2

Bei Interesse schicke ich Dir meine genannten Dateien.

!!Aufgrund des jüngsten Security-Themas von http://www.kernel.org und allen abhängigen Mirrors, teste ich die 3er Serie nur isoliert!!

Ich bin pessimistisch und gehe davon aus, dass sich die erfolgreichen Angreifer die (SHA1 basierende??) Signierung der Kerne angeeignet haben und daher in den Eingeweiden der 3er Serie eine Backdoor lauert.

LG!