Difference between revisions of "Arch boot process (Italiano)"

From ArchWiki
Jump to: navigation, search
(tradotta l'introduzione)
(Prima di init)
Line 8: Line 8:
 
Questo articolo intende descrivere l'ordine cronologico del processo di avvio di Arch, ed i file che lo interessano, fornendo link a sezioni del wiki dove necessario. Arch come BSD utilizza init, contrariamente al più diffuso SysV. Ciò implica una lieve distinzione tra i runlevel, dato che il sistema di default usa i soliti moduli ed i soliti processi in tutti gli altri runlevel. Il vantaggio è che gli utenti potranno configurare semplicemente il processo di avvio(vedere [[rc.conf (Italiano)]]; lo svantaggio è che alcune configurazioni interessanti che offre SysV vanno perse. Consultare la guida su [[Adding Runlevels|come aggiungere runlevel]] in modo da utilizzare alcune opzioni di SysV in Arch. Consultare [[Wikipedia:init]] per approfondire maggiormente le distinzioni tra SysV ed il metodo BSD.
 
Questo articolo intende descrivere l'ordine cronologico del processo di avvio di Arch, ed i file che lo interessano, fornendo link a sezioni del wiki dove necessario. Arch come BSD utilizza init, contrariamente al più diffuso SysV. Ciò implica una lieve distinzione tra i runlevel, dato che il sistema di default usa i soliti moduli ed i soliti processi in tutti gli altri runlevel. Il vantaggio è che gli utenti potranno configurare semplicemente il processo di avvio(vedere [[rc.conf (Italiano)]]; lo svantaggio è che alcune configurazioni interessanti che offre SysV vanno perse. Consultare la guida su [[Adding Runlevels|come aggiungere runlevel]] in modo da utilizzare alcune opzioni di SysV in Arch. Consultare [[Wikipedia:init]] per approfondire maggiormente le distinzioni tra SysV ed il metodo BSD.
  
== Before init ==
+
== Prima di init ==
After the system is powered-on and the [[Wikipedia:Power-on self-test|POST]] is completed, the BIOS will locate the preferred boot medium and transfer control to the [[Master Boot Record]] of this device. On a GNU/Linux machine, often a bootloader such as [[GRUB]] or [[LILO]] is found and loaded from the MBR. The bootloader will present the user with a range of options for boot, e.g. Arch Linux and Windows on a [[Windows and Arch Dual Boot|dual-boot setup]]. Once Arch is selected, the kernel image in the {{Filename|/boot}} directory (currently {{Filename|kernel26.img}}) is decompressed and loaded into memory.
+
Dopo che la macchina viene accesa ed il [[Wikipedia:Power-on self-test|POST]] è stato completato, il BIOS identifica la periferica impostata per il boot e passa il controllo al settore di avvio([[Master Boot Record (Italiano)]]) della periferica. Su una macchina GNU/Linux, spesso viene installato sul MBR del disco un bootloader come [[GRUB (Italiano)]] o [[LILO (Italiano)]]. Il bootloader offre diverse opzioni di avvio ad esempio come Arch Linux e Windows [[Windows and Arch Dual Boot (italiano)|configurati in dual-boot.]] Una volta che viene selezionata Arch, l'immagine del kernel nella cartella {{Filename|/boot}}(attualmente il nome del file è {{Filename|kernel26.img}}) viene decompressa e caricata in memoria.
  
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine, and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion (to human perception) of many tasks being executed simultaneously.  
+
Il kernel è il cuore di un sistema operativo. Esso lavora a basso livello (''kernelspace'') interagendo tra le periferiche della macchina, ed i programmi che ne richiedono le risorse per funzionare. Per sfruttare la CPU in modo efficiente, il kernel usa un sistema di pianificaizone per decidere a quale processo assegnare la priorità e quando, creando così l'illusione(per l'occhio umano) che i processi vengano eseguiti contemporaneamente.
  
