[RISOLTO] Guida "Debian Kernel Howto"

[Aki]

La guida Debian Kernel Howto prevede che la directory /usr/src abbia i privilegi owner:group pari a root:src .

A seguito di bugfix, la directory /usr/src ha assunto i privilegi root:root.

La guida, pertanto, non è più utilizzabile, fatto salvo non si annullino gli effetti del bugfix sopra indicato (vedi http://forum.debianizzati.org/viewtopic.php?f=3&t=48035).

Il presente messaggio è finalizzato a ottenere consenso sulla modifica da effettuare alla guida. In particolare, è preferibile che la guida sia modificata in modo che il kernel sia scaricato, configurato e compilato al di fuori del percorso /usr/src (ad esempio, in $HOME/usr/src) oppure se ci sono ancora validi motivi per mantenere l'attuale impostazione della guida ed, in quest'ultimo caso, quale modifica apportare alla guida per renderla utilizzabile.

[s3v]

Questo messaggio mi era completamente sfuggito.
Appena posso modifico la guida (avrei dovuto già farlo ma me ne sono dimenticato...). Se qualcuno lo fa prima è ben accetto

Grazie del reminder.

EDIT
La frase "avrei dovuto già farlo" era riferita a questo

[s3v]

La compilazione del kernel in una cartella diversa da /usr/src non presenta problemi, per cui direi di aggiornare la guida togliendo completamente la compilazione in /usr/src .
Qualcuno conferma?

Putroppo, stupidamente, ho compilato lo stesso kernel che uso (3.2) per cui non ho testato il DKMS; quindi dovrei ricompilare un kernel nuovo...
Qualcuno ha già compilato una versione diversa dal kernel utilizzato per vedere se i moduli esterni (nel mio caso VBox e Nvidia) vengono automaticamente ri-compilati per il nuovo kernel?

Altrimenti bisognerebbe scrivere anche due righe per lanciare il DKMS prima che il riavvio con il kernel nuovo porti ad uno schermo nero (caso Nvidia) e senza alcuni moduli (vbox o altri).

[s3v]

Ho appena compilato correttamente utilizzando la mia directory home.
A mio avviso non è più necessario compilare in "/usr/src" (che poi sul mio sistama ha permessi root:root).
Se si hanno riscontri, modifichiamo la guida.

[Ombra]

Se può servire, già da tempo compilo i kernel in una subdir della mia home e confermo che funziona tutto correttamente.
Aggiungo solo che io per i moduli esterni (tipo vbox) non uso DKMS ma module-assistant e anche qui nessun problema, il pacchetto deb con i moduli da installare viene creato nella directory sopra a quella dei sorgenti (come succedeva in /usr/src/)

[s3v]

Grazie dell'utilissimo feedback.
Ho compilato il 3.19 nella mia home con:

Codice: Seleziona tutto

$ make deb-pkg

e ha creato cinque .deb compresi gli header.
È bastato installare con dpkg ''prima'' gli header e poi l'immagine: il DKMS ha compilato correttamente i moduli per VirtualBox. Sicuramente il "build" del DKMS permetterà di compilare anche senza installare i pacchetti in ordine, ma non ho provato.
Ora non resta che capire la differenza tra "make deb-pkg" e "make-kpkg".
Da qui sembra che "make-kpkg" sia stato superato:

CULTURE
The good old days of kernel-package
Before the Linux build system gained the ability to build proper Debian packages, the recommended way to build such packages was to use make-kpkg from the kernel-package package.

"I vecchi cari giorni di kernel-package" ...

[Ombra]

Ora non resta che capire la differenza tra "make deb-pkg" e "make-kpkg".
Da qui sembra che "make-kpkg" sia stato superato:

ci avevo guardato tempo fa, quando dissero che make-kpkg era deprecato: da quello che ho capito (ma bisognerebbe verificare) la "procedura" per costruire i pacchetti deb per il kernel è stata incorporata nei makefiles del kernel ufficiale (kernel.org) pertanto non è più necessario make-kpkg.
Questa procedura dovrebbe occuparsi, oltre che della creazione del kernel e degli headers, anche della separazione delle parti di codice proprietario (es firmware) in un relativo pacchetto separato, in puro Debian-style.

EDIT: ecco avevo letto qui , c'è la spiegazione e qualche esempio d'uso

[s3v]

Ottimo, grazie del link.
Non mi è chiaro però a cosa serve il pacchetto del firmware "in Debian". Cioè, nei repository non lo vedo per cui immagino non debba essere installato e che venga poi splittato a sua volta dagli sviluppatori in pacchetti da inserire nei repository.
Praticamente di quei cinque pacchetti dovrebbe servire solo "image" mentre gli altri quattro andrebbero installati dai repository.

Su questo aspetto andrebbe fatta qualche prova perché ho notato anche che di default viene assegnata una versione al pacchetto che non corrisponde con la versione precompilata (linux-image-3.19.1_3.19.1-1_amd64/linux-image-3.19.0-trunk-amd64 nel mio caso) e davvero non saprei se installare il kernel che ci si è compilati da soli con gli headers/dbg/libc-dev dei repository possa funzionare.
Inoltre mi piacerebbe sapere come creare un .deb a scelta e non i cinque di default.
Se qualcuno ha già la soluzione, che eviti il lungo processo di ricompilazione per provare dopo aver letto la documentazione, sarebbe davvero il benvenuto

Per il resto...
1) Ho provato a cambiare l'ordine di installazione (image e *poi* headers) e i moduli esterni non vengono compilati automaticamente.
Si risolve con un semplice:

