Configurazione kernel Linux

Note:

I kernel 2.6.39.2 sono stati riconfigurati nei primi di luglio 2011 per effettuare questi cambiamenti (mantenuti nei kernel successivi):

La prima modifica si è resa necessaria perché Wine ad ogni esecuzione abortiva con il laconico messaggio: Ucciso (Killed, usando una localizzazione inglese del terminale).  La modifica abbandona il modello di memoria 2G/2G user/kernel split (for full 2G low memory) (nome della voce in Linux/i386 Memory Access).

La voce CONFIG_ZONE_DMA serve per i dispositivi dotati di uno spazio di indirizzi a meno di 32 bit:

DMA memory allocation support allows devices with less than 32-bit addressing to allocate within the first 16MB of address space. Disable if no such devices will be used.

Questa opzione non si è rivelata necessaria per i PC Atom N450, Atom D525, Pentium III 1000 e AMD E350.

1) La terza colonna è stata introdotta il 05/03/2013.  Per i dati immessi prima essere indicato, per una certa versione della distribuzione, un kernel usato in una versione prececente a quella dichiarata.2) I kernel successivi alla serie 3.0 non funzionano con l'ACPI attivato su questo portatile per il noto problema delle tabelle DSDT (Differentiated System Description Table), facenti parte del sistema ACPI (Advanced Configuration and Power Interface), che non osservano fedelmente le specifiche ACPI e che sono state compilate con il compilatore Microsoft, piuttosto permissivo con i loro errori di sintassi.  Inoltre i kernel Linux più recenti evidentemente hanno perso qualcosa della vecchia capacità di raggirare questi errori sintattici.  Ancora non mi è riuscito di farli funzionare senza disattivare l'ACPI (parametro del kernel acpi=off).  Nel mio caso il problema si manifesta con il kernel che scrive a ripetizione righe come questa senza procedere oltre nella fase di avvio:

udevd[411]: timeout: killing '/sbin/modprobe -bv acpi:ACPI0002:' [565]

Per ulteriori informazioni in proposito e tecniche di soluzione si legga:

1. https://wiki.archlinux.org/index.php/DSDT e i suoi rimandi:

2. http://acpi.sourceforge.net/dsdt/ e

3. http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems

3) Per ottenere questi dati, non avendo la Fedora un pacchetto pnputils, sono stati copiati da una Debian i file /sbin/lspnp, /usr/share/misc/pnp.ids e /usr/share/man/man8/lspnp.8.gz.

4) Per poter compilare il kernel 3.1.1 (e altri successivi, anche su altre macchine) si è dovuto disabilitare la voce (nuova) CONFIG_DEBUG_STRICT_USER_COPY_CHECKS, situata in: Kernel hacking -> Strict copy size checks.  La descrizione di questa opzione è riportata nel quadro seguente:

Strict copy size checks CONFIG_DEBUG_STRICT_USER_COPY_CHECKS: Enabling this option turns a certain set of sanity checks for user copy operations into compile time failures. The copy_from_user() etc checks are there to help test if there are sufficient security checks on the length argument of the copy operation, by having gcc prove that the argument is within bounds. If unsure, or if you run an older (pre 4.4) gcc, say N.

  In fase di compilazione la sua attivazione causava questo messaggio d'errore:

CHK     include/linux/version.h   CHK     include/generated/utsrelease.h   CALL    scripts/checksyscalls.sh   CHK     include/generated/compile.h   CC [M]  fs/binfmt_misc.o In file included from /tmp/linux-3.1/arch/x86/include/asm/uaccess.h:573:0,                  from include/linux/uaccess.h:5,                  from include/linux/highmem.h:7,                  from include/linux/pagemap.h:10,                  from fs/binfmt_misc.c:26: /tmp/linux-3.1/arch/x86/include/asm/uaccess_32.h: In function ‘parse_command.part.0’: /tmp/linux-3.1/arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct make[1]: *** [fs/binfmt_misc.o] Errore 1 make: *** [fs] Errore 2