After the kernel is loaded, it reads from the [[initramfs]] (initial RAM filesystem). The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, or SATA drives (or USB/FW, if booting off a USB/FW drive) must be loaded. Once the initramfs loads the proper modules, either manually or through [[udev]], it passes control to the kernel and the boot process continues. For this reason, the initrd only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.  
+
Dopo che il kernel è stato caricato, viene letto l'[[initramfs]](initial RAM filesystem). L'obbiettivo di initramfs è di effettuare il bootstrap del sistema dalla periferica in cui si trova il filesystem di root(vedi [[FHS (Italiano)]] per maggiori informazioni). Ciò significa che ogni modulo richiesto dalle periferiche come dischi IDE, SCSI, o SATA (oppure USB/FireWire, se si effettua il boot da una di queste periferiche) deve essere caricato. Una volta che initramfs carica i moduli necessari, sia manualmente che tramite [[udev (Italiano)]], il controllo passa di nuovo al kernel ed il processo di avvio continua. Per questa ragione l'initrd può contenere solo i moduli strettamente necessari per l'accesso al filesystem di root(/); non è quindi necessario che contenga tutti i moduli che servono al completo funzionamento della macchina. La maggior parte dei moduli sarà caricata in seguito da udev, durante la fase di init.
  
The kernel then looks for the program {{Codeline|init}} which resides at {{Filename|/sbin/init}}. {{Codeline|init}} relies on {{Codeline|glibc}}, the GNU C library. Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of {{Filename|*.so}}. They are essential for basic system functionality. This part of the boot process is called ''early userspace''.
+
Il kernel successivamente richiama il programma {{Codeline|init}} che si trova in {{Filename|/sbin/init}}. {{Codeline|init}} fa riferimento a {{Codeline|glibc}}, la libreria standard del C del progetto GNU. Le librerie sono un insieme di programmi e routine utilizzate frequentemente e sono facilmente identificabili dalla loro esetensione {{Filename|*.so}}. Sono essenziali per il funzionamento base del sistema. Questa fase del processo di avvio è definita ''early userspace''.
  
 
== init: The Arch boot scripts ==
 
== init: The Arch boot scripts ==

Revision as of 00:00, 4 May 2010

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Arch boot process (Italiano)#)
Note: Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.

Questo articolo intende descrivere l'ordine cronologico del processo di avvio di Arch, ed i file che lo interessano, fornendo link a sezioni del wiki dove necessario. Arch come BSD utilizza init, contrariamente al più diffuso SysV. Ciò implica una lieve distinzione tra i runlevel, dato che il sistema di default usa i soliti moduli ed i soliti processi in tutti gli altri runlevel. Il vantaggio è che gli utenti potranno configurare semplicemente il processo di avvio(vedere rc.conf (Italiano); lo svantaggio è che alcune configurazioni interessanti che offre SysV vanno perse. Consultare la guida su come aggiungere runlevel in modo da utilizzare alcune opzioni di SysV in Arch. Consultare Wikipedia:init per approfondire maggiormente le distinzioni tra SysV ed il metodo BSD.

Prima di init

Dopo che la macchina viene accesa ed il POST è stato completato, il BIOS identifica la periferica impostata per il boot e passa il controllo al settore di avvio(Master Boot Record (Italiano)) della periferica. Su una macchina GNU/Linux, spesso viene installato sul MBR del disco un bootloader come GRUB (Italiano) o LILO (Italiano). Il bootloader offre diverse opzioni di avvio ad esempio come Arch Linux e Windows configurati in dual-boot. Una volta che viene selezionata Arch, l'immagine del kernel nella cartella Template:Filename(attualmente il nome del file è Template:Filename) viene decompressa e caricata in memoria.

Il kernel è il cuore di un sistema operativo. Esso lavora a basso livello (kernelspace) interagendo tra le periferiche della macchina, ed i programmi che ne richiedono le risorse per funzionare. Per sfruttare la CPU in modo efficiente, il kernel usa un sistema di pianificaizone per decidere a quale processo assegnare la priorità e quando, creando così l'illusione(per l'occhio umano) che i processi vengano eseguiti contemporaneamente.

Dopo che il kernel è stato caricato, viene letto l'initramfs(initial RAM filesystem). L'obbiettivo di initramfs è di effettuare il bootstrap del sistema dalla periferica in cui si trova il filesystem di root(vedi FHS (Italiano) per maggiori informazioni). Ciò significa che ogni modulo richiesto dalle periferiche come dischi IDE, SCSI, o SATA (oppure USB/FireWire, se si effettua il boot da una di queste periferiche) deve essere caricato. Una volta che initramfs carica i moduli necessari, sia manualmente che tramite udev (Italiano), il controllo passa di nuovo al kernel ed il processo di avvio continua. Per questa ragione l'initrd può contenere solo i moduli strettamente necessari per l'accesso al filesystem di root(/); non è quindi necessario che contenga tutti i moduli che servono al completo funzionamento della macchina. La maggior parte dei moduli sarà caricata in seguito da udev, durante la fase di init.

