# [portage]Ridurre /usr/src senza compromettere gli ebuild

## Cazzantonio

Vorrei sapere come poter ridurre in modo "safe" le dimensioni della directory in /usr/src che contiene il kernel.

Volevo far stare gentoo in un hard disk molto piccolo, e avrei piacere di scendere sotto il giga di spazio occupato.

A parte portage (che è una menata discreta ma purtroppo necessaria), i sorgenti del kernel sono la cosa che mi occupa più spazio.

Vorrei cancellarli del tutto ma noto che molti ebuild necessitano di andare a ravanare in /usr/src per avere informazioni sul kernel attualmente in uso. (tra l'altro... non sono già contenute in /proc/config.gz ? )

Che cosa è tranquillamente cancellabile in /usr/src ? C'è qualcosa di cui si può fare a meno e risparmiare un po' di spazio senza impedire il corretto funzionamento degli ebuild?

----------

## falko

Bhe io dire Documentation  :Laughing:   :Laughing:   :Laughing: 

A parte gli scherzi, terrei sicuramente gli header file e il file di configurazione. Ma di preciso non saprei

----------

## HoX

emerge -C =gentoo-sources-<versione-che-NON-usi>

e lo ripeti per tutte le versioni che non usi.

puo' andare?

----------

## djinnZ

a parte documentation e arch/quelchenonhai non mi viene a mente molto.

----------

## Tigerwalk

 *Anema wrote:*   

> emerge -C =gentoo-sources-<versione-che-NON-usi>
> 
> e lo ripeti per tutte le versioni che non usi.
> 
> puo' andare?

 

Credo che lui abbia una sola versione installata e quello che vuole è fare "dimagrire" quella.

----------

## Onip

l'unica cosa che posso suggerire (oltre a quanto detto da djinnZ) è quella di dare

```
# make clean
```

dopo la compilazione.

per il fatto di proc/config.gz immagino dipenda dal fatto che questo è opzionale...

----------

## nikko96

Se provi ad eleminare i sorgenti del kernel,anche di quello in uso,rimane circa 2 M di roba,tra cui il .config.

Non so perchè accada questo,o meglio se sono tutti file creati dalla compilazione oppure se viene fatto per non

creare problemi ad alcuni ebuild,rimane il fatto però che in un eventuale ricompilazione del kernel

avrai di nuovo bisogno dei sorgenti.

Ciao.

----------

## makoomba

squashfs

----------

## Cazzantonio

 *falko wrote:*   

> A parte gli scherzi, terrei sicuramente gli header file e il file di configurazione. Ma di preciso non saprei

 

Appunto per questo ho fatto il post... è una cosa che non mi è mai stata molto chiara.

Esiste già un pacchetto sys-kernel/linux-headers, che praticamente è in system visto che viene tirato su dalle glibc. Che necessità c'è degli headers contenuti in /usr/src ? Non è che davvero basta lasciare il .config per quegli sparuti ebuild che cercano la configurazione del kernel?

Tra l'altro quest'ultima cosa è erronea, visto che non è detto che il .config nella directory dei sorgenti sia lo stesso del kernel in uso... secondo me gentoo farebbe meglio a richiedere, come standard, che il .config venga salvato da qualche parte in /etc/, oppure che /proc/config.gz sia abilitato di default.

 *makoomba wrote:*   

> squashfs

 Hai ragione, sarebbe la cosa migliore, tuttavia è una cosa laboriosa e il kernel viene aggiornato con una frequenza maggiore della mia voglia di stargli dietro con uno squashfs   :Smile: 

----------

## HoX

 *Cazzantonio wrote:*   

> Non è che davvero basta lasciare il .config per quegli sparuti ebuild che cercano la configurazione del kernel?
> 
> Tra l'altro quest'ultima cosa è erronea, visto che non è detto che il .config nella directory dei sorgenti sia lo stesso del kernel in uso... 

 

Teoricamente il link /usr/src/linux dovrebbe puntare sempre al kernel in uso (e se cosi' non fosse bisognerebbe aggiornarlo con eselect kernel set). Quindi è normale che vada a controllare quella cartella. Anche perche' non sarebbe detto che il file .config in etc sia quello corretto o aggiornato

----------

## devilheart

tieniti la configurazione e gli header, dovrebbe bastare così. al massimo fai un po' di esperimenti

----------

## djinnZ

Alcuni pacchetti tipo ntfs-3g layer7 iptables (in genere tutti quelli che creano dei moduli) etc. hanno necessità di verificare che il kernel sia stato opportunamente configurato quindi se non  trovano i sogenti la prendono a male e per ovvie necessità non possono puntare agli headers ma direttamente al kernel in uso.

Se non hai pacchetti del genere (per me è impossibile quindi non ho mai investigato oltre) lo puoi eliminare o potresti pensare di ridurlo ai soli headers ed al .config.

Per farlo dimagrire potresti anche pensare di eliminare i binari ovviamente. dovrebbe ridursi ad una decina di MB in questo modo.

----------

## Cazzantonio

Sono riuscito a ridurre l'occupazione dei sorgenti a soli 55 mega eliminando alcune directory presenti.   :Very Happy: 

Ho dovuto tenere qualcosa in arch, in include e la directory degli scripts. Penso che si potrebbe fare anche di meglio se qualcuno avesse voglia di spulciarsi le cartelle suddette e le funzioni di portage per vedere fino a che livello usano i files ivi contenuti.

Ho fatto uno script minuscolo per automatizzare l'operazione ad ogni aggiornamento del kernel

```
#!/bin/sh

ARCH=i386

PURGE_LIST="block crypto Documentation drivers fs init ipc kernel lib mm net se$

PURGE_VMLINUX="YES"

for i in `ls -F /usr/src/linux/arch/ |grep "\/"|grep -v $ARCH`; do

    /bin/rm /usr/src/linux/arch/$i -rf --preserve-root

done

for i in `ls -d /usr/src/linux/include/asm-*|cut -d "/" -f6-|grep -v $ARCH`; do

    /bin/rm /usr/src/linux/include/$i -rf --preserve-root

done

for i in $PURGE_LIST; do

    /bin/rm /usr/src/linux/$i -rf --preserve-root

done

if [ $PURGE_VMLINUX = YES ]; then

    /bin/rm /usr/src/linux/vmlinux* -rf --preserve-root

fi
```

----------

## djinnZ

aggiungerei anche un 

```
find /usr/src/linux -name *.o -exec rm
```

----------

## Scen

 *djinnZ wrote:*   

> aggiungerei anche un 
> 
> ```
> find /usr/src/linux -name *.o -exec rm
> ```
> ...

 

Se ti salvi il file .config da qualche parte, e dai

```

make mrproper

```

nella directory dei sorgenti del kernel, dovresti fare una bella pulizia anche dei file *.o.

----------

## Cazzantonio

Solo cinque mega, comunque tutto fa... comunque ancora non ho chiaro cosa cerchi portage in arch e in scripts...

L'unica funzione che guarda nei sorgenti che ho trovato è ExtractKernelVersion in /usr/lib/portage/pym/portage.py. Ma non basta andare a leggere /proc/version per avere la versione del kernel?

----------

## Scen

 *Cazzantonio wrote:*   

> Ma non basta andare a leggere /proc/version per avere la versione del kernel?

 

Ma siccome certi pacchetti DEVONO appoggiarsi ai sorgenti del kernel per poter compilare, non possono fare affidamento a /proc/version in quanto non è detto che il kernel in esecuzione in quel momento sia lo stesso dei sorgenti presenti in /usr/src/linux.

----------

## Cazzantonio

 *Scen wrote:*   

> Ma siccome certi pacchetti DEVONO appoggiarsi ai sorgenti del kernel per poter compilare, non possono fare affidamento a /proc/version in quanto non è detto che il kernel in esecuzione in quel momento sia lo stesso dei sorgenti presenti in /usr/src/linux.

 Ti capisco, tuttavia ho provato ad installare pacchetti che  cercano il kernel, come ad esempio iptables, e sono stati compilati anche con i sorgenti "epurati", segno che a quanto pare non necessitano davvero dei sorgenti del kernel. Probabilmente bastano gli headers, o sbaglio?

Sicuramente esistono anche dei pacchetti a cui servono i sorgenti veri e propri, sai indicarmi quali sono?

Tra l'altro il kernel potrebbe essere stato compilato su una macchina diversa e copiato sulla macchina attuale. Si potrebbe trattare anche di una macchina che fa il boot da rete... come si comporta portage in questi casi? E' necessario esportare via nfs la directory dei sorgenti per poter usare portage su una macchina del genere?

----------

## cloc3

 *Cazzantonio wrote:*   

> 
> 
> Tra l'altro il kernel potrebbe essere stato compilato su una macchina diversa e copiato sulla macchina attuale. Si potrebbe trattare anche di una macchina che fa il boot da rete...

 

e davvero non riesci ad organizzarti con un mount da nfs?

io tengo sempre tutti i miei kernel su una sola macchina server.

il kernel originale resta pulito pulito come mamma lo ha fatto e compilo con dei mount di differenze (aufs) su cartelle separate da apposite etichette.

----------

## Cazzantonio

 *cloc3 wrote:*   

> e davvero non riesci ad organizzarti con un mount da nfs?

 Il mount via nfs è un'opzione, non sempre è detto che sia possibile o auspicabile. Comunque non cercavo aiuto per nfs, stavo solo chiedendo se portage offriva altre opzioni che non richiedessero una configurazione di rete particolare.

In alcune evenienze è comodo evitare di dover scaricare tutti i sorgenti, e tuttavia non è disponibile una macchina server da dedicare ad ospitarli.

Magari è impossibile, tutto qui, eppure vorrei capire davvero quali pacchetti hanno bisogno dei sorgenti del kernel e perché.

----------

## djinnZ

dimenticavo che forse puoi anche provare ad eliminare *.cmd

----------

## Cazzantonio

Ora provo, comunque ancora sto cercando di capire quali siano i pacchetti che hanno bisogno dei sorgenti e come portage si appoggi ai medesimi... forse dovrei chiedere ad un developer di portage (o leggermi tutto il codice   :Smile:  )

----------

## cloc3

 *Cazzantonio wrote:*   

>  (o leggermi tutto il codice   )

 

di tutto il Software...

secondo me, una risposta definitiva non la troverai mai, perché può sempre uscire un pacchetto nuovo che, per installarsi, ficca il naso in un posto che tu non avevi previsto. sia pure per errore, e perché il programmatore non ha pensato a cercare l'informazione in un posto più adatto.

è anche per questo che, prima, ragionavo su soluzioni alternative.

----------

## Cazzantonio

Hai ragione, ma guardando le funzioni di portage che controllano il kernel uno si può fare un idea di cosa vadano a cercare i pacchetti.

Per questo chiedevo se qualcuno aveva idea delle linee guida dei developers riguardo ai pacchetti che hanno bisogno del kernel. Non penso siano una lista infinita...

----------

## djinnZ

potresti incominciare a filtrare tutti gli ebuild che hanno la chiamata ad ExtractKernelVersion oppure potresti provare chiamare le funzioni usate dall'ebuild degli headers direttamente sul kernel installato. In arch ci sono alcuni headers specifici della versione in uso ma in scripts non dovrebbe esserci nulla di utile.

----------

## HoX

Potresti anche rimuovere completamente il kernel e la volta che ti capita un ebuild che te lo richiede in 2 minuti lo recuperi (ovviamente salvati il file .config)

----------

## Cazzantonio

Volevo trovare una soluzione per evitare di dover scaricare i sorgenti su quella macchina. O passo da nfs (preferirei di no) o trovo un modo per ingannare portage e fargli credere che ho una certa versione del kernel.

Fino ad adesso non ho trovato pacchetti che usino i sorgenti del kernel altro che per guardarne versione e configurazione... sto cercando di vedere se tra i pacchetti che uso qualcuno di essi necessita effettivamente dei sorgenti interi.

----------

