Difference between revisions of "Mkinitcpio (Italiano)"

From ArchWiki
Jump to: navigation, search
(use https for links to archlinux.org)
(out of date)
Line 1: Line 1:
 +
{{out_of_date|Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese.|Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}
  
 
[[Category:Boot process (Italiano)]]
 
[[Category:Boot process (Italiano)]]

Revision as of 09:44, 7 May 2013

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. (Discuss in Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme")
Template:Article summary start

Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary end

mkinitcpio è un generatore initramfs di ultima generazione initramfs.

Introduzione

mkinitcpio è uno script bash usato per generare un iniziale ambiente ramdisk. Da mkinitcpio man page:

Il ramdisk iniziale è in sostanza un ambiente molto ridotto ("pre-userspace"), che carica vari moduli del kernel e imposta le operazioni preliminari necessarie prima di consegnare il controllo ad init. In questo modo è possibile avere, ad esempio, filesystem criptati e filesystem su software RAID. L'mkinitcpio permette inoltre estensioni con hooks personalizzati, rilevamento automatico in fase di runtime, e molte altre caratteristiche.

Tradizionalmente, il kernel è il responsabile del rilevamento dell'hardware e dei compiti di inizializzazione nelle prime fasi del boot process, prima di montare il filesystem root e passare il controllo a init. Tuttavia, con il progredire della tecnologia, queste attività sono diventate sempre più complesse.

Al giorno d'ggi, il filesystem root può essere installato su una vasta gamma di hardware, da SCSI a SATA a USB, monitorato da una serie di controller di unità di produttori diversi. Inoltre, il filesystem root può essere compresso o criptato, all'interno di un software RAID o di un gruppo di volumi logici. Il modo più semplice per gestire questa serie di complessità, è passare la gestione all'ambiente userspace: il ramdisk iniziale.

Consultare: /dev/brain0 » Blog Archive » Early Userspace in Arch Linux.

mkinitcpio è uno strumento modulare per la costruzione di un'immagine init ramfs cpio, che offre molti vantaggi rispetto ai metodi alternativi, tra cui:

  • L'utilizzo di busybox, che fornisce una base minimale e leggera per l'ambiente userspace (prima della versione 0.6, veniva utilizzato klibc).
  • Il supporto per udev per il rilevamento automatico dell'hardware in fase di esecuzione, impedendo così il caricamento di moduli non necessari.
  • Essere un init script espandibile basato su hook; hooks personalizzati possono facilmente venir inclusi nei pacchetti pacman.
  • Supporto per lvm2, dm-crypt per entrambi i volumi legacy e LUKS, raid, mdadm, e swsusp e suspend2 per la ripresa e l'avvio da dispositivi di archiviazione di massa USB.
  • La capacità di permettere molte caratteristiche per poter essere configurato dalla riga di comando del kernel, senza la necessità di ricostruire l'immagine.
  • Supporto per l'inserimento dell'immagine nel kernel, rendendo così l'immagine del kernel autosufficiente.

mkinitcpio è stato sviluppato da phrakture, tpowa e brain0 con vari aiuti da parte della comunità. Recentemente lo sviluppo è portato avanti da falconindy.

Installazione

Il pacchetto mkinitcpio è disponibile nei repositories ufficiali, ed è installato in modo predefinito in quanto incluso nel gruppo base.

Per gli utenti che preferiscono installare l'ultima versione in sviluppo di mkinitcpio da Git:

$ git clone git://projects.archlinux.org/mkinitcpio.git
Note: È fortemente consigliabile seguire le mailing list del progetto Arch se si intende utilizzare la versione git di mkinitcpio!

Creazione dell'immagine ed attivazione

Per impostazione predefinita, lo script mkinitcpio genera due immagini dopo l'installazione o l'aggiornamento del kernel: /boot/initramfs-linux.img e /boot/initramfs-linux-fallback.img. L'immagine fallback utilizza lo stesso file di configurazione come l'immagine predefinita, ad eccezione dell' hook autodetect che è saltato durante la creazione, includendo quindi anche una vasta gamma di moduli. L'hook di rilevazione (autodetect) automatica rileva i moduli necessari e personalizza l'immagine per hardware specifico, riducendo l'initramfs.

Gli utenti possono creare quante immagini initramfs desiderano, con differenti profili di configurazione. L'immagine desiderata deve essere specificato per il bootloader, spesso nelle sue file di configurazione (/boot/grub/menu.lst per gli utilizzatori di GRUB Legacy). Dopo le modifiche apportate al file di configurazione, l'immagine deve essere rigenerata. Per lo stock kernel di Arch Linux, questo si ottiene con il comando:

# mkinitcpio -p linux

L'opzione -p indica un "preset" da utilizzare; la maggior parte dei pacchetti kernel fornisce un mkinitcpio predefinito, che si trova in /etc/mkinitcpio.d (per esempio /etc/mkinitcpio.d/linux.preset per linux). Un preset è una definizione predefinita di come creare una immagine initramfs invece di specificare il file di configurazione e il file di output ogni volta.

Attenzione: I file preset vengono utilizzati per rigenerare automaticamente l'initramfs dopo un aggiornamento del kernel; fare attenzione quando li si modifica.

Gli utenti possono creare manualmente un'immagine utilizzando una configurazione alternativa del file:

# mkinitcpio -c /etc/mkinitcpio-custom.conf -g /boot/linux-custom.img

Questo genererà l'immagine initramfs per il kernel attualmente in esecuzione per poi salvarli su /boot/linux-custom.img.

Per la creazione dell'immagine di un kernel diverso da quello attualmente in esecuzione, aggiungere la versione del kernel alla riga di comando:

# mkinitcpio -g /boot/linux.img -k 3.0.0-ARCH

Configurazione

Il file di configurazione principale di mkinitcpio è /etc/mkinitcpio.conf. Inoltre, le definizioni di preset sono fornite dai pacchetti del kernel nella cartella /etc/mkinitcpio.d (per esempio /etc/mkinitcpio.d/linux.preset).

Attenzione: lvm2, raid, mdadm, e encrypt NON sono abilitati di default. Si prega di leggere attentamente questa sezione per le istruzioni, se questi hooks sono richiesti.
Nota: Gli utenti con più controller hardware del disco che utilizzano i nomi dei nodi stessi, ma moduli del kernel diversi (ad esempio, due SCSI / SATA o due controller IDE) devono assicurarsi che il corretto ordine dei moduli sia specificato in /etc/mkinitcpio.conf. In caso contrario, la posizione della partizione root può variare negli avvii, con conseguente kernel panic. Un'alternativa più elegante è quella di utilizzare nomi di dispositivo non variabili persistent block device naming, per garantire che vengano sempre correttamente montati.

Gli utenti possono modificare cinque variabili all'interno del file di configurazione:

MODULES
Moduli del kernel da caricare prima che gli hooks vengono eseguiti all'avvio.
BINARIES
Binari supplementari da includere nell'immagine initramfs.
FILES
File aggiuntivi da inserire nell'immagine initramfs.
HOOKS
Gli hooks sono script che vengono eseguiti nel ramdisk iniziale.
COMPRESSION
Utilizzato per comprimere l'immagine initramfs.
COMPRESSION_OPTIONS
Opzioni da riga di comando da passare al programma COMPRESSION.

MODULES

La stringa MODULES è usata per specificare i moduli da caricare prima di mandare in esecuzione qualsiasi altra cosa. Per accelerare il processo d'avvio, si può optare di disabilitare l'hook udev ed elencare i moduli richiesti:

MODULES="piix ide_disk reiserfs"

[...]

HOOKS="base autodetect ide filesystems"

I moduli con suffisso '?' non restituiranno errori se non trovati. Questo può essere molto utile nel caso si stia compilando un kernel personalizzato che compili i moduli scritti esplicitamente negli HOOKS o nel file di configurazione.

Nota: Nel caso si utilizzi reiser4, questo deve essere aggiunto alla lista dei moduli. E se ci fosse bisogno di un qualsiasi filesystem durante il processo d'avvio, inesistente durante l'esecuzione di mkinitcpio, come nel caso di una chiave criptata LUKS su un filesystem ext2, ma senza nessun filesystem ext2 montato durante l'esecuzione di mkinitcpio, il modulo di quel filesystem deve essere aggiunto alla lista MODULES. Consultare qui per maggiori approfondimenti.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Mkinitcpio (Italiano)#)
Template:Box YELLOW

Moduli che non vengono caricati durante il processo d'avvio (stock kernel 2.6.18): scsi_transport_sas, ultrastor, qlogicfas, eata, BusLogic, pas16, wd7000, sym53c416, g_NCR5380_mmio, fdomain, u14-34f, dtc, initio, in2000, imm, t128, aha1542, aha152x, atp870u, g_NCR5380, NCR53c406a, qlogicfas408, megaraid_mm, advansys.

Se qualcuno dei moduli sopra è richiesto per il dispositivo di root, aggiungerlo specificatamente in /etc/mkinitcpio.conf per evitare eventuali kernel panic.

BINARIES e FILES

Queste opzioni consentono all'utente di aggiungere dei file all'immagine. Sia i BINARIES che iFILES vengono aggiunti prima che gli hook siano eseguiti, e possono essere usati per sovrascrivere i file usati o forniti dagli hook. I BINARIES vengono auto-localizzati in quanto devono essere salvati in un PATH standard e sono analizzatori di dipendenze, quindi ogni libreria e dipendenza richieste saranno aggiunte di conseguenza. I FILES saranno aggiunti come stanno. Per esempio:

FILES="/etc/modprobe.d/modprobe.conf"
BINARIES="kexec"


HOOKS

Hook è uno script che mette in esecuzione l'initial ramdisk. Gli hooks sono contenuti nella cartella /lib/initcpio/install; per una lista di hooks, dare il comando:

$ ls -1 /lib/initcpio/install

Usare l'opzione di mkinitcpio -H per ottenere maggiori informazioni riguardo qualche hook specifico. Ad esempio, per informazioni circa l'hook base:

$ mkinitcpio -H base

Gli hooks sono elencati in ordine di esecuzione, e vengono usati per aggiungere file o moduli all'immagine. Quindi gli hooks possono influire sull' installazione (quando mkinitcpio viene eseguito per generare l'immagine e/o durante il tempo di esecuzione) per mezzo di uno script annesso che viene avviato durante l'avvio. Gli script possono essere trovati nella cartella /lib/initcpio/hooks.

La configurazione predefinita funzionerà per la maggior parte degli utenti con le impostazioni standard:

HOOKS="base udev autodetect pata scsi sata filesystems"

Se si userà l'immagine su più sistemi con hardware diverso, rimuovere l'hook autodetect, dato che ottimizza l'immagine sulla macchina dove viene generato:

HOOKS="base udev pata scsi sata filesystems"

Per il supporto a volumi criptati su gruppi LVM2:

HOOKS="base udev autodetect pata scsi sata lvm2 encrypt filesystems"

Segue una tabella degli hooks più comuni e relative caratteristiche. Notare che questa tabella non è completa, poiché i pacchetti possono fornire hooks personalizzati.

Hooks più comuni
Hook Installazione Tempo di esecuzione
base Imposta tutte le cartelle d'avvio ed installa le utilità di base e le librerie. Aggiungere sempre questo hook a meno che non si sappia esattamente cosa si sta facendo. --
udev Aggiunge all'immagine udev, udevadm e le regole di udev. Udev sarà usato per creare il nodo del dispositivo di root e rilevare i moduli necessari per il dispositivo di root. Poiché semplifica le cose, usare udev è raccomandabile.
autodetect Riduce l'initramfs mediante autorilevamento dei moduli necessari. Verificare che i moduli inclusi siano tutti presenti e corretti. Questo hook deve essere avviato prima degli altri hook di sottosistema, per sfruttare completamente l'autorilevamento. Ogni hook specificato prima di "autodetect" sarà installato totalmente. --
pata Aggiunge i nuovi moduli IDE libata/PATA all'immagine. Usarlo se il dispositivo di root è su un disco IDE. Usare anche autodetect per eventualmente ridurre la dimensione dell'immagine. --
sata Aggiunge i moduli Serial ATA all'immagine. Usarlo se il dispositivo di root è su un disco SATA. Usare anche autodetect per eventualmente ridurre la dimensione dell'immagine. --
scsi Aggiunge i moduli SCSI all'immagine. Usarlo se il dispositivo di root è su un disco SCSI. Usare anche autodetect per eventualmente ridurre la dimensione dell'immagine. --
usb Aggiunge i moduli USB all'immagine. Usarlo se il dispositivo di root è su un dispositivo di archiviazione USB o se tale USB deve disporre di altri tipi di accesso (montato, controllato, ecc.) in fase di avvio. --
usbinput Aggiunge i moduli US HID all'immagine. Usarlo se si dispone di una tastiera USB e se ne ha bisogno durante la prima fase di userspace (sia per immettere passphrase criptate che per modalità sicura). --
fw Aggiunge i moduli FireWire all'immagine. Usarlo se il dispositivo di root è su un dispositivo di archiviazione FW. --
net Aggiunge i moduli necessari per dispositivi di rete. Per dispositivi PCMCIA aggiungere anche l'hook pcmcia. --Carica i moduli network. Ci sarà bisogno dell'hook udev a meno che si specifichino i moduli manualmente (vedere la sezione MODULES sotto). Vedere #Personalizzazione del runtime per supporto alla configurazione.
pcmcia Aggiunge i moduli necessari per i dispositivi PCMCIA. È necessario disporre anche di pcmciautils per avvalersene. --
dsdt Carica un file DSDT ACPI personalizzato in fase d'avvio. Aggiungere il file DSDT in /lib/initcpio/custom.dsdt Il file personalizzato DSDT è automaticamente usato dal kernel se è presente in initramfs.
filesystems Include i moduli di filesystem necessari nell'immArch supplies default configuration files inArch supplies default configuration files inagine. Questo hook è richiesto, a meno che non si specifichino i moduli di filesystem in MODULES. --
lvm2 Aggiunge il modulo device mapper kernel, e il tool lvm all'immagine. Sarà inoltre necessario avere installato il pacchetto lvm2. Abilita tutti i gruppi di voluni LVM2. È necessario se il filesystem di root è su LVM.
dmraid Provvede al supporto per fakeRAID del device root. È necessario aver installato dmraid per poter usare questo hooks Locates and assembles fakeRAID block devices using mdassemble.
mdadm Questo hook sostituisce l'hook raid. Supporta la disposizione del montaggio dal file /etc/mdadm.conf, o l'autorilevamento durante il boot. Carica i moduli necessari per il software per dispositivi raid, e monta i dispositivi raid quando eseguiti. Vedere #Personalizzazione del runtime per supporto alla configurazione.
madadm_udev Fornisce supporto per l'assemblaggio degli array tramite udev. È fondamentale avere mdadm installato.
encrypt Aggiunge il modulo del kernel dm-crypt e il cryptsetup tool all'immagine. Sarà inoltre necessario avere installato il pacchetto cryptsetup. Rileva e sblocca una partizione root criptata. Vedere #Personalizzazione del runtime per supporto alla configurazione.
resume -- Tenta di eseguire il ripristino (resume) dallo stato di "sospensione". Funziona in aggiunta a swsusp e suspend2. Consultare #Personalizzazione del runtime per supporto alla configurazione.
keymap Aggiunge keymap e consolefonts da rc.conf. Carica i keymap e consolefont specificati da rc.conf durante la prima fase di userspace.
fsck Aggiunge i binari di fsck e degli helpers per il filesystem specifico. Se aggiunto dopo l'hook autodetect verrà aggiunto solo l'helper per il filesystem di root. Usare questo hook è fortemente consigliato. Lancia fsck sul device "root" (e /usr se separata) prima del mount.
shutdown Aggiunge il supporto allo spegnimento a initramfs. Se si ha una /usr separata questo hook è fondamentale Copia initramfs su /run/initramfs per riusarlo allo spegnimento.

Creare un hook personalizzato

Un hook initcpio non è altro che uno script di shell contenente le informazioni necessarie a puntare mkinitcpio con gli eseguibili che devono essere caricati e le relative opzioni. Può essere utile in alcune rare occasioni in cui c'è bisogno di qualcosa nello userspace iniziale o finale, e non viene fornito da altri script già installati.

Innanzitutto creare lo script vero e proprio:

/lib/initcpio/install/hook
 #!/bin/bash
 
 build() {
     SCRIPT="hook" #the name of the hook
     add_binary /bin/bash  #/bin/bash is given as an example, you can type your desired executable here
 }
 
 help() {
     cat <<HELPEOF
     Line used as help information #Typing mkinitcpio -H hook will display this information
 HELPEOF
 }

Creare poi l'hook:

/lib/initcpio/hooks/hook
 run_hook ()
 {
     msg -n ":: This is an example hook"
     bash #your executable example
     msg "done."
 }
Note: Non è necessario e neanche consigliabile, rendere eseguibile alcuno di questi script.

Editare quindi /etc/mkinitcpio.conf al fine di includere il proprio hook. È anche possibile includerlo in /etc/rc.sysinit per caricarlo nello userspace finale. i

COMPRESSION

Il kernel supporta vari formati per la compressione dell'initramfs, gzip, bzip2, lzma, xz (o lzma2) e lzo. Nella maggior parte dei casi, gzip o lzop forniscono il miglior equilibrio tra dimensione dell'immagine compressa e velocità di decompressione.

COMPRESSION="gzip"
COMPRESSION="bzip2"     # richiede kernel 2.6.30
COMPRESSION="lzma"      # richiede kernel 2.6.30
COMPRESSION="lzop"      # richiede kernel 2.6.34
COMPRESSION="xz"        # richiede kernel 2.6.38

La mancata specifica del parametro COMPRESSION comporterà un file initramfs compresso in gzip. Per creare un'immagine non compressa, specificare COMPRESSION=cat nella configurazione o utilizzare -z cat dalla riga di comando.

OPZIONI DI COMPRESSIONE

Queste sono ulteriori flag che possono essere passate al programma specificato da COMPRESSION, come ad esempio:

COMPRESSION_OPTIONS='-9'

In generale questi non dovrebbero essere necessari, in quanto mkinitcpio farà in modo che qualsiasi metodo di compressione supporti le flag necessarie per produrre una immagine funzionante.

Personalizzazione del runtime

Le opzioni di configurazione del runtime possono essere inviate a init e ad alcuni hooks per mezzo della riga di comando del kernel. I parametri della riga di comando del kernel sono spesso forniti dal bootloader. Per esempio, una tipica voce GRUB Legacy di Arch Linux:

/boot/grub/menu.lst
...

# (0) Arch Linux
title  Arch Linux  [/boot/vmlinuz-linux]
root   (hd0,0)
kernel /vmlinuz-linux root=/dev/sda3 ro
initrd /initramfs-linux.img

...

In questo caso, root=/dev/sda3 e ro sono parametri della riga di comando del kernel. Le opzioni specificate sotto possono essere apportate alla linea di comando del kernel per alterare il comportamento predefinito. Consultare Arch Boot Process per ulteriori informazioni.

init

Nota: Le opzioni seguenti alterano il comportamento predefinito di init nell'ambiente initramfs. Vedere /lib/initcpio/init per maggiori informazioni.
root
Questo è il parametro più importante da specificare al kernel. Determina quale device deve essere montato come root. mkinitcpio è flessibile e permette diverse sintassi. Per esempio
root=/dev/sda1                                                # /dev node
root=LABEL=CorsairF80                                         # label
root=UUID=ea1c4959-406c-45d0-a144-912f4e86b207                # UUID
root=/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1    # udev symlink (richiede l'hook udev )
root=801                                                      # hex-encoded major/minor number
break
Se è specificato break=premount, init esegue una pausa iniziale nel processo d'avvio (dopo aver caricato i moduli ma prima di montare root) e lancia una shell interattiva che può essere usata per la risoluzione di eventuali problemi. Questa shell può essere lanciata dopo il mount di root specificando break=postmount. La fase di boot continua dopo il logout.
disablehooks
Disabilita gli hooks al runtime aggiungendo disablehooks=hook1{,hook2,...}. Per esempio:
disablehooks=resume
earlymodules
Altera l'ordine in cui moduli vengono caricati, specificando quali moduli devono essere caricati prima earlymodules=mod1{,mod2,...}. (Questo potrebbe essere usato, per esempio, per assicurare l'ordine corretto delle interfacce di rete multiple).
rootdelay
Fare una pausa di dieci secondi prima di montare il sistema root apponendo il rootdelay. (Questo potrebbe essere usato, per esempio, per l'avvio di un disco rigido USB che è lento in fase di avvio).

Usare RAID

Per prima cosa aggiungere l'hook mdadm alla lista HOOKS, e poi ogni altro modulo raid richiesto alla lista MODULES in /etc/mkinitcpio.conf.

Kernel Parameters: Usando l'hook mdadm, non sarà più necessario configurare la stringa RAID nei parametri GRUB Legacy. L'hook mdadm userà il file /etc/mdadm.conf, o automaticamente rileverà gli array durante la fase iniziale di boot.

Se si configura tale parametro via udev, è consigliabile usare l'hook mdadm_udev. Questo metodo è anche quello consigliato dallo sviluppo in upstream in quanto /etc/mdadm.conf sarà letto per nominare i devices connessi, se esistono.

Usare la rete

Pacchetti richiesti:

La rete richiede che il pacchetto mkinitcpio-nfs-utils sia installato dai repositories ufficiali.

Parametri del Kernel:

ip=

La specificazione di un'interfaccia può essere sia in formato corto, che è solo il nome di un'interfaccia ("eth0" o altro), che in formato allungato. Il formato allungato può essere costituito fino da sette elementi, separati da due punti:

 ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
 nfsaddrs= is an alias to ip= and can be used too.

Spiegazione dei parametri:

 <client-ip>   Indirizzo IP del client. Se vuoto, l'indirizzo sarà
               determinato da RARP/BOOTP/DHCP. Il tipo di protocollo 
               usato dipenderà dal parametro <autoconf>. Se questo
               parametro non è vuoto, sarà usato l'autoconf.
 
 <server-ip>   Indirizzo IP del server NFS. Se RARP è usato per 
               determinare l'indirizzo del client, e questo parametro 
               non è vuoto, saranno accettate solo risposte dal server
               specificato. Per usare differenti server RARP e NFS
               specificare il server RARP qui (o lasciare lo spazio vuoto), 
               e specificare il server NFS, in "nfsroot", il parametro
               (vedere sopra). Se questa voce è vuota verrà usato l'indirizzo 
               del server RARP/BOOTP che ha risposto alla richiesta DHCP.
 
 <gw-ip>       Indirizzo IP di un gateway se il server è su una sottorete 
               differente. Se vuoto, non verrà usato nessun gateway e il
               server sarà, presumibilmente, nella rete locale, a meno che 
               non venga ricevuto qualche valore attraverso BOOTP/DHCP.
 
 <netmask>     Netmask per l'interfaccia di rete locale. Se lasciato vuoto,
               il netmask è derivato dall'indirizzo IP del client che presume
               l'indirizzamento "classful", a meno che venga annullato nella 
               risposta di BOOTP/DHCP.
 
 <hostname>    Il nome del client. Se vuoto, l'indirizzo
               IP del client è usato nella notazione ASCII, oppure il 
               valore ricevuto da BOOTP/DHCP.
 
 <device>      Nome del dispositivo di rete da usare. Se vuoto, tutti i
               dispositivi sono usati per le richieste RARP/BOOTP/DHCP, e il
               primo a ricevere una risposta viene configurato. Se si usa
               un'unico dispositivo si può lasciare vuota questa voce.              
 
 <autoconf>    Metodo da usare per l'autoconfigurazione. Se include sia
               "rarp", "bootp", che "dhcp" il protocollo specificato verrà
               usato.  Se il valore è "both", "all" o vuoto, tutti i
               protocolli verranno usati. "off", "static" o "none" significa
               no autoconfigurazione.

Esempi:

 ip=127.0.0.1:::::lo:none  --> Permettere l'interfaccia loopback.
 ip=192.168.1.1:::::eth2:none --> Permettere l'interfaccia statica eth2.
 ip=:::::eth0:dhcp --> Permettere il protocollo dhcp per la configurazione eth0.

nfsroot=

Se il parametro "nfsroot" non viene dato dalla riga di comando, sarà usato il predefinito "/tftpboot/%s".

 nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

Spiegazione dei parametri:

 <server-ip>   Specifica l'indirizzo IP del server NFS. Se non specificato,
               l'indirizzo predefinito è determinato dall' "ip" variabile
               (vedere più sotto). Un'utilità di questo valore è per esempio
               la possibilità di usare differenti server per RARP e NFS.
               In generale si può lasciare in bianco.
 
 <root-dir>    Nome della cartella sul server, da montare come root. Se c'è
               un "%s" nella stringa, il simbolo sarà sostituito dalla
               rappresentazione ASCII dell'indirizzo ip del client.
               
 <nfs-options> Opzioni standard NFS. Tutte le opzioni sono separate da virgole.
               Se non viene fornita nessuna opzione, saranno usate le 
               seguenti opzioni predefinite:
                       port            = as given by server portmap daemon
                       rsize           = 1024
                       wsize           = 1024
                       timeo           = 7
                       retrans         = 3
                       acregmin        = 3
                       acregmax        = 60
                       acdirmin        = 30
                       acdirmax        = 60
                       flags           = hard, nointr, noposix, cto, ac

root=/dev/nfs

Se non si utilizzano parametri nfsroot= bisognerà configurare root=/dev/nfs per avviare un nfs da root per l'autoconfigurazione.

Usare lvm

Se il dispositivo di root è su lvm, bisognerà aggiungere l'hook lvm2, e passare il dispositivo di root sulla riga di comando del kernel nel formato

root=/dev/mapper/<volume group name>-<logical volume name>

per esempio

root=/dev/mapper/myvg-root

Usare root criptato

Se il volume di root è codificato, si deve aggiungere l'hook encrypt. Poi specificare il dispositivo di root sulla riga di comando del kernel, come se fosse non codificato.

Per una partizione criptata su un disco SATA o SCSI:

root=/dev/sda5

Per un volume LVM criptato:

root=/dev/mapper/myvg-root

Il dispositivo di root sarà automaticamente cambiato a /dev/mapper/root.

Usare volumi LUKS

Se si usa LUKS per la crittografia del disco rigido, lo script init rileverà la codifica automaticamente, qualora fosse abilitato l'hook encrypt. Verrà poi richiesta una password o passphrase per sbloccare il volume.

In caso di errori provare ad aggiungere il modulo del filesystem all'elenco dei moduli in /etc/mkinitcpio.conf se non compilato all'interno del kernel.

Usare un file chiave

Si può usare un "key-file" per codificare il filesystem di root. Usare il formato seguente:

cryptkey=device:fs-type:path

device è il file-device che rappresenta quale dispositivo è codificato dalla chiave (per esempio /dev/sda1), fs-type è il tipo di filesystem del dispositivo (per esempio ext3) e path è il percorso al keyfile all'interno del file system del dispositivo.

Usare volumi cryptsetup legacy

Nel caso di utilizzo di legacy cryptsetup volume, si devono specificare tutte le opzioni cryptsetup necessarie per sbloccare il volume dalla riga di comando. Il formato delle opzioni è:

crypto=hash:cipher:keysize:offset:skip

che equivalgono alle opzioni --hash, --cipher, --keysize, --offset, and --skip di cryptsetup. In caso di omissione di qualche opzione, verranno usati i valori predefiniti di cryptsetup, quindi si può anche specificare solo

crypto=::::

Se è stato creato il volume con le impostazioni predefinite.

Nota: Per ragioni tecniche, non è possibile verificare la correttezza della passphrase con volumi cryptsetup legacy. Se scritto erroneamente, il montaggio semplicemente non avverrà. È reccomandabile piuttosto, fare uso di LUKS.

Usare volumi loop-aes

mkinitcpio non supporta ancora loop-aes.

/usr su una partizione separata

Se durante l'installazione di Arch Linux si è scelto di montare /usr su una partizione separate, è necessario tenere conto di questo due cose:

  • Aggiungere l'hook shutdown. Allo spegnimento, initscript permetterà a /usr (e root) di essere adeguatamente smontata.
  • Aggiungere l'hook fsck. Raccomandato a tutti, fondamentale se si vuole un fsck al boot sulla partizione /usr. Senza questo hook, rc.sysinit farà partire fsck con /usr montata e di conseguenza fallirà.

Anche senza questi due HOOKS il sistema funzionerà correttamente (/usr montata e smontata correttamente) ma un setup del genere non è supportato.

Risoluzione dei problemi

Estrarre l'immagine

Se si è curiosi e si vuole scoprire cosa c'è dentro l'immagine initrd, la si può estrarre, per dare un'occhiata ai file all'interno.

L'immagine initrd è un archivio SVR4 CPIO, generato dai comandi find e bsdcpio e compressa con uno dei 3 formati di compressione compatibili con il kernel, chiamati gzip, bzip2, lzma, lzo o xz.

Mkinitcpio include uno strumento chiamato lsinitcpio che elenca ed estrae i contenuti dell'immagine initramfs.

Si possono elencare i file nell'immagine con:

$ lsinitcpio /boot/initramfs-linux.img

Ed estrarli nella cartella attuale:

$ lsinitcpio -x /boot/initramfs-linux.img

È anche possibile avere una lista più human-friendly delle più importanti parti dell'immagine:

$lsinitcpio -a /boot/initramfs-linux.imq

Riferimenti esterni

  • Documentazione del kernel Linux: initramfs
  • Documentazione del kernel Linux: initrd
  • Articolo Wikipedia: initrd