Gentoo Logo

[ << ] [ < ] [ Home ] [ > ] [ >> ]


10. Configurazione del Bootloader

Indice:

10.a. Macchine Silicon Graphics: Impostare arcload

Quale installare?

Su sistemi SGI, si usa il bootloader arcload. Nelle precedenti versioni, si poteva usare anche arcboot, ma è stato dichiarato obsoleto.

Nota: I filename dell'intestazione del volume per SGI sono limitati a 8 caratteri, e non ci possono essere più di 16 file contenuti in una intestazione di volume.

Installare arcload

arcload è stato scritto per sistemi che richiedono kernel 64 bit, e che quindi non possono usare arcboot (il quale non può facilmente essere compilato come un binario 64 bit). Ha anche delle peculiarità che si notano quando si caricano kernel dalla intestazione del volume. Si procede con l'installazione:

Codice 1.1: Emergere arcload e dvhtool

# emerge arcload dvhtool

Si dovrebbe trovare il binario arcload in /usr/lib/arcload. Ci sono due file:

  • sashARCS: Il binario 32 bit per sistemi Indy, Indigo2 (R4k), Challenge S e O2
  • sash64: Il binario 64 bit per sistemi Octane/Octane2, Origin 200/2000 e Indigo2 Impact

Usare dvhtool per installare il binario appropriato al proprio sistema nell'intestazione del volume:

Codice 1.2: Mettere arcload nell'intestazione del volume

(Utenti Indy/Indigo2/Challenge S/O2)
# dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS

(Utenti Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000)
# dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64

Nota: Non si deve usare il nome sashARCS o sash64 a meno che si stia installando nell'intestazione del volume di un CD avviabile. Per boot normali dall'hard disk si può nominarli in qualunque altro modo.

Usare dvhtool per verificare che siano nell'intestazione del volume.

Codice 1.3: Controllare che arcload sia presente nell'intestazione del volume

# dvhtool --print-volume-directory
----- directory entries -----
Entry #0, name "sash64", start 4, bytes 55859
#

Il file arc.cf ha una sintassi simile a C. Per dettagli su come configurarlo, vedere la pagina arcload su Linux/MIPS wiki. In breve, si definisce un numero di opzioni, le quali si abilitano e disabilitano al boot con la variabile OSLoadFilename.

Codice 1.4: Un esempio di arc.cf

# Configurazione ARCLoad

# Alcune impostazioni predefinite...
append  "root=/dev/sda3";
append  "ro";
append  "console=ttyS0,9600";

# Definizione principale.  ip28 può essere cambiato se lo si desidera.
ip28 {
        # Definizione per un kernel funzionante
        # Selezionare questo impostando OSLoadFilename="ip28(working)"
        working {
                description     "SGI Indigo2 Impact R10000\n\r";
                image system    "/working";
        }

        # Definizione per un kernel nuovo
        # Selezionare questo impostando OSLoadFilename="ip28(new)"
        new {
                description     "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
                image system    "/new";
        }

        # Per un kernel di debug
        # Selezionare questo impostando OSLoadFilename="ip28(working,debug)"
        # o OSLoadFilename="ip28(new,debug)"
        debug {
                description     "Debug console";
                append          "init=/bin/bash";
        }
}

A partire da arcload-0.5, arc.cf ed i kernel possono risiedere le''header del volume o in una partizione. Se si desidera sfruttare questa nuova possibilità si può spostare i propri file nella partizione /boot (o / se non si possiede una partizione di boot separata). arcload utilizza il codice del filesystem del famoso bootloader grub e dunque ne supporta gli stessi filesystem.

Codice 1.5: Mettere arc.cf e kernel nell'intestazione del volume

# dvhtool --unix-to-vh arc.cf arc.cf
# dvhtool --unix-to-vh /usr/src/linux/vmlinux new

Quello che manca è impostare alcune opzioni nel PROM. Vedere la sezione Riavviare il sistema.

10.b. Cobalt MicroServer: Impostare CoLo

Installare CoLo

