.\" -*- coding: UTF-8 -*-
.\" This man-page is Copyright (C) 1997 John S. Kallal
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" If the you wish to distribute versions of this work under other
.\" conditions than the above, please contact the author(s) at the following
.\" for permission:
.\"
.\"  John S. Kallal -
.\"	email: <kallal@voicenet.com>
.\"	mail: 518 Kerfoot Farm RD, Wilmington, DE 19803-2444, USA
.\"	phone: (302)654-5478
.\"
.\" $Id: initrd.4,v 0.9 1997/11/07 05:05:32 kallal Exp kallal $
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH initrd 4 "5 lutego 2023 r." "Linux man\-pages 6.03" 
.SH NAZWA
initrd \- dysk RAM inicjowany przez program rozruchowy
.SH KONFIGURACJA
\fI/dev/initrd\fP jest urządzeniem blokowym tylko do odczytu, z przypisanym
numerem głównym 1 i numerem pobocznym 250. Zwykle \fI/dev/initrd\fP jest
własnością root:disk z trybem 0400 (dostęp do odczytu tylko przez
roota). Jeśli system Linux nie posiada utworzonego \fI/dev/initrd\fP, można to
uczynić następującymi poleceniami:
.PP
.in +4n
.EX
mknod \-m 400 /dev/initrd b 1 250
chown root:disk /dev/initrd
.EE
.in
.PP
.\"
.\"
.\"
Aby korzystać z \fI/dev/initrd\fP, konieczne jest wkompilowanie bezpośrednio w
jądro Linux obsługi \[Bq]RAM disk\[rq] oraz \[Bq]Initial RAM disk\[rq]
(tj. \fBCONFIG_BLK_DEV_RAM=y\fP i \fBCONFIG_BLK_DEV_INITRD=y\fP). Gdy korzysta się
z \fI/dev/initrd\fP, sterownik dysku RAM nie może być załadowany jako moduł.
.SH OPIS
Specjalny plik \fI/dev/initrd\fP jest urządzeniem blokowym tylko do
odczytu. Urządzenie jest dyskiem RAM, które jest inicjowane (np. ładowane)
przez program rozruchowy przed uruchomieniem jądra. Jądro może następnie
użyć zawartości \fI/dev/initrd\fP, w trakcie uruchamiania systemu, składającego
się z dwóch faz.
.PP
.\"
.\"
.\"
W pierwszej fazie rozruchu, jądro uruchamia i montuje pierwotny główny
system plików z zawartości \fI/dev/initrd\fP (np. dysku RAM zainicjowanego
przez program rozruchowy). W drugiej fazie dodatkowe sterowniki i inne
moduły są ładowane z zawartości urządzenia pierwotnego urządzenia
głównego. Po załadowaniu dodatkowych modułów, montowany jest nowy główny
system plików (tj. zwykły korzeń systemu plików) z innego urządzenia.
.SS "Działania rozruchowe"
Jeśli rozruch następuje z użyciem \fBinitrd\fP, wygląda to następująco:
.IP (1) 5
Program rozruchowy ładuje do pamięci program jądra i zawartość
\fI/dev/initrd\fP.
.IP (2)
Przy uruchomieniu jądra, jądro rozpakowuje i kopiuje zawartość urządzenia
\fI/dev/initrd\fP do urządzenia \fI/dev/ram0\fP, a następnie zwalnia pamięć użytą
przez \fI/dev/initrd\fP.
.IP (3)
Jądro montuje następnie do odczytu i zapisu urządzenie \fI/dev/ram0\fP jako
pierwotny główny system plików.
.IP (4)
Jeśli wskazany zwykły korzeń systemu plików jest również pierwotnym głównym
systemem plików (np. \fI/dev/ram0\fP) to jądro pomija ostatni krok zwykłej
sekwencji rozruchowej.
.IP (5)
Jeśli w pierwotnym głównym systemie plików obecny jest plik wykonywalny
\fI/linuxrc\fP, to \fI/linuxrc\fP jest wykonywany z identyfikatorem użytkownika
równym 0 (plik \fI/linuxrc\fP musi mieć ustawione uprawnienie do wykonania;
plik \fI/linuxrc\fP może być dowolnym prawidłowym plikiem wykonywalnym, w tym
skryptem powłoki).
.IP (6)
Jeśli \fI/linuxrc\fP nie jest wykonywany lub gdy \fI/linuxrc\fP się zakończy,
montowany jest zwykły korzeń systemu plików (jeśli \fI/linuxrc\fP wyjdzie z
jakimkolwiek systemem plików zamontowanym w pierwotnym głównym systemie
plików, to zachowanie jądra jest \fBNIEZDEFINIOWANE\fP; zob rozdział UWAGI, aby
zapoznać się z bieżącym zachowaniem jądra).
.IP (7)
Jeśli zwykły korzeń systemu plików posiada katalog \fI/initrd\fP, to urządzenie
\fI/dev/ram0\fP jest przemieszczane z \fI/\fP do \fI/initrd\fP. W innym przypadku,
jeśli katalog \fI/initrd\fP nie istnieje, urządzenie \fI/dev/ram0\fP jest
odmontowywane (przy przemieszczaniu z \fI/\fP do \fI/initrd\fP, \fI/dev/ram0\fP nie
jest odmontowywane, zatem mogą pozostać procesy działające z \fI/dev/ram0\fP;
jeśli katalog \fI/initrd\fP nie istnieje na zwykłym korzeniu systemu plików i
pozostaną jakieś procesy działające z \fI/dev/ram0\fP, gdy \fI/linuxrc\fP wyjdzie,
zachowanie jądra jest \fBNIEZDEFINIOWANE\fP; zob rozdział UWAGI, aby zapoznać
się z bieżącym zachowaniem jądra).
.IP (8)
.\"
.\"
.\"
Na zwykłym korzeniu systemu plików dokonywana jest zwykła sekwencja
rozruchowa (np. wywołanie \fI/sbin/init\fP).
.SS Opcje
Gdy korzysta się z \fBinitrd\fP, wpływ na działanie w trakcie uruchomienia
jądra, mają następujące opcje z programu rozruchowego:
.TP 
\fBinitrd=\fP\fInazwa\-pliku\fP
Określa plik, z którego załadowana zostanie zawartość \fI/dev/initrd\fP. W
przypadku \fBLOADLIN\fP jest to opcja wiersza poleceń. W \fBLILO\fP konieczne jest
użycie tego polecenia w pliku konfiguracyjnym \fBLILO\fP
\fI/etc/lilo.config\fP. Nazwa pliku podana w tej opcji będzie zwykle
skompresowanym za pomocą gzip obrazem systemu plików.
.TP 
\fBnoinitrd\fP
Opcja rozruchowa wyłącza rozruch składający się z dwóch faz. Jądro wykonuje
zwykłą sekwencję rozruchową, jak gdyby \fI/dev/initrd\fP nie był
zainicjowany. Dzięki tej opcji, zawartość \fI/dev/initrd\fP załadowana do
pamięci przez program rozruchowy jest zachowywana. Opcja pozwala, aby
zawartością \fI/dev/initrd\fP były dowolne dane, niekonieczne obraz systemu
plików. Jednak urządzenie \fI/dev/initrd\fP jest tylko do odczytu i może być
odczytane jedynie jednokrotnie po uruchomieniu systemu.
.TP 
\fBroot=\fP\fInazwa\-urządzenia\fP
.\"
.\"
.\"
Określa urządzenie, które będzie służyło jako zwykły główny system plików. W
przypadku \fBLOADLIN\fP jest to opcja wiersza poleceń. W \fBLILO\fP konieczne jest
użycie tego polecenia w pliku konfiguracyjnym \fBLILO\fP
\fI/etc/lilo.config\fP. Urządzenie podane w tej opcji musi być urządzeniem do
zamontowania, posiadającym odpowiedni główny system plików.
.SS "Zmienianie zwykłego głównego systemu plików"
.\" commit dc7a08166f3a5f23e79e839a8a88849bd3397c32
Domyślnie, w przypadku zwykłych głównych systemów plików, używane są
ustawienia jądra (np. ustawione w pliku jądra za pomocą \fBrdev\fP(8) lub
wkompilowane w plik jądra) lub opcje programu rozruchowego. W przypadku
zwykłego głównego systemu plików montowanego jako NFS, konieczne jest użycie
opcji rozruchowych \fBnfs_root_name\fP i \fBnfs_root_addrs\fP, aby przekazać
ustawienia NFS. Więcej informacji o głównym systemie plików jako NFS
znajduje się w pliku dokumentacji jądra
\fIDocumentation/filesystems/nfs/nfsroot.txt\fP (lub
\fIDocumentation/filesystems/nfsroot.txt\fP przed Linuksem 2.6.33). Więcej
informacji o ustawieniach głównego systemu plików znajduje się też w
dokumentacji \fBLILO\fP i \fBLOADLIN\fP.
.PP
Możliwe jest również, aby plik wykonywalny \fI/linuxrc\fP zmienił zwykłe
urządzenie główne. Aby \fI/linuxrc\fP mógł zmienić zwykłe urządzenie główne,
musi być zamontowany \fI/proc\fP. Po zamontowaniu \fI/proc\fP, \fI/linuxrc\fP zmienia
zwykłe urządzenie główne zapisując do plików proc:
\fI/proc/sys/kernel/real\-root\-dev\fP, \fI/proc/sys/kernel/nfs\-root\-name\fP oraz
\fI/proc/sys/kernel/nfs\-root\-addrs\fP. W przypadku fizycznego urządzenia
głównego, urządzenie główne jest zmieniane, przez zapisanie przez
\fI/linuxrc\fP numeru urządzenia nowego korzenia systemu plików do pliku
\fI/proc/sys/kernel/real\-root\-dev\fP. W przypadku głównego systemu plików na
NFS, urządzenie główne jest zmieniane przez zapisanie przez \fI/linuxrc\fP
ustawień NFS do plików \fI/proc/sys/kernel/nfs\-root\-name\fP oraz
\fI/proc/sys/kernel/nfs\-root\-addrs\fP, a następnie zapisanie 0xff (np. numeru
pseudourządzenia NFS) do pliku
\fI/proc/sys/kernel/real\-root\-dev\fP. Przykładowo, poniższy wiersz polecenia
powłoki zmieniłby zwykłe urządzenie główne na \fI/dev/hdb1\fP:
.PP
.in +4n
.EX
echo 0x365 >/proc/sys/kernel/real\-root\-dev
.EE
.in
.PP
W przykładzie dla NFS, poniższe wiersze poleceń powłoki zmieniłyby zwykłe
urządzenie główne na katalog NFS \fI/var/nfsroot\fP na serwerze NFS sieci
lokalnej, o numerze IP 193.8.232.7, dla systemu o numerze IP 193.8.232.2, o
nazwie \[Bq]idefix\[rq]:
.PP
.in +4n
.EX
echo /var/nfsroot >/proc/sys/kernel/nfs\-root\-name
echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \e
    >/proc/sys/kernel/nfs\-root\-addrs