5) Questi kernel e i successivi sono stati compilati seguendo le istruzioni del sito Fedoraproject.  Il primo kernel prodotto, per quanto riguarda le dimensioni, ha queste caratteristiche rispetto a quello della distribuzione:

# ls -oh /boot -rw-r--r--  1 root 4.6M Dec 17 23:57 vmlinuz-3.6.11-5.fc17.i686 -rw-r--r--  1 root 2.7M Jan 21 22:13 vmlinuz-3.6.11-5.niraya.fc17.i686 # du /usr/lib/modules/3.6.11-* 87M     /usr/lib/modules/3.6.11-5.fc17.i686 39M     /usr/lib/modules/3.6.11-5.niraya.fc17.i686

Con Fedora17 per far funzionare Xorg con l'accelerazione fornita dal driver libero nouveau invece di quello propritario nvidia ho dovuto disinstallare i pacchetti seguenti forniti dal repository RPMFusion:

• xorg-x11-drv-nvidia-304.64-3.fc17.i686

• kmod-nvidia-3.6.11-5.fc17.i686-304.64-1.fc17.7.i686

• xorg-x11-drv-nvidia-libs-304.64-3.fc17.i686

spostare altrove i file /etc/X11/xorg.conf.d/00-nvidia.conf e /etc/ld.so.conf.d/nvidia-lib.conf, cancellare il collegamento simbolico /usr/lib/xorg/modules/nvidia-304.64 (che puntava a ../../nvidia/xorg) e modificare il file /etc/X11/xorg.conf per trasformare la riga Driver "nvidia" in Driver "nouveau" nella sezione "Device":

# RPM Fusion - nvidia-xorg.conf # Section "Device"         Identifier  "Videocard0"         #Driver      "nvidia"         Driver      "nouveau" EndSection

Con Fedora18 invece è stato necessario spostare in altra directory il file /etc/ld.so.conf.d/nvidia-lib.conf e aggiungere, nel file /etc/X11/xorg.conf, le righe seguenti:

Section "Files"         ModulePath "/usr/lib/xorg/modules"         ModulePath "/usr/lib/nvidia/xorg" EndSection

6) Nella Fedora 18 la compilazione dei kernel falliva con questo messaggio d'errore:

[alessandro@niraya]$ rpmbuild -bb --without debug --without xen --without smp --without pae --without kdump --without debuginfo --with baseonly --target="$(uname -m)" kernel.spec [...] + read i + grep -E -v 'GPL( v2)?$|Dual BSD/GPL$|Dual MPL/GPL$|GPL and additional rights$' modinfo + rm -f modinfo modnames + /home/alessandro/rpmbuild/SOURCES/mod-extra.sh /home/alessandro/rpmbuild/BUILDROOT/kernel-3.8.1-201.niraya.fc18.i386/lib/modules/3.8.1-201.niraya.fc18.i686 /home/alessandro/rpmbuild/SOURCES/mod-extra.list ~/rpmbuild/BUILDROOT/kernel-3.8.1-201.niraya.fc18.i386/lib/modules/3.8.1-201.niraya.fc18.i686 ~/rpmbuild/BUILD/kernel-3.8.fc18/linux-3.8.1-201.niraya.fc18.i686 ~/rpmbuild/BUILD/kernel-3.8.fc18/linux-3.8.1-201.niraya.fc18.i686 ~/rpmbuild/BUILDROOT/kernel-3.8.1-201.niraya.fc18.i386/lib/modules/3.8.1-201.niraya.fc18.i686 ~/rpmbuild/BUILD/kernel-3.8.fc18/linux-3.8.1-201.niraya.fc18.i686 ~/rpmbuild/BUILD/kernel-3.8.fc18/linux-3.8.1-201.niraya.fc18.i686 + cp -r .tmp_versions .tmp_versions.sign + cp signing_key.priv signing_key.priv.sign cp: cannot stat 'signing_key.priv': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.VwU93X (%build) RPM build errors:     Bad exit status from /var/tmp/rpm-tmp.VwU93X (%build)

  Le ragioni di quest'errore sono spiegate in questa pagina: Can't build own kernel; in breve, a partire dalla versione 18 di Fedora, la procedura di creazione del pacchetto rpm del kernel tenta di firmare i moduli dei sorgenti ufficiali, possibilità introdotta a partire dal kernel 3.7.  Questa firma digitale è attivata passando in fase di avvio al kernel il parametro "enforcemodulesig=1".  La cosa presenta due problemi: per prima cosa bisogna fornire al processo una chiave crittografica; in secondo luogo la Fedora ancora non imposta di default il parametro di avvio "enforcemodulesig=1", e quindi, a meno di non prendersi cura di eseguire entrambi questi passi manualmente e se non si hanno troppi dubbi sulla resistenza del sistema agli attacchi, è nella maggioranza dei casi poco utile attivare questa funzione (che è descritta nei dettagli su questa pagina).
  Si può quindi procedere a disattivare la firma automatica dei moduli aprendo con un editor di testo il file ~/rpmbuild/SPECS/kernel.spec per modificare, per la propria architettura, la riga:

%global signmodules 1

in:

%global signmodules 0

7) Ho notato che è necessario assicurarsi che nella configurazione del kernel la voce General setup  ---> () Local version - append to kernel release (ossia il campo CONFIG_LOCALVERSION) sia vuota, altrimenti il kernel installato cercherà i propri moduli in /lib/modules/${KERNEL_VERSION}${LOCALVERSION} mentre questi saranno installati in /lib/modules/${KERNEL_VERSION}.

8) La compilazione di questo kernel si arrestava con l'errore seguente:

Extracted 16 tokens Extracted 1 types Extracted 1 actions Pass 1 Pass 2 crypto/asymmetric_keys/x509_public_key.c: In function 'x509_key_preparse': crypto/asymmetric_keys/x509_public_key.c:237:35: error: 'system_trusted_keyring' undeclared (first use in this function)    ret = x509_validate_trust(cert, system_trusted_keyring);                                    ^ crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Errore 1 make[1]: *** [crypto/asymmetric_keys] Errore 2 make: *** [crypto] Errore 2 make: *** Attesa dei processi non terminati.... + exit 1 errore: Stato d'uscita errato da /var/tmp/rpm-tmp.1SmKRY (%build) Errori di compilazione RPM:     Stato d'uscita errato da /var/tmp/rpm-tmp.1SmKRY (%build)

Seguendo le risultanze esposte su http://www.gossamer-threads.com/lists/linux/kernel/1801173 e su http://lists-archives.com/linux-kernel/27949520-linux-3-13-rc1-is-out.html, ho cambiato dalla configurazione la voce:

CONFIG_X509_CERTIFICATE_PARSER=y

in:

# CONFIG_X509_CERTIFICATE_PARSER is not set

Questa voce si trova seguendo il percorso:

Cryptographic API -> <M> Asymmetric (public-key cryptographic) key type -> <M> Asymmetric public-key crypto algorithm subtype (CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE)

Il problema non si è più presentato con il kernel 3.13.3-201 e successivi.

9) La voce CONFIG_X509_CERTIFICATE_PARSER è stata reintrodotta senza che la compilazione fallisse (si veda la nota 8)
10) In questo portatile si è riscontrato un problema con il touchpad.  Il kernel Linux 3.10.7 (e successivi, esclusi almeno quelli successivi al 3.14.13, vedasi nota 11) lo considera un banale topo PS/2, non un touchpad (kernel ):

[alessandro@ayu ~]$ xinput ⎡ Virtual core pointer                          id=2    [master pointer  (3)] ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)] ⎜   ↳ HID 062a:0000                             id=12   [slave  pointer  (2)] ⎜   ↳ PS/2 Generic Mouse                        id=14   [slave  pointer  (2)] ⎣ Virtual core keyboard                         id=3    [master keyboard (2)]     ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]     ↳ Power Button                              id=6    [slave  keyboard (3)]     ↳ Fujitsu FUJ02E3                           id=7    [slave  keyboard (3)]     ↳ Video Bus                                 id=8    [slave  keyboard (3)]     ↳ Fujitsu FUJ02B1                           id=9    [slave  keyboard (3)]     ↳ Power Button                              id=10   [slave  keyboard (3)]     ↳ FJ Camera                                 id=11   [slave  keyboard (3)]     ↳ AT Translated Set 2 keyboard              id=13   [slave  keyboard (3)]