Sui server Cobalt, queste macchine hanno firmware meno capace installato sul chip. Il Cobalt BOOTROM è primitivo rispetto al SGI PROM, ed ha alcuni limiti.

  • C'è un limite (approssimato) di 675kB sui kernel. Con l'attuale dimensione del 2.4, è impossibile fare un kernel di questa grandezza. Il 2.6 non è proprio possibile considerarlo.
  • I kernel 64-bit non sono supportati dal firmware di riserva (sebbene questi siano sperimentali sulle macchine Cobalt)
  • La shell è di base nella maggior parte dei casi

Per superare questi limiti, è stato sviluppato un firmware alternativo, CoLo (Cobalt Loader). E' una immagine BOOTROM che può essere sia inserita nel chip del server Cobalt, sia essere caricata dal firmware esistente.

Nota: In questo manuale si seguirà l'impostazione di CoLo in modo che sia caricato dal firmware di riserva. Questo è l'unico modo per avere una impostazione sicura e raccomandata.

Avvertenza: Si può inserirlo nel server, e rimettere il firmware originale (lo si fa a proprio rischio). Se qualcosa dovesse andare storto, si dovrà rimuovere il BOOTROM e riprogrammare con il firmware di riserva. Se non si sa cosa si sta facendo, NON si deve esporre la macchina a potenziali guasti. Gli autori di questo Manuale non si assumono nessuna responsibilità se questo consiglio viene ignorato.

Si inizia con emergere il pacchetto.

Codice 2.1: Emergere colo

# emerge colo

Si dovrebbe avere la directory /usr/lib/colo e in essa si dovrebbero trovare due file, colo-chain.elf il kernel per il firmware di riserva da caricare, e colo-rom-image.bin una immagine ROM che si inserisce nel BOOTROM. Iniziare montando /boot e mettendo una copia compressa di colo-chain.elf in /boot dove il sistema si aspetta di trovarla.

Codice 2.2: Mettere CoLo al suo posto

# gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz

Configurare CoLo

Quando il sistema si avvia per la prima volta, caricherà CoLo con un menu diviso in sezioni. La prima opzione (predefinita dopo 5 secondi) è il boot del disco. Il sistema tenta di montare la prima partizione Linux che trova, ed esegue lo script default.colo. La sintassi è ben documentata nella documentazione di CoLo (leggere /usr/share/doc/colo-X.YY/README.shell.gz, dove X.YY è la versione installata), ed è molto semplice.

Nota: Solo un consiglio: quando si installano i kernel, è meglio creare due immagini dei kernel, kernel.gz.working (un kernel funzionante), e kernel.gz.new (un kernel appena compilato). Si possono usare i collegamenti simbolici per puntare ai kernel "new" e "working", o rinominare le immagini dei kernel.

Codice 2.3: default.colo di base

#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/sda3 ro console=ttyS0,115200

Nota: CoLo rifiuterà di caricare uno script che non inizia con la riga #:CoLo:#. E' come se fosse l'equivalente di #!/bin/sh negli script di shell.

E' anche possibile chiedere quale kernel & configurazione si preferisce bootare, con timeout predefinito. Questa configurazione fa questo, chiedere all'utente quale kernel desidera usare, e eseguire l'immagine scelta. vmlinux.gz.new e vmlinux.gz.working possono essere le immagini del kernel o symlink che puntano alle immagini del kernel su questo disco. Il 50 di select specifica che dovrebbe procedere con la prima opzione ("Working") dopo 50/10 secondi.

Codice 2.4: Configurazione basata sul menu

#:CoLo:#

lcd "Mounting hda1"
mount hda1
select "Which Kernel?" 50 Working New

goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new

@lcd "Loading Linux" {image-name}
load /{image-name}
lcd "Booting..."
execute root=/dev/sda5 ro console=ttyS0,115200
boot

Vedere la documentazione in /usr/share/doc/colo-VERSION per maggiori informazioni.

10.c. Impostare una console seriale

Si assume che si sia loggati in un terminale. Sulle macchine Cobalt non è una cosa da fare.

Nota: Chi ha un framebuffer supportato può saltare questa sezione.

Aprire con un editor /etc/inittab. Si trova qualcosa come questo:

Codice 3.1: Configurazione inittab

# CONSOLE SERIALE
#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102

# TERMINALS
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now

Non commentare la riga c0. In modo predefinito è impostata per usare un baud rate terminale di 9600 bps. Sui server Cobalt, si potrebbe cambiarlo a 115200 per combinare il baud rate deciso dal BOOT ROM. Sui server Cobalt, si raccomanda di commentare le righe locali del terminale (da c1 a c6) poichè non funzinano bene quando non possono aprire /dev/ttyX.

Codice 3.2: Esempio da inittab

# CONSOLE SERIALE
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102

# TERMINALI -- Sono inutili in un qube senza monitor
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Si deve dire al sistema che la porta locale seriale può essere considerata come un terminale sicuro. Il file che si deve modificare è /etc/securetty. Contiene un elenco di terminali sicuri per il sistema. Si aggiungono due righe, e permette che la riga seriale sia usata per i login da root.

Codice 3.3: Abilitare i login da root sulla console seriale

(/dev/ttyS0 -- il nome per la prima porta seriale)
# echo 'ttyS0' >> /etc/securetty

(Linux la chiama anche /dev/tts/0 -- si aggiunge anche questo)
# echo 'tts/0' >> /etc/securetty

10.d. Riavviare il sistema

Uscire dall'ambiente in cui si è fatto il chroot e smontare tutte le partizioni montate. Poi digitare il comando reboot.

Codice 4.1: Uscire dal chroot, smontare tutte le partizioni e riavviare

# exit
cdimage ~# cd
cdimage ~# umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~# umount -l /mnt/gentoo{/boot,/proc,}
cdimage ~# reboot

Nota: Utenti Cobalt: Il resto di questo capitolo copre il setup per SGI PROM in modo che avvii arcload e carichi Linux. Non è applicabile al setup per server Cobalt. Tutto quello che era necessario fare, è stato fatto: non c'è nessuna configurazione per il primo avvio, si può passare alla sezione Termine dell'installazione Gentoo.

10.e. Ottimizzare il SGI PROM

Impostazioni generiche PROM

Il bootloader è installato, si è pronti per riavviare il sistema.

Codice 5.1: Riavviare