Codice: Seleziona tutto

# dkms install nomemodulo/versionemodulo -k versionekernel

Nel mio caso, per VB:

Codice: Seleziona tutto

dkms install virtualbox/4.3.18 -k 3.19.1

Per cui (prima del comando):

Codice: Seleziona tutto

# dkms status
virtualbox, 4.3.18, 3.16.0-4-amd64, x86_64: installed

(dopo)

Codice: Seleziona tutto

# dkms status
virtualbox, 4.3.18, 3.16.0-4-amd64, x86_64: installed
virtualbox, 4.3.18, 3.19.1, x86_64: installed

2) Nella guida si dovrebbero eseguire i seguenti cambiamenti:
2a) Rimuovere le indicazioni sul gruppo "src" come segnalato da Aki nel primo post (modifica veloce)
2b) Controllare i pacchetti da installare in quanto non vedo "pkg-config" (modifica veloce ma serve un'installazione pulita di Debian)
2c) Cambiare "make-kpkg" con "make deb-pkg" (modifica sostanziale)
2d) Controllare se le opzioni del "make" valgono ancora (presumo di sì ma non mi sembra un'operazione tanto veloce).

Sul punto 2c: se ne dovrebbe discutere e decidere se mantenere i nick in verifica o rimuoverli in caso di sostituzione del comando.
Oppure scrivere una guida da zero.

[s3v]

Modificato la guida in accordo al punto 2a.
Restano gli altri punti e, se potete, leggete quella pagina per correggere eventuali errori.

[Ombra]

2c) io più che sostituire sarei per tenerli entrambi, in questo modo puoi lasciare anche i nick che hanno verificato.
Il motivo è che kpkg funziona ancora benissimo ed è più flessibile (io ad esempio uso ancora kpkg, anche solo per non creare 5 pacchetti ogni volta..).
Farei una prima parte coi comandi e spiegazione delle opzioni da usare con deb-pkg, poi di seguito comandi e opzioni con kpkg, specificando che il secondo è deprecato in favore del primo, ma che al momento è ancora funzionante e consente una maggiore flessibilità.
Terrei questa situazione fino al momento in cui
A) kpkg non fosse più funzionante/ uscisse dai repository e/o
B) deb-pkg "assorbe" la maggior parte delle opzioni mancanti

2b)
essendo a corto di tempo io modificherei la lista in questo modo

Codice: Seleziona tutto

 apt-get install module-init-tools kernel-package pkg-config libncurses5-dev fakeroot

fino a che qualcuno non ha tempo di fare un bootstrap e verificare se pkg-config viene installato di default

Nel caso nella 2c si decida di togliere completamente kpkg, segnalo che kernel-package si tira dietro parecchi pacchetti che secondo me servono per la compilazione, tipo build-essential e binutils e forse anche altri..

Oppure scrivere una guida da zero.

