PLD-doc/book/pl_book__konfiguracja/pl_konfiguracja__boot_loader.sec

pawelb cvs w pld-linux.org
Pon, 19 Lip 2004, 18:16:25 CEST


Author: pawelb
Date: Mon Jul 19 16:16:23 2004
New Revision: 4372

Modified:
   PLD-doc/book/pl_book__konfiguracja/pl_konfiguracja__boot_loader.sec
Log:
- dodano opis gruba, wymaga drobnych poprawek

Modified: PLD-doc/book/pl_book__konfiguracja/pl_konfiguracja__boot_loader.sec
==============================================================================
--- PLD-doc/book/pl_book__konfiguracja/pl_konfiguracja__boot_loader.sec	(original)
+++ PLD-doc/book/pl_book__konfiguracja/pl_konfiguracja__boot_loader.sec	Mon Jul 19 16:16:23 2004
@@ -9,7 +9,7 @@
       Dla architektur ix86 mamy do wyboru jeden z dwóch boot loaderów - lilo albo grub. 
 </para>
 </section>
-<section id="konfiguracja_pliki_lilo">
+<section id="konfiguracja_boot_loader_lilo">
 	<title>LILO</title>
 <para>
       Wiele osób korzystających z dystrybucji takich jak <productname>Debian</productname>
@@ -84,4 +84,85 @@
 <screen># lilo -v</screen>
 <para>Jeżeli nie pokazały się żadne błędy, boot loader powinien być zainstalowany na naszym dysku</para>
 </section>
+<section id="konfiguracja_boot_loader_grub">
+	<title>GRUB</title>
+	<para>
+        Każdy z nas zastanawiał się kiedyś nad alternatywą dla <command>lilo</command>, które lubiło czasem zawodzić.
+        Okazuje się, że istnieje bardzo dobra alternatywa o nazwie <command>grub</command>.
+        Ten drugi bootmanager różni się nieco od pierwszego. Największą różnicą jest obsługa dużej gamy systemów plików.
+        Dzięki możliwości bezpośredniego dostępu do systemu plików, jesteśmy w stanie załadować dowolny obraz,
+        który nie został umieszczony w pliku konfiguracyjnym.
+	</para>
+	<para>
+        Konfiguracja gruba różni się nieco od konfiguracji jego konkurentów. Przedewszystkim nie używamy już
+	nazw dysków opierających się na urządzeniach widniejących w <filename>/dev</filename> 
+	(np. <filename>/dev/hda</filename>). Grub przy pomocy BIOSa
+	sprawdza istniejące dyski w systemie i numeruje je począwszy od zera. Dla przykładu, jeżeli posiadamy
+        dwa dyski twarde (np. hda i hdc), pierwszy z nich zostanie oznaczony jako hd0, drugi jako hd1.
+        Sytuacja z partycjami wygląda podobnie, również numerowane są od zera, natomiast pierwsza partycja logiczna
+	będzie oznaczona numerem 4. Dla dotychczasowego <filename>/dev/hda1</filename> w grubie powinniśmy używać (hd0,0). Podane
+        nawiasy nie są przypadkowe, to cecha składni poleceń gruba. Jeżeli określamy jakiś dysk/partycję,
+        robimy to w nawiasach.
+	</para>
+	<para>
+        Przejdźmy do konfiguracji. Zakładamy, że zarówno rootfs, jak i boot leżą na tej samej partycji.
+        W przykładowej konfiguracji będzie to /dev/hda1. Plikiem konfiguracyjnym w domyślnej instalacji jest
+       <filename>/boot/grub/menu.lst</filename>.
+	</para>
+	<screen># cat /boot/grub/menu.lst
+timeout 15
+
+title  PLD 2.0 (Ac)
+root (hd0,0)
+kernel /boot/vmlinuz root=0301
+initrd /boot/initrd</screen>
+	<para>
+	Pewnie zastanawiasz się skąd wzięły się te dziwne cyferki przy <command>root=</command> ?
+	Nie ma w nich nic dziwnego, w naszym przypadku 03 to 'major' a 01 to 'minor' naszej partycji.
+	Skąd wziąć te cyferki? To nic trudnego, musimy tylko umieć przeliczać liczby dziesiętne
+	na szesnastkowe.
+	</para>
+	<screen># ls -l /dev/hda1
+		brw-rw----  1 root disk 3, 1 2004-06-03 18:41 /dev/hda1</screen>
+	<para>
+	Pierwsza liczba (3) to major, druga (1) to minor. Urządzenia w katalogu <filename>/devi</filename> posiadają
+        oznaczenia w systemie dziesiętnym, kernelowi należy przekazać je w szesnastkowym.
+        Akurat w przypadku hda1 nic się nie zmienia, bo zarówno liczby 3 jak i 1 w obu
+        systemach liczbowych są jednakowe. W przypadku podawania parametru <command>root=</command>
+        major można podać w postaci jednej cyfry, natomiast minor powinien być już rozwinięty do dwóch.
+        Tym sposobem możemy zamienić <command>root=0301</command> na <command>root=301</command>.
+	W przypadku dysków scsi postępujemy analogicznie.
+	</para>
+	<para>
+        Przejdźmy do instalacji gruba w bootsektorze dysku (MBR).
+	</para>
+	<screen># grub
+grub> root (hd0,0)
+Filesystem type is xfs, partition type 0x83
+
+grub> setup (hd0)
+Checking if "/boot/grub/stage1" exists... yes
+Checking if "/boot/grub/stage2" exists... yes
+Checking if "/boot/grub/xfs_stage1_5" exists... yes
+Running "embed /boot/grub/xfs_stage1_5 (hd0)"...  18 sectors are embedded.
+succeeded
+Running "install /boot/grub/stage1 (hd0) (hd0)1+18 p (hd0,0)/boot/grub/stage2
+/boot/grub/menu.lst"... succeeded
+Done.
+grub> quit</screen>
+	<para>
+        Tym optymistycznym akcentem staliśmy się posiadaczami bootloadera <command>grub</command>
+        w naszym systemie. W odróżnieniu od <command>lilo</command> nie ma potrzeby ponownej
+        instalacji gruba w MBR w przypadku zmiany kernela lub pliku konfiguracyjnego.
+	</para>
+	<para>
+        Może brakować Ci jeszcze możliwości startu z partycji, na której masz zainstalowany np.
+        system MS Windows. Dodanie kolejnego wpisu należy do bardzo prostych czynności.
+        Zakładająć, że jest on zainstalowany na /dev/hda2, na końcu pliku konfiguracyjnego dopisujemy:
+	</para>
+	<screen>title Windows
+rootnoverify (hd0,1)
+chainloader +1
+</screen>
+</section>
 </section>




Więcej informacji o liście dyskusyjnej pld-doc