(Uscire dall'ambiente in cui si è fatto il chroot)
# exit

(Fare unmount dei dischi)
cdimage ~# umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~# umount -l /mnt/gentoo{/boot,/proc,}

(Riavviare)
# reboot

Dopo aver riavviato, andare nel System Maintenance Menu e selezionare Enter Command Monitor (5) come quando si è fatto il netboot al sistema.

Codice 5.2: Configurare il PROM per avviare Gentoo

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor.  Type "exit" to return to the menu.

(Impostare alcune opzioni per arcload)

(Fornire la locazione dell'intestazione del volume)
>> setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)

(Avviare automaticamente Gentoo)
>> setenv AutoLoad Yes

(Impostare la timezone)
>> setenv TimeZone EST5EDT

(Usare la console seriale - utenti con adattatori grafici dovrebbero avere "g" invece di "d1" (uno))
>> setenv console d1

(Impostare il baud rate della console seriale. Questo è opzionale,) (9600 è l'impostazione predefinita, si può usare anche 38400.)
>> setenv dbaud 9600

Le prossime impostazioni dipendono da come si sta avviando il sistema.

Impostazioni per l'avvio diretto nell'intestazione del volume

Si fa cenno a questo per completezza. E' raccomandato agli utenti di installare arcload.

Nota: Funziona solo su Indy, Indigo2 (R4k) e Challenge S.

Codice 5.3: Impostazioni PROM per avviare nell'intestazione del volume

(<root device> = partizione di root di Gentoo, per esempio /dev/sda3)
>> setenv OSLoadPartition <root device>

(Per elencare i kernel disponibili, digitare "ls")
>> setenv OSLoader <kernel name>
>> setenv OSLoadFilename <kernel name>

(Dichiarare i parametri del kernel che si desiderano usare)
>> setenv OSLoadOptions <kernel parameters>

Se si desidera provare un kernel senza fare confusione con i parametri del kernel, si può usare il comando PROM boot -f:

Codice 5.4: Avviare senza cambiare le variabili di ambiente

(Avviare un kernel, nuovo, con altre opzioni)
# boot -f new root=/dev/sda3 ro

Impostazioni per arcload

arcload usa l'opzione OSLoadFilename per specificare quale opzione è da impostare da arc.cf. Il file di configurazione è essenzialmente uno script, con i blocchi iniziali che definiscono le immagini di boot per sistemi differenti, e dentro, le impostazioni opzionali. Così OSLoadFilename=mysys(serial) si applica nelle impostazioni per il blocco mysys, poi imposta varie opzioni escluse in serial.

Nel file di esempio già visto, si ha un blocco di sistema definito, ip28 con le opzioni disponibili working, new e debug. Si definiscono le variabili di PROM così:

Codice 5.5: Impostazioni di PROM usando arcload

(Selezionare arcload come bootloader:- sash64 o sashARCS)
>> setenv OSLoader sash64

(Usare l'immagine del kernel "working", definita nella sezione "ip28" di arc.cf)
>> setenv OSLoadFilename ip28(working)

A partire da arcload-0.5, i file non devono più per forza essere messi nell'header del volume ma possono essere posti invece in una partizione. Per comunicare ad arcload dove cercare i propri file di configurazione ed i vari kernel, è necessario impostare la variabile PROM OSLoadPartition. Il valore esatto dipende dalla posizione del proprio disco sul bus SCSI. Utilizzare la variabile PROM SystemPartition come esempio, dovrebbe essere sufficiente cambiare solo i numeri delle partizoni.

Nota: Le partizioni vengono numerate a partire da 0, non 1 come per Linux.

Codice 5.6: Comunicare ad arcload dove cercare arc.cf

(Se si desidera caricare dall'header del volume specificare la partizione 8)
>> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)

(Altrimenti specificare la partizione ed il tipo di filesystem)
>> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]

Tutto completato

Ora si ha installato un sistema Gentoo. Avviare in Gentoo, e finire con Termine dell'installazione Gentoo.


[ << ] [ < ] [ Home ] [ > ] [ >> ]


Stampa

Visualizza tutto

Aggiornato il 15 gennaio 2012

La versione originale di questo documento è più recente ed è stata aggiornata il 12 aprile 2014

Oggetto: Su entrambe le macchine Silicon Graphics, e sui server Cobalt, viene richiesto l'uso di un bootloader per caricare il kernel. Questa sezione spiega come mettere a punto arcboot/arcload (per le macchine SGI) e colo per i server Cobalt.

Sven Vermeulen
Autore

Grant Goodyear
Autore

Grant Goodyear
Autore

Roy Marples
Autore

Daniel Robbins
Autore

Chris Houser
Autore

Jerry Alexandratos
Autore

Seemant Kulleen
Sviluppo x86

Tavis Ormandy
Sviluppo Alpha

Jason Huebel
Sviluppo AMD64

Guy Martin
Sviluppo HPPA

Pieter Van den Abeele
Sviluppo PPC

Joe Kallar
Sviluppo SPARC

John P. Davis
Redazione

Pierre-Henri Jondot
Redazione

Eric Stockbridge
Redazione

Rajiv Manglani
Redazione

Jungmin Seo
Redazione

Stoyan Zhekov
Redazione

Jared Hudson
Redazione

Colin Morey
Redazione

Jorge Paulo
Redazione

Carl Anderson
Redazione

Jon Portnoy
Redazione

Zack Gilburd
Redazione

Jack Morgan
Redazione

Benny Chuang
Redazione

Erwin
Redazione

Joshua Kinard
Redazione

Stuart Longland
Redazione

Tobias Scherbaum
Redazione

Xavier Neys
Redazione

Joshua Saddler
Redazione

Gerald J. Normandin Jr.
Revisione

Donnie Berkholz
Revisione

Ken Nowack
Revisione

Lars Weiler
Contributi

Marco Mascherpa
Traduzione

Stefano Pacella
Traduzione

Enrico Morelli
Traduzione

Davide Cendron
Traduzione

Sergio Vaccaro
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.