Il kernel successivamente richiama il programma Template:Codeline che si trova in Template:Filename. Template:Codeline fa riferimento a Template:Codeline, la libreria standard del C del progetto GNU. Le librerie sono un insieme di programmi e routine utilizzate frequentemente e sono facilmente identificabili dalla loro esetensione Template:Filename. Sono essenziali per il funzionamento base del sistema. Questa fase del processo di avvio è definita early userspace.

init: The Arch boot scripts

The main Arch startup process is initiated by the program Template:Codeline, which spawns all other processes. The purpose of Template:Codeline is to bring the system into a usable state, using the boot scripts to do so. As previously mentioned, Arch uses BSD-style boot scripts. Template:Codeline reads the file Template:Filename; the default Template:Filename begins with the following:

Template:File

The first uncommented line defines the default system runlevel (3). When the kernel calls init:

Template:Filename

Template:Filename is a huge startup script that basically takes care of all hardware configuration plus a number of general initialization tasks. It can be identified by its first task, printing the lines:

Arch Linux
http://www.archlinux.org
Copyright 2002-2007 Judd Vinet
Copyright 2007-2009 Aaron Griffin
Distributed under the GNU General Public License (GPL)

A rough overview of its tasks:

  • Sources the Template:Filename script
  • Sources the Template:Filename script
  • Displays a welcome message
  • Mounts various virtual file systems
  • Creates dummy device files
  • Starts minilogd
  • Outputs messages from dmesg
  • Configures the hardware clock
  • Empties the Template:Filename file
  • Starts udev and checks for udev events
  • Starts the loopback interface
  • Loads modules from the Template:Codeline array defined in rc.conf
  • Configures RAID and encrypted filesystem mappings
  • Runs a forced check of partitions (fsck) if the /etc/fstab file contains instructions to do so
  • Mounts local partitions and swap (networked drives are not mounted before a network profile is up)
  • Activates swap areas
  • Sets the hostname, locale and system clock as defined in Template:Filename
  • Removes various leftover/temporary files, such as Template:Filename
  • Configures the locale, console and keyboard mappings
  • Sets the console font
  • Writes output from dmesg to Template:Filename

Template:Filename is a script and not a place for settings. It sources (i.e. reads and inherits variables and functions) rc.conf for settings and Template:Filename for the functions that produce its graphical output (nice colors, alignments, switching 'busy' to 'done', etc.) There is no particular need to edit this file, although some may wish to do so in order to speed up the boot process.

Template:Filename

Single-user mode will boot straight into the root user account and should only be used if one cannot boot normally. This script ensures no daemons are running except for the bare minimum: syslog-ng and udev. The single-user mode is useful for system recovery where preventing remote users from doing anything that might cause data loss or damage is necessary. In single-user mode, users can continue with the standard (multi-user) boot by entering 'exit' at the prompt.

Template:Filename

Template:Filename is run on any multi-user runlevel (i.e. 2, 3. 4 and 5) which basically means any ordinary boot. Typically, users will not notice the transition from Template:Filename to Template:Filename as Template:Filename also uses the functions file to produce output. This script has three tasks:

Template:Filename

Template:Filename is the local multi-user startup script. Empty by default, it is a good place to put any last-minute commands the system should run at the very end of the boot process. Most common system configuration tasks (like loading modules, changing the console font, or setting up devices) usually have a dedicated place where they belong. To avoid confusion, ensure that whatever one intends to add to Template:Filename is not already residing in Template:Filename, or any other existing configuration location instead.

When editing this file, keep in mind that it is run after the basic setup (modules/daemons), as the root user, and whether or not X starts. Here is an example which just un-mutes the ALSA sound settings:

Template:File

Another common usage for Template:Filename is to apply various hacks when one cannot make the ordinary initialization work correctly.

init: Login

By default, after the Arch boot scripts are completed, the Template:Codeline program prompts users for a login name. After a login name is received, Template:Codeline calls Template:Codeline to prompt for the login password.

Finally, with a successful login, the Template:Codeline program starts the user's default shell. The default shell and environment variables may be globally defined within Template:Filename. All variables within a users home directory shall take precedence over those globally defined under Template:Filename. For instance, if two conflicting variables are specified within Template:Filename and Template:Filename, the one dictated by Template:Filename shall prevail.

Other options include mingetty which allows for auto-login and rungetty which allows for auto-login and automatically running commands and programs, e.g. the always useful htop.

The majority of users wishing to start an X server during the boot process will want to install a display manager, and see Display Manager for details. Alternatively, Start X at Boot outlines methods that do not involve a display manager.

Risorse