Sembra che la generazione degli headers del kernel con la 2.6.24
fallisca causa riunificazione architetture x86-32/64.
Sintomi:
in archlinux con il vanilla compilato (con PKGBUILD come da riferimento)
il link /usr/src/linux-2.6.24-vanilla/include/asm è interrotto
manca tutta la cartella
/usr/src/linux-2.6.24-vanilla/include/asm-x86
cartella che nei 2.6.23.x si chiamava /include/asm-i386
in debian sid con il vanilla (compilato con make-kpkg image headers)
il link /usr/src/linux-headers-2.6.24-mc/include/asm è interrotto
manca tutta la cartella
/usr/src/linux-headers-2.6.24-mc/include/asm-x86
cartella che nei 2.6.23.x si chiamava /include/asm-i386
Come conseguenza non si compila più nulla senza tutto il source del kernel.
Esempi:
http://telperion.wordpress.com/2008/01/27/kernel-2624-e-nvidia-169-09/
http://forum.debianizzati.org/kernel/linux-2624-vboxdrv-build-fallito-t32356.0.html
http://bbs.archlinux.org/viewtopic.php?id=43045
Se qualcuno ha notizie … notizi.
PS:
Su ArchLinux usando il nuovo schema PKGBUILD del kernel26-ARCH 2.6.24 in testing
come riferimento, che varia parecchio dal “vecchio” standard tutto và a posto, a conferma
che è il kernel che è cambiato negli headers.
Non ho idea di come ottenere gli headers corretti su Debian Ubuntu con make-kpkg.

Io, 2 palle
non sò più in che lingua scriverlo.
2.13. x86-32/64 arch reunification
You can read this recommended article.
When support for the x86-64 AMD architecture was developed, it was decided to develop it as a “fork” of the traditional x86 architecture for comodity reasons. Many patches needed to patch a file in the i386 architecure directory, and another similar patch for the duplicated file in the x86_64 directory. It has been decided to unify both architectures in the same directory again.
This reunification has not been done in a radical way. In this release, both architectures have been unified in arch/x86, but only in appearance. All the source files in i386 and x86-64 directories have been moved to arch/x86, but renaming them with “_32″ and “_64″ suffixes. Ex: arch/i386/kernel/reboot.c has been moved to arch/x86/kernel/reboot_32.c, and arch/x86_64/kernel/reboot.c has been moved to arch/x86/kernel/reboot_64.c. Makefiles have been modified accordingly. So for now the reunification has been pretty much just a relocation of all the files and adaptation of the build machinery to make it compile just as it’d have been compiled in the old separated directories, done mostly with scripts.
In the future lots of those files will be unified and shared by both architectures, ex. reboot_32.c and reboot_64.c into reboot.c, and many files have already been unified in this release. Others will keep separated forever, due to the differences between both architectures.
io passo, il 24 non mi interessa… difatti
Linux debian64 2.6.23.12-luna2
questo è il mio ultimo kernel e come vedi non ho compilato neanche l’ultima stable della precedente serie.
Io, 2 palle
vedremo che c’e’ nel 25
Commento di LuNa — gennaio 30, 2008 @ 5:53 am
ma l’aggiunta “tech” io la vedo adesso .. o c’era pure ieri… lol
se ho capito bene basta aspettare n’attimo che risistemino
certo che però
Io, 2 palle
Commento di LuNa — gennaio 30, 2008 @ 1:56 pm
L’ho aggiunta, non è che ogni info che trovo faccio un post nuovo,
è cambiata tutta la disposizione degli headers, su arch con kernel personalizzati basta modificare il PKGBUILD del kernel seguendo le nuove guide come detto, mentre su Debian e Ubuntu facendo i pacchetti com make-kpkg non si può far nulla finchè non aggiornano il comando, bisogna tenere tutto il sources.
Nessun problema su Gentoo dove il sources c’è tutto comunque.
Commento di telperion — gennaio 30, 2008 @ 2:12 pm
E’ il solito “vizietto”: cambio una cosa, bisogna riscrivere i tools.
Commento di telperion — gennaio 30, 2008 @ 2:15 pm
lo stesso vizietto per cui poi
i produttori non producono per linux
cambiare bello èèèèèèèèèèèèèèèèèèè, ma prima aspettare bisognaaaaaaaaaaaaaaa
stabilità qui occorreeeeeeeeeeeee … se da quache parte si vuole arrivareeeeee
Sono intonato ?
Lol
Commento di LuNa — gennaio 30, 2008 @ 3:35 pm
[...] pacchetti kernel_headers assolutamente non funzionanti, costringendoci a tenere tutti i sorgenti del kernel in /usr/src, altrimenti non compilate nulla, [...]
Pingback di Hardy Heron e i kernel custom (2.6.25) « Tecnologia e non solo — aprile 22, 2008 @ 8:05 pm
[...] Archiviato in: Debian, Gutsy, Hardy, Sid — telperion @ 3:08 pm Come già segnalato la generazione dei pacchetti deb degli headers del kernel con i tools di kernel-package, già dal [...]
Pingback di Pacchetti deb linux-headers custom: come “fixarli” « Tecnologia e non solo — maggio 11, 2008 @ 3:08 pm