Kernel-Kompilierung schlägt fehl (Debian)

[s24!]

Hallo,

es ist etwas kurios - zumindest aus meiner Sicht: Ich habe hier ein System, welches auf neue Hardware umziehen soll. Daher habe ich es einfach mit rsync komplett auf den neuen Server geschoben, abzüglich /boot, /dev, /proc, /sys, /tmp und /var/run. fstab, Netzwerkkonfiguration und ein paar Einzelheiten angepasst und die Sache läuft. Ich weiß, das ist nicht die feine englische Art - hat jedoch bislang immer funktioniert.
Aber ich kriege einfach keinen Kernel kompiliert bzw. gar nicht erst konfiguriert:

root@web2 /usr/src/linux-3.4.57 # make menuconfig
  HOSTCC  scripts/basic/fixdep
scripts/basic/fixdep.c:106:23: error: sys/types.h: No such file or directory
scripts/basic/fixdep.c:107:22: error: sys/stat.h: No such file or directory
scripts/basic/fixdep.c:108:22: error: sys/mman.h: No such file or directory
In file included from /usr/include/unistd.h:26,
                 from scripts/basic/fixdep.c:109:
/usr/include/features.h:346:25: error: sys/cdefs.h: No such file or directory
In file included from /usr/include/unistd.h:218,
                 from scripts/basic/fixdep.c:109:
/usr/include/bits/types.h:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’
In file included from scripts/basic/fixdep.c:109:
/usr/include/unistd.h: In function ‘access’:
/usr/include/unistd.h:288: error: expected declaration specifiers before ‘__THROW’
/usr/include/unistd.h:306: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__THROW’

So geht es noch viele Zeiten weiter, unabhängig davon, welche Kernelversion ich versuche und ob ich ihm schon eine Config mitgebe oder nicht. Besonders interessant ist aber wohl, dass das Ganze auf dem "Quellsystem" problemlos funktioniert. Das verstehe ich nicht im Ansatz - die Systeme sind doch eigentlich identisch?
Ansätze, die zugrundelegen, dass Pakete fehlen, sind somit auch leider nicht zutreffend - mehr konnte ich auch nicht dazu ergoogeln.

Hat jemand eine Idee?


Viele Grüße
Tim

 

[svenr]

da du debian nutzt...warum so komiziert? Kernel via paketmanager, vorher lspci um zu klären ob Treiber evtl noch dazu müssen und fertig.

Gruß Sven

 

[s24!]

Es soll einiges dazu, was im Standard-Kernel von Ubuntu nicht drin ist. Davon abgesehen löst das ja auch nicht das Problem.

 

[Deleted member 11740]

Einmal fehlen dir irgendwelche headerdateien vom Quellcode des Kernel und dann versucht der noch aus /usr/include/ was zu laden. Ist mir jetzt auch neu..

Wenn ich jetzt raten müsste, dann probiere doch mal apt-get build-dep $irgendeinkernel. Der holt sich dann die Abhängigkeiten um das Paket zu kompilieren.

Dann versuch nochmal menuconfig aufzurufen. Den Kernel erstellst du dann am besten als Debian-Paket inklusive header und initramfs.

 

[s24!]

Danke für deine Antwort.

root@web2 /usr/src/linux-3.4.57 # apt-get build-dep linux-image-3.2.0-0.bpo.4-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Picking 'linux' as source package instead of 'linux-image-3.2.0-0.bpo.4-amd64'
E: Unable to find a source package for linux
root@web2 /usr/src/linux-3.4.57 #

Das ist eindeutig nicht mehr meine Uhrzeit. Was mache ich falsch?

 

[Deleted member 11740]

Ich kann nicht schlafen :-(

Dir fehlen die deb-src im repository. Aber eigentlich soll er ja nicht den Kernel kompilieren, sondern nur die Abhängigkeiten zum Kompilieren besorgen. Ach keine Ahnung, wahrscheinlich holt sich apt-get das Paket, damit es die Abhängigkeiten auslesen kann und die entsprechenden Tools installiert.

Müsste gcc, make, automake, fakeroot usw. sein. Ist schon echt zu lange her.

 

[s24!]

War auch mein erster Gedanke, die sources.list ist aber korrekt. Pakete sind auch alle installiert. Wie gesagt, ein quasi baugleiches System funktioniert problemlos.

 

[s24!]

Es gibt Neuigkeiten:
Kaputt war die lib6-dev. aptitude reinstall hat die Sache wieder geradegebogen. Warum rsync trotz mehrmaliger Ausführung die Datei korrupt kopiert bzw. den Fehler nicht erkannt hat, weiß ich nicht und habe es auch nicht mehr rausgekriegt.

Ich verwende nun zum "rsyncen" zusätzlich den Parameter -c um Checksummen zu bilden und zu vergleichen und hoffe, dass das das Problem generell löst. Sonst wäre mein Grundvertrauen in rsync etwas erschüttert...