tu hai tempo da vendere!
concordo che la guida è un po' dispersiva, specialmente nella parte in fondo in cui si trattano vari argomenti che meriterebbero un approfondimento dedicato; in tal senso, in un secondo momento, si potrebbe pensare ad uno split della guida creando una pagina separata per le FAQ (sviluppandole meglio) e/o per quella sezione "Installare e gestire i moduli" che di sicuro meriterebbe una guida a parte

[s3v]

2c) io più che sostituire sarei per tenerli entrambi, in questo modo puoi lasciare anche i nick che hanno verificato.
Il motivo è che kpkg funziona ancora benissimo ed è più flessibile (io ad esempio uso ancora kpkg, anche solo per non creare 5 pacchetti ogni volta..).
Farei una prima parte coi comandi e spiegazione delle opzioni da usare con deb-pkg, poi di seguito comandi e opzioni con kpkg, specificando che il secondo è deprecato in favore del primo, ma che al momento è ancora funzionante e consente una maggiore flessibilità.
Terrei questa situazione fino al momento in cui
A) kpkg non fosse più funzionante/ uscisse dai repository e/o
B) deb-pkg "assorbe" la maggior parte delle opzioni mancanti

Buona idea. Ho notato anche io che "make-kpkg" funziona bene e ho avuto l'impressione che l'opzione "deb-pkg" sia molto più orientata agli sviluppatori e/o a chi vuole crearsi un pacchetto totalmente conforme alla policy.
Per me la guida si può lasciare com'è, bisogna solo rivedere le opzioni che ancora richiamano "/usr/src".
Sulle opzioni: da quanto fino ad ora sperimentato, ci sono tutte. In fondo sono opzioni di "make" e, a quanto ho visto, quelle passate a "make-kpkg" vengono "tradotte" in un formato comprensibile a "make".

2b)
essendo a corto di tempo io modificherei la lista in questo modo
Code:
apt-get install module-init-tools kernel-package pkg-config libncurses5-dev fakeroot

Ok, cambio. Con "apt-cache rdepends" non mi è parso che i pacchetti attuali si tirassero dietro "pkg-config", in ogni caso questo pacchetto è necessario se si vuole configurare con "xconfig" (presumo anche con "gconfig"). Per "menuconfig" non ci sono problemi.

tu hai tempo da vendere!
concordo che la guida è un po' dispersiva, specialmente nella parte in fondo in cui si trattano vari argomenti che meriterebbero un approfondimento dedicato; in tal senso, in un secondo momento, si potrebbe pensare ad uno split della guida creando una pagina separata per le FAQ (sviluppandole meglio) e/o per quella sezione "Installare e gestire i moduli" che di sicuro meriterebbe una guida a parte

Il tempo per fare qualcosa che mi piace e per imparare lo trovo sempre
E poi si tratterebbe di una mezz'ora al giorno.
L'idea dello split mi ha accarezzato in questi giorni ma serve parecchio tempo e, oltre alla pagina della gestione dei moduli, ce ne starebbe bene anche una sulle opzioni del "make" relative al kernel.
Comunque sempre disponibile a contribuire alla stesura se ci sono persone interessate

[Spoon]

Vorrei dare un piccolo feedback sulla guida in questione: oggi ho provato per la prima volta a compilare il kernel distribuito da Debian seguendola, e non ho riscontrato nessun problema nel lavorare in una sottodirectory della mia home. Ho notato invece una piccola incongruenza con la mia esperienza: i sorgenti del kernel (linux-source) sono stati scaricati in un archivio compresso di tipo .tar.bzip2, anzichè .tar.xz, vi risulta? Ho usato i sorgenti del kernel 3.2.

Non ho verificato la parte relativa all'installazione e alla gestione di moduli usando module-assistant. Ah, giusto per informazione, al boot c'è stato un kernel panic, quindi non sono ancora riuscito a cantare vittoria.

[s3v]

Grazie della conferma

Ho notato invece una piccola incongruenza con la mia esperienza: i sorgenti del kernel (linux-source) sono stati scaricati in un archivio compresso di tipo .tar.bzip2, anzichè .tar.xz, vi risulta? Ho usato i sorgenti del kernel 3.2.

Hai ragione.
Ora si è passati a compressioni più efficienti ma quel pacchetto crea un file bz2:
(3.16) https://packages.debian.org/jessie/all/ ... 6/filelist
(3.2) https://packages.debian.org/wheezy/all/ ... 2/filelist

Modifico la guida.