Forse, dovrei cambiare distro?

[ninja]

I pacchetti sono 3, il kernel (linux-image), l'initrd (l'immagine con i moduli che il kernel può caricare in fase di boot senza l'obbligo di aver montato il filesystem della partizione /) e gli headers (utilizzati dai compilatori, tipo gcc, indispensabili se si compila e installa qualcosa direttamente dal codice sorgente o se si installano i driver proprietari di Nvidia e ATI/AMD).

[Zievatron]

Quindi devo dare:

Codice: Seleziona tutto

# dpkg -i

seguito dai nomi di tutti e tre i pacchetti?

[Zievatron]

Provato. Ho la nuova voce di kernel come prima selezione in grub.

[ninja]

Ottimo, se tutto funziona non ti resta che provare a compilarlo apportando qualche modifica...

... parti da quelle che ti ho consigliato, magari dal menù del processore per scegliere la famiglia dei processori per la quale compilare il kernel.

Già con le prime ottimizzazioni dovresti accorgerti di qualche miglioramento nella velocità di risposta del sistema.

[Zievatron]

Ho trovato questo script perl che dovrebbe eseguire una ottimizzazione in automatico e l'ho provato. L'ho usato al posto del .config.

Questa volta è andata male.
Il tempo di compilazione è stato sicuramente minore. Al massimo due ore.
Dopo l'installazione, al riavvio, Grub riconosce il nuovo kernel, ma non funziona.
Ottengo dei messaggi di errore.
Il primo:

Codice: Seleziona tutto

i8042: no controller found

E' un messaggio di errore che avevo anche prima, ma tutto proseguiva come se niente fosse.
Ora, invece, mi compaiono anche queste righe:

Codice: Seleziona tutto

Kernel panic-not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Pid: 1, comm: swapper not tainted 3.2.54mioricompilatoperla #3
Call Trace:
... ...

Seguono delle righe di Call Trace, che ho omesso. Se servono riprovo e le trascrivo.

[Zievatron]

Penso di aver proprio sbagliato. Ho copiato lo script "al posto" del .config.
Invece è una cosa che si deve eseguire. Ma se lo davo come comando non veniva riconosciuto.

[Zievatron]

Ho capito.
Tentavo di eseguirlo come un comando normale, invece dovevo prima dirgli che è uno script perl.
Vabbhè, ora mi ritrovo già con due kernel supplementari di prova installati.
Prima di proseguire, come ripulisco il sistema di queste prove?

[ninja]

Per rimuovere è semplice...

Codice: Seleziona tutto

apt-get remove nomepacchetto1 nomepacchetto2 nomepacchetto3...

[Zievatron]

Ah! Quindi vale anche per i pacchetti che ho creato io.
Non dovrebbe essere più adatto purge di remove?

[Zievatron]

Ho provato, ma risponde che è impossibile trover il pacchetto nomepacchetto ...

[ninja]

Non dovrebbe essere più adatto purge di remove?

purge rimuove anche i file di configurazione (non è il caso del kernel, quindi le due opzioni si equivalgono).

Al posto di nomepacchetto devi mettere il pacchetto del kernel...

.. nel caso del mio sistema, in cui non ho ancora installato un kernel compilato, sarebbe qualcosa del tipo:

Codice: Seleziona tutto

sudo apt-get remove linux-image-3.8.0-12-generic

[Zievatron]

Allora non so qual'è il nome esatto che devo inserire.
Lo stesso del pacchetto .deb creato con qualcosa in meno alla fine?

[ninja]

Il nome del pacchetto senza il .deb

[Zievatron]

Ho provato ad usare il comando

Codice: Seleziona tutto

dpkg --list "linux-image-*

Ho visto che i nomi che vengono fuori sono troncati. Dovrebbero finire rispettivamente con "perla" e "uguale". Invece li vedo finire con "per" e "ugu".

Ho usato apt-get purge dando "*" al posto della parte finale del nome. Ha funzionato!
Però solo con i pacchetti con il nome.
I pacchetti linux-libc-dev_1.0_amd64.deb e linux-libc-dev_1_amd64.deb ha continuato a non trovarli. Con questi non ci provo a tagliare il nome con "*" perchè non vorrei che disinstallasse qualcos'altro che mi serve.

[ninja]

I pacchetti linux-libc-dev_1.0_amd64.deb e linux-libc-dev_1_amd64.deb ha continuato a non trovarli.

Probabilmente li trova nel database (perché con * potresti includerli) ma non può rimuoverli perché non li ha mai installati, a volte capita.

[Zievatron]

La prova con lo script perl ha funzionato.
Ora devo provare a fare di meglio.

[Zievatron]

...
... selezioni il processore, o meglio la famiglia di processori a cui appartiene la tua CPU per ottenere la maggiore ottimizzazione, se invece vuoi considerare che spesso è garantita la retrocompatibilità e vuoi il maggior supporto a tutti i sistemi possibili, se imposti I486 avrai il maggior supporto ma la minor ottimizzazione (tutti i PC degli ultimi 20 anni), con I686 dal Pentium II in poi (praticamente tutti i PC da 15 a questa parte),.. io opterei per la prima scelta, la famiglia del tuo processore.

Se scegli l'ottimizzazione, come ti ho consigliato, disabilita il supporto al codice generico per piattaforma X86, il codice generato sarà più piccolo e più veloce.
....