Per risolvere ho seguito le indicazioni fornite su http://nwoki.wordpress.com/2012/10/02/multitouch-fix-for-alps-touchpad/, tranne per il dettaglio di non aver sostituito il file psmouse.c dell'archivio http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/at_download/file (file di archivio psmouse-alps-1.3-alt.tbz) con il file http://pastebin.com/raw.php?i=m404GW1G.  Farlo causava il fallimento della compilazione, e il file del sito pastebin.com è più vecchio dell'ultima versione dell'archivio disponibile sul sito www.dahetral.com, che è la versione 1.3 ancora il giorno della scrittura di queste note, il 03 maggio 2014.

Scompattato l'archivio (psmouse-alps-1.3-alt.tbz) in /usr/src/psmouse-alps-1.3, si sono eseguiti questi comandi come superutente (root):

dkms add psmouse/alps-1.3 dkms build psmouse/alps-1.3 dkms install psmouse/alps-1.3

Per i kernel successivi, l'installazione del file immagine del kernel compilati con il comando make-kpkg aggiunge automaticamente il modulo sostitutivo /usr/src/psmouse-alps-1.3/ a quello del kernel, installando il primo nel modulo /lib/modules/"$(uname -r)"/updates/dkms/psmouse.ko.  Usando questo modulo il touchpad funziona correttamente se si configura Xorg inserendo lo specifico file di configurazione /etc/X11/xorg.conf.d/50-synaptics.conf.  Il sistema riconosce adesso in questo modo il touchpad:

[alessandro@ayu ~]$ xinput ⎡ Virtual core pointer                          id=2    [master pointer  (3)] ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)] ⎜   ↳ HID 062a:0000                             id=12   [slave  pointer  (2)] ⎜   ↳ PS/2 Mouse                                id=14   [slave  pointer  (2)] ⎜   ↳ AlpsPS/2 ALPS GlidePoint                  id=15   [slave  pointer  (2)] ⎣ Virtual core keyboard                         id=3    [master keyboard (2)]     ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]     ↳ Power Button                              id=6    [slave  keyboard (3)]     ↳ Fujitsu FUJ02E3                           id=7    [slave  keyboard (3)]     ↳ Video Bus                                 id=8    [slave  keyboard (3)]     ↳ Fujitsu FUJ02B1                           id=9    [slave  keyboard (3)]     ↳ Power Button                              id=10   [slave  keyboard (3)]     ↳ FJ Camera                                 id=11   [slave  keyboard (3)]     ↳ AT Translated Set 2 keyboard              id=13   [slave  keyboard (3)] [alessandro@ayu ~]$ sudo lsinput [...] /dev/input/event6    bustype : BUS_I8042    vendor  : 0x2    product : 0x8    version : 0    name    : "PS/2 Mouse"    phys    : "isa0060/serio1/input1"    bits ev : EV_SYN EV_KEY EV_REL [...] /dev/input/event14    bustype : BUS_I8042    vendor  : 0x2    product : 0x8    version : 1280    name    : "AlpsPS/2 ALPS GlidePoint"    phys    : "isa0060/serio1/input0"    bits ev : EV_SYN EV_KEY EV_ABS

11) Nel kernel 3.14.13 si è potuto disabilitare il modulo esterno di cui la nota 10, essendo il suo modulo nativo psmouse.ko capace di riconoscere correttamente il dispositivo di input AlpsPS/2 ALPS GlidePoint.

Ultimo aggiornamento: 2016/01/23

< Torna al livello superiore <
<< Torna alla pagina iniziale <<