echo 255 >/proc/sys/kernel/real\-root\-dev
.EE
.in
.PP
.\" commit 9d85025b0418163fae079c9ba8f8445212de8568
.\" FIXME . Should this manual page  describe the pivot_root mechanism?
.\"
.\"
.\"
\fBUwaga\fP: Korzystanie z \fI/proc/sys/kernel/real\-root\-dev\fP do zmiany głównego
systemu plików jest przestarzałe. Plik
\fIDocumentation/admin\-guide/initrd.rst\fP (lub \fIDocumentation/initrd.txt\fP
przed Linuksem 4.10) w źródłach jądra Linux oraz podręczniki
\fBpivot_root\fP(2) i \fBpivot_root\fP(8) opisują współczesne metody zmieniania
głównego systemu plików.
.SS Użycie
Główną motywacją implementacji \fBinitrd\fP było umożliwienie, aby konfiguracja
jądra była modularna przy instalacji systemu.
.PP
Oto możliwy scenariusz instalacji systemu:
.IP (1) 5
Program rozruchowy jest uruchamiany z dyskietki lub innego nośnika z
minimalnym jądrem (np. z obsługą \fI/dev/ram\fP, \fI/dev/initrd\fP oraz systemu
plików ext2) i ładuje \fI/dev/initrd\fP ze spakowaną gzip wersją pierwotnego
systemu plików.
.IP (2)
Plik wykonywalny \fI/linuxrc\fP określa, co jest wymagane do (1) zamontowania
zwykłego głównego systemu plików (tj. typ urządzenia, sterowniki urządzenia,
system plików) oraz (2) nośnika instalacyjny (np. płyta, sieć, taśma,
\&...). Może tego dokonać pytając użytkownika, sprawdzając samemu lub łącząc
te dwa podejścia.
.IP (3)
Plik wykonywalny \fI/linuxrc\fP ładuje wymagane moduły dla początkowego
głównego systemu plików.
.IP (4)
Plik wykonywalny \fI/linuxrc\fP tworzy i wypełnia główny system plików (na tym
etapie zwykły główny system plików nie musi być jeszcze kompletny).
.IP (5)
Plik wykonywalny \fI/linuxrc\fP ustawia \fI/proc/sys/kernel/real\-root\-dev\fP,
odmontowuje \fI/proc\fP, zwykły główny system plików i inne zamontowane przez
niego systemy plików, a następnie kończy działanie.
.IP (6)
Następnie jądro montuje zwykły główny system plików.
.IP (7)
System plików jest teraz dostępny i kompletny, zatem można zainstalować
program rozruchowy.
.IP (8)
Program rozruchowy jest konfigurowany do załadowania do \fI/dev/initrd\fP
systemu plików, który ma zbiór modułów, których użyto do uruchomienia
systemu (np. urządzenie \fI/dev/ram0\fP może być zmodyfikowane, następnie
odmontowane, a na końcu obraz jest zapisywany z \fI/dev/ram0\fP do pliku).
.IP (9)
System jest teraz gotowy do rozruchu i mogą nastąpić dodatkowe zadania
instalacyjne.
.PP
Kluczową rolą \fI/dev/initrd\fP w powyższym opisie jest korzystanie z danych
konfiguracyjnych ze zwykłego działania systemu, bez konieczności:
początkowego wyboru jądra, korzystania z przeładowanego jądra uniwersalnego
lub rekompilacji jądra.
.PP
Drugi scenariusz występuje w przypadku instalacji, gdy Linux działa na
systemach z różnymi konfiguracjami sprzętowymi, w jednolicie administrowanej
sieci. W takich przypadkach, może być pożądane, aby korzystać z niewielkiego
zbioru jąder (a najlepiej jednego) i minimalizować wielkość informacji
konfiguracyjnych danego systemu. Wówczas odmienny może być tylko plik
\fI/linuxrc\fP albo plik przez \fI/linuxrc\fP wykonywany.
.PP
Trzeci scenariusz to poręczniejsze dyski odzyskiwania. Ponieważ informacje
takie jak położenie partycji głównego systemu plików nie są wymagane w
czasie rozruchu, system załadowany z \fI/dev/initrd\fP może wyświetlić pytanie
i/lub skorzystać z autowykrywania, ewentualnie sprawdzając je następnie.
.PP
.\"
.\"
.\"
W końcu, co nie mniej istotne, dystrybucje Linuksa na płytach mogą korzystać
z \fBinitrd\fP w celu łatwej instalacji z tego nośnika. Dystrybucja może użyć
\fBLOADLIN\fP, aby bezpośrednio załadować \fI/dev/initrd\fP z płyty, bez
konieczności korzystania z dyskietek. Dystrybucja może też korzystać z
dyskietki rozruchowej \fBLILO\fP, a następnie załadować (poprzez bootstrap)
większy dysk RAM za pomocą \fI/dev/initrd\fP z płyty.
.SH PLIKI
\fI/dev/initrd\fP
.br
\fI/dev/ram0\fP
.br
\fI/linuxrc\fP
.br
.\"
.\"
.\"
\fI/initrd\fP
.SH UWAGI
.IP \[bu] 3
W bieżącym jądrze, wszelkie systemy plików, które pozostaną zamontowane przy
przeniesieniu \fI/dev/ram0\fP z \fI/\fP do \fI/initrd\fP będą wciąż dostępne. Wpisy
\fI/proc/mounts\fP nie są jednak aktualizowane.
.IP \[bu]
W bieżącym jądrze, jeśli katalog \fI/initrd\fP nie istnieje, to \fI/dev/ram0\fP
\fBnie\fP zostanie w pełni odmontowane, jeśli \fI/dev/ram0\fP jest używany przez
jakikolwiek proces lub zamontowano w nim system plików. Jeśli \fI/dev/ram0\fP
\fBnie\fP jest w pełni odmontowane, to \fI/dev/ram0\fP pozostanie w pamięci.
.IP \[bu]
.\"
.\"
.\"
.\" .SH AUTHORS
.\" The kernel code for device
.\" .BR initrd
.\" was written by Werner Almesberger <almesber@lrc.epfl.ch> and
.\" Hans Lermen <lermen@elserv.ffm.fgan.de>.
.\" The code for
.\" .BR initrd
.\" was added to the baseline Linux kernel in development version 1.3.73.
Użytkownicy \fI/dev/initrd\fP nie powinni polegać na zachowaniu opisanym w
powyższych uwagach. Może się ono zmienić w kolejnych wersjach jądra Linux.
.SH "ZOBACZ TAKŻE"
\fBchown\fP(1), \fBmknod\fP(1), \fBram\fP(4), \fBfreeramdisk\fP(8), \fBrdev\fP(8)
.PP
.\" commit 9d85025b0418163fae079c9ba8f8445212de8568
\fIDocumentation/admin\-guide/initrd.rst\fP (lub \fIDocumentation/initrd.txt\fP
przed Linuksem 4.10) w drzewie źródeł jądra Linux, dokumentacja LILO,
dokumentacja LOADLIN, dokumentacja SYSLINUX
.PP
.SH TŁUMACZENIE
Tłumaczenie niniejszej strony podręcznika:
Michał Kułach <michal.kulach@gmail.com>
.
.PP
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach
licencji można uzyskać zapoznając się z
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License w wersji 3
.UE
lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.
.PP
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy
dyskusyjnej
.MT manpages-pl-list@lists.sourceforge.net
.ME .