Questa è la prima cosa che mi proponevo di fare, ma...
In
Processor type and features --->
Processor family (Generic-x86-64) --->
Trovo soltanto
( ) Opteron/Athlon64/Hammer/K8
( ) Intel P4 / older Netburst based Xeon
( ) Core 2/newer Xeon
( ) Intel Atom
(X) Generic-x86-64

Tutto quì?! Alla faccia dell'ottimizzazione! Ed io che mi aspettavo minimo due dozzine di voci!
Possibile che non ci sia niente di meno generico?!
Il mio PC ha la AMD APU E450, debbo dunque restare nella massima genericità?

[ale2695]

Ad oggi i due principali produttori di CPU (Intel ed AMD) usano proprio il driver generico su Linux, applicando poi varie patch separate all'interno del kernel per migliorarne il supporto. Quindi si, mi spiace, ma sono solo quelle le voci selezionabili per le CPU

[Zievatron]

... sono solo quelle le voci selezionabili per le CPU

Intanto ho provato a fare un po' di deselezioni con Make Menuconfig.
Ho copiato il .config in .configperla.
Ho preso nota di tutto quello che ho deselezionato in Make Menuconfig (38 voci, per incominciare).
La compilazione ha preso un 2h e mezza di tempo.
Ho installato i nuvi pacchetti, ho spento ed ho riacceso. Non rilevo nessun problema, dunque...
Ha funzionato!
Non ho combinato nessun pasticcio.
Allora posso provare ad andare oltre.

[Zievatron]

Ho eseguito una nuova sfoltita di un 30 voci.

Questa volta è andata male. La compilazione è finita con quest'output:

Codice: Seleziona tutto

  OBJCOPY arch/x86/boot/vmlinux.bin
  HOSTCC  arch/x86/boot/tools/build
  CPUSTR  arch/x86/boot/cpustr.h
  ZOFFSET arch/x86/boot/zoffset.h
  CC      arch/x86/boot/cpu.o
  AS      arch/x86/boot/header.o
  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  BUILD   arch/x86/boot/bzImage
Setup is 16976 bytes (padded to 17408 bytes).
System is 2103 kB
CRC 3dcf5ad1
Kernel: arch/x86/boot/bzImage is ready  (#1)
ERROR: "sctp_do_peeloff" [fs/dlm/dlm.ko] undefined!
make[3]: *** [__modpost] Error 1
make[2]: *** [modules] Error 2
make[1]: *** [deb-pkg] Error 2
make: *** [deb-pkg] Error 2

Si capisce cosa ho sbagliato?

[Zievatron]

Ho provato a googlare su "sctp_do_peeloff", ma a parte il fatto che stcp è un protocollo di comunicazione non ho trovato nulla di illuminante. Ho provato a guardare gli help di ogni voce che ho deselezionato questa volta, caso mai qualcuna indicasse qualcosa. Ma non ho visto niente. Io non saprei fare altro che ricominciare da un passo indietro con meno deselezioni.

[Zievatron]

L'HO TROVATO!!!
Mi ha fatto sbattere la testa, perchè lo consideravo uno dei più sicuri che non servisse, perchè come viene descritto sembra che serva solo agli sviluppatori e tester delle versioni alpha de software.
E' la voce:

Codice: Seleziona tutto

General setup  --->
         [ ] Prompt for development and/or incomplete code/drivers 

Non ho la più pallida idea del perchè e sono sorpreso che, invece, risulta indispensabile e la sua mancanza produce nella compilazione l'errorre:

Codice: Seleziona tutto

Setup is 16976 bytes (padded to 17408 bytes).
System is 2210 kB
CRC dd9ea090
Kernel: arch/x86/boot/bzImage is ready  (#1)
ERROR: "sctp_do_peeloff" [fs/dlm/dlm.ko] undefined!
make[3]: *** [__modpost] Error 1
make[2]: *** [modules] Error 2
make[1]: *** [deb-pkg] Error 2
make: *** [deb-pkg] Error 2

[Zievatron]

Mi sono accorto di un difetto che, forse, avevo introdotto già da prima.
Con il kernel originale, quando nel terminale dò halt, ottengo un momentaneo passaggio al login testuale e poi lo spegnimento completo del PC.
Con il mio ricompilato, invece, passato al login testuale, compare la scritta "system halted" ma il PC non si spegne.
C'è un altro modo per capire la causa? O devo ripetere la caccia alla modifica che lo causa attraverso una nuova serie di ricompilazioni?

P.S.: Ora sono alla decima ricompilazione. Dopo quante ricompilazioni non si esce più dal tunnel?

[Zievatron]

Ho confrontato le modifiche fatte ai .config che avevo ed trovato cos'era.
Avevo deselezionato la voce "ACPI (Advanced Configuration and Power Interface) Support ---> che, evidentemente, serviva.

[ninja]

...la voce "ACPI (Advanced Configuration and Power Interface) Support ---> che, evidentemente, serviva.

Io semmai disabilito l'APM che è la tecnologia che è stata sostituita, ovvero resa obsoleta, dall'ACPI.

Inoltre, in un portatile (notebook e netbook) l'ACPI è fondamentale per abilitare tutte le funzionalità di risparmio energetico, incluse le variazioni di frequenza e alimentazione del processore, che sono utilissime permettendo una durata maggiore della batteria.