A grub rendszer betöltő újratelepítése

Átírás

1 i A grub rendszer betöltő

2 ii COLLABORATORS TITLE : A grub rendszer betöltő ACTION NAME DATE SIGNATURE WRITTEN BY Hazai, Géza J július 8. REVISION HISTORY NUMBER DATE DESCRIPTION NAME

3 iii Tartalomjegyzék 1. Bevezetés 1 2. Rendszer betöltők Amikor még minden a DOS-ból indult: LoadLin A Linux betöltő: LILO GRUB könnyed betöltő Amikor a GRUB-ot javítani kell 4 4. Térjünk a lényegre: hogyan kell csinálni? A kezelendő rendszer felépítése A Windows feltelepítése után Ha a chroot üzen stage1 read not correctly

4 iv Ábrák jegyzéke bites PCLinuxOS induló képernyő LILO menü Betöltő-javító lemez indító képernyő RescaTux Kivonat Rendszeresen visszatérő probléma az, hogy a Linuxot egyszer csak nem lehet betölteni. Leggyakoribb ok a gépre később telepített (újratelepített) Windows, ami a rendszer betöltőt felülírja. Ahogy a modernebb változatok megjelennek, egyre bonyolultabbá válik a betöltő helyreállítása. Ez a leírás segítséget kíván nyújtani az említett helyzetek megoldásához.

5 1 / Bevezetés A Linux örvendetes elterjedése új helyzet elé állította az ezzel foglalkozó szakembereket. Az eredeti célkitűzésnek 1 megfelelően egyre-másra szembesültek a felhasználók a rendszertechnikai kérdésekkel. Ezek egyik lényeges eleme lett a rendszer betöltő beállítása, szükség szerinti módosítása. A téma akkor vált népszerűvé, amikor a Windows vált szükségessé. Sokan ugyanis nem tudtak még teljesen elszakadni régi megoldásaiktól, így számítógépükön 2 operációs rendszer is elérhető, betölthető volt. A Windows viszont nem kímélte a betöltőt és irgalmatlanul felülírta, aminek következtében a gondosan feltelepített és beállított Linux elérhetetlenné vált. Kísérletező kedvű felhasználókkal az is előfordult, hogy különböző kísérletezések következtében rendszere nem volt indítható, egy-egy sikertelen kernel fordítást követően megjelent a nem kívánt üzenet: kernel panic... Edz persze nem olyan nagy baj, könnyen orvosolható, ha... kellően előrelátó volt a szenvedő fél, de néha még ez sem segített. Az igény megvolt a rendszer elérésére, csak éppen a tudás, a tapasztalat hiányzott. Ha nem volt a közelben egy hozzáértő szakember (vagy csak egyszerűen ilyen problémát tapasztalt és megoldott felhasználó), könnyen kedvét veszthette a merész alkalmazó. Egy szó, mint száz: nem árt néha olyan dolgokat is megismerni, ami nem csak a gép egyszerű használatának a része, hanem a használatba vétel szükséges eleme lehet. Ebben a kis írásban azoknak szeretnék segítséget nyújtani, akik a számítógépet (PC-t, laptopot) intelligens írógépnél többre tartják és használják. 2. Rendszer betöltők Ma már mindennapos dolog, hogy a számítógép bekapcsolása után valamilyen rendszerbetöltő egy menüt jelenít meg, amelyben a betölthető rendszerek közül lehet választani. Ilyen indító menü akkor is jelen van, ha csak egy rendszer van a gépen, mert egy olyan menüpont is szerepel(het), ami vészhelyzet esetére biztosít betöltési lehetőséget. A PCLinuxOS induló képernyőjén ( 1. ábra) ez látható. 1 Minden háztartásban legyen számítógép és rajta olyan programok, amik könnyen kezelhetőek, internetezésre, levelezésre, egyszerűbb dokumentumok megírására legyen alkalmas.

6 2 / ábra. 64 bites PCLinuxOS induló képernyő Egy nagyon rövid ismertető (történeti áttekintés) olvasható a következő pontokban a betöltőkről. Akit ez nem érdekel, nyugodtan lépjen a... pontra Amikor még minden a DOS-ból indult: LoadLin Amint a neve is mutatja, ez egy Linux betöltő. Annak idején ez egy olyan lehetőség volt, hogy a futó DOSrendszerből (később Windows 95, Windows 98, legvégül Windows ME) a loadlin parancs kiadásával át lehetett térni Linuxra. Ez a MBR-t nem módosította. Mint minden emuláció, a sebessége nem érte el az alaprendszer mutatóit, viszont a fájlrendszerét az alaprendszerből is meg lehetett tekinteni A Linux betöltő: LILO A LILO (LInux LOader) sokáig volt szinte minden disztribúció alapértelmezett betöltője. Ez már módosíthatta a MBR-t, ugyanakkor a rendszer akár floppy-ról is betölthető volt. A képernyőn egy menü jelent meg (2. ábra), amiből kiválasztható volt, hogy melyik rendszert szeretnénk indítani. Legfeljebb 16 menüpont lehetett. Ezek közül az egyik beállítható volt alapértelmezettnek, így egy bizonyos idő eltelte után (ami szintén állítható volt) automatikusan elindult. 2 ami kényelmes volt ugyan, de hozzáértés hiányában könnyen megrogyasztható volt a vendég rendszer.

7 3 / ábra. LILO menü Az egyes menüpontokat meg kellett határozni. Lényeges elem volt, hogy bármilyen módosítást hajtottak végre a /etc/lilo.conf fájlon, ezt követően mindig futtatni kellett a lilo parancsot (ennek elmaradása jó esetben csak az előző állapot szerinti betöltőt jelenítette meg). A betöltés során a LILO betűk jelentek meg, ahol minden egyes betű a betöltés fázisát jelölte. Ma már csak alternatívaként jelenik meg néhány disztribúcióban, használata gyakorlatilag megszűnt, 2.3. GRUB könnyed betöltő A GRUB a GNU GRand Unified Bootloader (GNU nagyszerű egységes betöltő) rövidítése ben a FSF (Free Software Foundation Szabad Szoftver Alapítvány) által kialakított Multiboot Specification alapján készült. Ennek lényege az, hogy különböző (többféle) kernelt lehet betölteni egy megfelelő szoftverrel. A GRUB-ot 1999-ben fejlesztették ki azzal a céllal, hogy minél egyszerűbben, átláthatóbban lehessen konfigurálni. A betöltési folyamat során, majd a U*X rendszerek futásakor egy egyszerű, bash-hoz hasonló parancssoros felület áll rendelkezésre. A beállításokat a betöltés során olvassa be, ami azzal az előnnyel is jár, hogy a felhasználó az egyes módosítások után egy egyszerű újratöltéssel ellenőrizheti, milyen módon lépett életbe a változtatás (vagyis nem kell külön életbe léptetni, mint a LILO esetén a lilo paranccsal). Azzal együtt, hogy a GRUB fejlesztése intenzíven folyik, megjelent a 2. verzió, ami elvében is különbözik az e. verziótól, a disztribúciók többsége az eredeti, egyszerű változatot ajánlja fel telepítésre.

8 4 / 12 A GRUB2-vel szembeni ellenérzések Bár a fejlődés szükségszerű velejárója volt a fejlettebb változat megjelenése, mégis sokan idegenkednek a használatától. Ennek számos oka lehet, de elsősorban az a tapasztalat lehet a háttérben, hogy megjelenése utáni korai szakaszban a hozzá kialakított automatikus rendszer pásztázó nem minden esetben ismerte fel a többi meglévő operációs rendszert (főleg a Windows-t) multiboot környezetben. A másik probléma az, hogy a megfelelő javítások életbe léptetése érdekében külön parancsot kell kiadni, nem elég az újdonság átvezetése. Ennek az anyagnak nem célja a GRUB részletes bemutatása, erről számos cikk található az interneten. 3. Amikor a GRUB-ot javítani kell Azzal együtt, hogy a Linux egyik bájos tulajdonsága a stabilitása, számos olyan esetről tudunk, amikor ez csorbát szenved. Számos esetet lehetne felsorolni, amikor a rendszer betöltése hiúsul meg, erre azonban nem vállalkozhatok, mivel jó pár felhasználói hibából ered, és elég nehéz lenne rendszerbe foglalni ezeket ahány (kísérletező) felhasználó, annyi esemény... Van azonban egy olyan eset, ami elég rendszeresen fordul elő: a Windows újratelepítéséből adódóan (vagy a Windows később történő telepítése miatt) a Linux elérhetetlenné válik. Nem kívánok a részletekbe belemenni (nem is szakterületem), elég annyi, hogy a Windows az MBR-t teljes egészében kisajátítja. Ebből persze további problémák is felmerülnek, amiről a későbbiekben szót ejtek. Másik eset az, amikor valami megváltozik. Ez általában a kísérletező kedvű felhasználók rettegett helyzete, ugyanis korábbi egy partíció kettéosztása, vagy éppen két partíció összeolvasztása okozhat olyan helyzetet, amikor belső azonosítók változnak meg, és a GRUB egy-egy menüeleme már nem azt találja a megjelölt tárolórészen, ami a betöltéshez kell. Ilyenkor jelenik meg a kernel panic felirat, amivel nem lehet megbarátkozni és néha gyakorlott felhasználó is tehetetlennek érzi magát. Több éves tapasztalatom alapján mondhatom, hogy sokszor érdemes egy kis ideig nem foglalkozni a dologgal (néhány percig, esetleg óráig), lenyugodni, mert a kapkodás csak további problémákat szül. Az utóbbi időben szerencsére számos olyan alkalmazás jelent meg, ami segít a bajba jutottakon. Ilyen például: Boot-Repair-Disk, the must-have rescue CD! 3. Letöltés és CD-re kiírás után egy sok lehetőséget felkínáló betöltő javító live rendszert kapunk. Az indítóképernyő elég beszédes (3. ábra): 3 Betöltő-javító lemez, a lennie kell biztonsági-lemez!

9 5 / ábra. Betöltő-javító lemez indító képernyő Ez azért is érdekes, mert egy javításra is teljességgel alkalmas, valóban rescue CD-ről van szó. A Boot-Repair lemezről néhány szó Csak egy 64 bites PCLinuxOS-en próbáltam ki. Viszonylag sokat futott, de megoldotta a problémát (ami amúgy nem is volt, de ez mellékes). Egy Debian alapú, LXDE-s felületű rendszer, ebből gondolom, hogy a GRUB2-vel is elbánik. Valószínűleg az olyan túlbonyolított rendszert is jól kezeli, mint az én munkaállomásom, de nem kísérleteztem vele. Jól példázza a gondos munkát, hogy mind 32 bites, mind 64 bites kernele is van, ha nem a megfelelőt töltöd be, figyelmeztet. Nem tudom, hogy mennyire széles a fájlrendszer választéka, de minden jel szerint ext3 és ext4 felépítést ismer. Külön érdekesség, hogy azt is érzékelte, hogy a teszt rendszeremen a boot mappa külön partíción van! Egy apró kellemetlenséget érzékeltem: csak angol (amerikai) billentyűzetet ismer. Aki dolgozott ilyennel, nyilván nem lepődik meg, aki viszont nem, annak némi nehézséget okozhat. Nekik szánom kis támaszul, hogy a <0> (nulla) az <Ö>, a <-> az <Ü>, a </> pedig a <-> helyén van. Napjainkban meglehetősen sajátos termék jelent meg: az UEFI. Úgy tűnik, hogy a kezelése ugyanúgy meg fog oldódni, mint annak idején az ún. soft-modem megoldása 4. A Home Linux Secure Remix honlapon megjelent lehetőség állítólag orvosolja ezt a kellemetlenséget 5. 4 A Linux térhódításának kezdetén még a betárcsázós internet kapcsolat volt a mérvadó. A nagy gyártók által forgalomba hozott modem kártyákon egy idő után nem volt szoftver, hanem a Windows szolgáltatott a rendszeren belülről a kapcsoláshoz szükséges programot. A Linuxos világgal azonban nem lehet kiba...brálni! Rövidesen megjelent a megoldás, majd az akkori kernel fejlesztői fába is beépítették a kódot. A dolognak egy kétségtelen előnye lett: ezek a soft-modem-ek lényegesen olcsóbbak voltak, így rendszeres cseréjük (az elérhető maximális vonali sebesség szinte naponta változott) nem okozott irreálisan nagy anyagi megterhelést. 5 Nincs a birtokomban ilyen gép, így kipróbálni nem tudtam.

10 6 / 12 Nem csak állítólag A dokumentum ennek a részének leírását követően kedves barátom, akinek pont UEFI gondja volt, az említett link alapján sikerült a problémát megoldania. Még egy érdekes projektre szeretném a figyelmet felhívni: Rescatux & SG2D (4. ábra). 4. ábra. RescaTux Ez több, mint egy egyszerű GRUB javító, ahogy a beharangozója is említi: kiigazítja a GRUB/GRUB2-t, ellenőrzi és javítja a fájlrendszert, kikapcsolja a Windows jelszót, megváltoztathatja a GNU/Linux jelszót, újraépíti a sudoers fájlt, és még sok minden lehetőség... kb. 367 Mb méretű Minden valószínűség szerint a két projektnek köze van egymáshoz, mert számos megoldás ugyanolyan (pl. a menü szerkezete). Ennek további előnye, hogy USB kulcsra is kiírható.

11 7 / 12 Mi szükség van erre a leírásra? Ha ilyen felkészült különféle alkalmazások vannak, miért szükséges egy ilyen leírás? merül fel jogosan a kérdés. A válasz nem nehéz: Amikor minden rendben van, látszólag felesleges az egyes folyamatok hátterét tudni. A baj akkor kezdődik, amikor valami elégtelenség lép fel. Ha ilyenkor valamilyen szinten ismerős az események belső sorrendje, a feltételek, nagyobb a valószínűsége, hogy a kérdésre a választ könnyebben megtalálható avagy szakszerűbben lehet kérdéseket feltenni a hozzáértő(bb)nek. Anélkül, hogy mások szakmai felkészültségét minősíteném, megemlítem, hogy az egyik szoftverforgalmazó cég mérnöke képtelen volt egy viszonylag könnyű problémát megoldani. Amikor szoftveres munkatársaimmal együtt végül sikerült a megoldást megtalálni, kiderült, hogy a hibajavításra mindenféle módszert tanítottak meg nekik, de ténylegesen csak alkatrész-cserére képesek. Beismerte, hogy ha az elméleti alapokat jobban ismerte volna, könnyebben megtalálta volna hibát és annak javítási módszerét. Nem állítom, hogy az ilyen manuális megoldások az üdvözítők. Az biztos, hogy a rendszer mélyebb megismerésében segít Térjünk a lényegre: hogyan kell csinálni? Aki egyenesen ide navigált az olvasásban, tulajdonképpen nem sokat vesztett. A lényeget itt írom le. Azért mégis azt javaslom, hogy ez előző fejezeteket is alkalomadtán nézzék át hátha találnak benne hasznos információt. Az egész folyamat nem túl komplikált. Azért is érdemes egy kicsit foglalkozni vele, mert nem csak a GRUB javítására, hanem más rendszertechnikai tevékenységre is alkalmas. A lényege az, hogy felépítjük a rendszerünket, majd az így kialakított rendszerben a megfelelő feladatokat elvégezzük A kezelendő rendszer felépítése Az legfontosabb: tisztában kell lennünk a kezelendő rendszer kialakításával. Mit is jelent ez? Mi hová van becsatolva? Nagyon lényeges kérdés! Abból kell kiindulni, hogy nem minden Linux rendszer egyszerű munkaállomás, ahol legfeljebb a /home van külön partíción, hanem egyéb szempontok alapján eléggé tagolt a rendszer. Ennek feltérképezésében sokat segít a /etc/fstab vizsgálata. Én egy jó bonyolult rendszert alakítottam ki. Ennek elsőrendű oka az volt, hogy a laptopomon egy szerver kialakítást modelleztem amúgy meg nem zavar. A Linux egyik nagyszerűsége, hogy mindent fájlként kezel, így egy külön partíción lévő rendszer részt a felcsatolások után már egyben lát. A továbbiakban a jelenleg használt rendszeremet veszem alapul. Először nézzük meg a /etc/fstab fájl tartalmát. # Entry for /dev/sda5 : UUID=86b0eaf9-435a-4a99-acef-22a02d2e6371 / ext4 defaults 1 1 # Entry for /dev/sda1 : UUID=188b6cd2-e55a cfc-f4a7bf986dc7 /boot ext4 defaults 1 2 # Entry for /dev/sda9 : UUID=8d5ee4d1-174f-4e32-93e6-b7571c094bca /home ext4 defaults 1 2

12 8 / 12 # Entry for /dev/sda10 : UUID=a8bde949-c5f0-48b2-83e5-6eb0eae155e2 /home2 ext4 defaults 1 2 none /proc proc defaults 0 0 # Entry for /dev/sda6 : UUID=970b2f73-c2fc-424f-843c-affd98a1f6df /tmp ext4 defaults 1 2 # Entry for /dev/sda7 : UUID=ff395d74-0fee d4f-c3476f9ce00e /usr ext4 defaults 1 2 # Entry for /dev/sda8 : UUID=5e588ec4-d021-4f3b-912e-9c02eb007b62 /var ext4 defaults 1 2 # Entry for /dev/sda2 : UUID=c4107dde-3cde-4834-b9c7-d092e6f63785 swap swap defaults 0 0 none /dev/pts devpts defaults 0 0 Ez a sor (és mindegyik, amelyik # jellel kezdődik) megjegyzés. A következő sorban megadott eszköz fizikai neve. Az eszköz azonosítója és további adatok: csatolási pont, fájlrendszer típusa, csatolási opciók; arra kell ügyelni, hogy az adott fájlrendszerre érvényes opciók szerepeljenek, a dump számára információ: szükséges-e a fájlrendszert ömleszteni (archiválásban való részt vétel), a fsck számára információ: a rendszer indításakor az adott fájlrendszert kell-e ellenőrizni. Általános gyakorlat, hogy a / kötelezően ellenőrzendő, e többi nem. A /etc/fstab elég szemléletesen leírja a rendszer struktúráját. Bár az egyes partíciók nem az eszközök fizikai nevének sorrendjében szerepelnek, azért mégis kideríthető, hogyan néz ki a felépítés: / --> /dev/sda5 -- bin -- boot --> /dev/sda1 -- dev -- etc -- home --> /dev/sda9 -- home2 --> /dev/sda10 -- initrd -- lib -- lost+found!!! -- media -- mnt -- opt -- proc -- root -- sbin -- srv -- swap -- sys

13 9 / tmp --> /dev/sda6 -- usr --> /dev/sda7 -- var --> /dev/sda8 Ebben a fában nem látható a (nem túl szerencsés magyar szóval) cserehely, eredeti nevén swap 6. Ez ugyanis nincs a rendszerbe felcsatolva (nem is kell, sőt nem szabad). De ugyanígy nem találunk /dev/ sda3-at sem. Ez egy létező partíció, mint ahogy az fdisk kimenete is mutatja: /dev/sda lemez: GB, bájt 90 fej, 63 szektor, cilinder, összesen szektor Egység: szektorok 1 * 512 = 512 bájt Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Lemezazonosító: 0x000f2c05 Eszköz Indítás Eleje Vége Blokkok Az Rendszer /dev/sda1 * Linux /dev/sda Linux lapozó / - Solaris /dev/sda HPFS/NTFS /dev/sda Kiterjesztett /dev/sda Linux /dev/sda Linux /dev/sda Linux /dev/sda Linux /dev/sda Linux /dev/sda Linux Íme... Ide (erre a winchester-re) kerül majd fel a Windows. Nem örömömben, hanem egy alkalmazás, amire elkerülhetetlenül szükségem van, csak valódi W$ alatt működik (vagyis a VirtualBox sem megoldás). Eddig nem volt szó az elsődleges és logikai partíciókról. Azért van szükség ennek tisztázására, mert elsődleges partíció alapértelmezésben összesen 4 lehet (függetlenül a winchester típusától), de ha mind a 4-et felhasználtuk, akkor már logikai partíciót nem áll módunkban létrehozni. Ez alapján természetes, hogy a <t>d<x><d> tárolón <d> értéke 1 4 közé esik 7. A 4 feletti érték már logikai partíció. Azt kell erről tudni, hogy ténylegesen egy kiterjesztett partíció van, amin belül vannak részekre tagolva a logikai partíciók. Ezt látni is lehet, mert a /dev/sda4 kezdő címe egybe esik a /dev/sda5 kezdő címével, míg a záró címe a /dev/sda10 záró címével! A partíciók kiosztása már a telepítésnél eldől, így ennek utólagos változtatása csak igen körültekintően történhet. Ahogy szokás mondani: FIGYELEM! Csak akkor fogj bele, ha tudod, mit csinálsz! 6 Az ugyanilyen nevű könyvtár nem a cserehely! 7 Ebben a bonyolult kifejezésben t h (IDE) vagy s (SCSI, SATA) lehet; x pedig a tároló sorrendjére utaló betű ( a : első, b : második stb.)

14 10 / 12 Még annyit, hogy elsődleges partíciónak azokat a területeket szoktam megjelölni, amelyek sérülése esetén a rendszer egyes esetekben még megmenthető, vagy valami más komoly okom van rá. Jelen esetben a /boot az egyik ilyen, mivel az itt történő nem kívánt változások még a rendszer integritását nem, vagy csak csekély mértékben érintik. A swap (cserehely) meg azért elsődleges partíción van, mert abban a kellemetlen esetben, amikor a rendszer megoldhatatlanul omlik össze, általában a memória tartalmát ide üríti. Ennek elemzése segíthet a hiba feltárásában. A fenntartott /dev/sda3 meg majd a W$ helye, és még az is megoldható, hogy a Windows lapozó helye és a Linux cserehelye ugyanaz az eszköz legyen. Ha nem használjuk ki az összes elsődleges partíció lehetőségét, a kiterjesztett partíció a soron következő lesz, csak a befoglalt logikai partíciók számozása kezdődik 5-től. Ezeknek az ismereteknek a birtokában most már feltelepíthetjük a Windows-t. Előtte azonban jól jegyezzük meg a rendszer felépítését, sőt nem tűnik pazarlásnak, ha a biztonság kedvéért a /etc/fstab fájlt kinyomtatjuk A Windows feltelepítése után E dokumentáció kereteit túllépi a telepítés ismertetése. Elegendő annyit tudni, hogy a /dev/sda3-ra került és eltűnt a GRUB menü! Mit lehet tenni? Mielőtt bármihez kapkodnánk, építsük fel rendszerünket az ismert információk alapján. Ehhez szükségünk van egy Live CD/DVD-re. Ma már minden valamire való disztribúció telepítője ezt a technikát alkalmazza. Jó megoldás, hiszen a Linuxra vágyó felhasználó biztonságosan kipróbálhatja, mit is tud az adott összeállítás. De más célra is használhatjuk, így az eltűnt betöltőnk visszaszerzésére is. Mindössze azt kell elérnünk, hogy a számítógép ne a merevlemezről, hanem a CD meghajtóról induljon. Ennek elérése gépenként eltérő lehet, de általában a BIOS bejelentkezésekor a F12 lenyomására megjelenik a boot menü, amiben kiválasztható a betöltő eszköz. Miután sikerült a Live rendszer betöltése, nyissunk egy konzolt (például KDE desktop-on a konsole), majd lépjünk rendszergazdai üzemmódba ha már nem abban vagyunk. Fel kell építeni a rendszerünket 8. Legelőször is választanunk kell egy olyan könyvtárat, amelyre majd felcsatoljuk a megfelelő partíciót az én esetemben a /dev/sda5-t. Számos lehetőség van, én általában a /media-t használom, mert a PCLinuxOS CD-n a /mnt mappában van valami fájl (vagy almappa?), ami nem tudom, milyen célt szolgál jobb a békesség :-). Az is jó megoldás, ha készítünk egy mappát, és arra dolgozunk. Ne felejtsük el, hogy Live CD-ről indultunk, így ez a könyvtár csak a memóriában fog létezni, egy újratöltésnél (vagy a gép kikapcsolásánál) megsemmisül. De nincs is rá szükségünk, csak most: mkdir /lemez A továbbiak talán nem igényelnek magyarázatot: mount /dev/sda5 /lemez mount /dev/sda1 /lemez/boot mount /dev/sda6 /lemez/tmp mount /dev/sda7 /lemez/usr mount /dev/sda8 /lemez/var Ez persze nem kevés (úgy értem: begépelni), és sajnos még nem vagyunk a végén. Még két felcsatolási parancsot ki kell adni, de ismertetése előtt szükséges hozzá egy kis magyarázat: 8 A példában az ismertetett rendszer partíció kiosztását követem.

15 11 / 12 Más dokumentációban már szó volt arról, hogy a /proc fájlrendszer a betöltés során épül fel, lényegében a memória egyfajta tükre lesz a tartalma. Annak érdekében, hogy a kialakított rendszeren dolgozni tudjunk, a betöltött rendszer (ami a Live, vagyis nem a tárolón található rendszer!) /proc mappáját hozzá kell csatolni a kialakítandó rendszerhez úgy, hogy közben a memóriában lévő rendszer is használni tudja. Ugyanez vonatkozik a /dev mappára is. Éppen ezért a mount parancs bind kapcsolóját fogjuk használni. A leírás szerint: Lehetőség van egy mappa felcsatolására más helyre úgy, hogy közben az eredeti hely is használható marad. Így a fájlt (fájlrendszert) egyszerre két helyről is el lehet érni. mount --bind /proc /lemez/proc mount --bind /dev /lemez/dev Írjunk inkább szkriptet? Nem rossz ötlet. Ha magát a rendszer gyökerét már felcsatoltuk, csak el kell indítani a szkriptet, máris minden a rendelkezésünkre áll. Azért kell így tennünk, mert a Live CD-re nem tudunk írni vagyis csak a lemezen létrehozott szkript futtatására van mód. Vagyis: # mkdir /lemez # mount /dev/sda5 /lemez # cd /meze/root #./mount_partitions Ezt a szkriptet csak egyszer kell megírni. Igaz, amikor átstruktúrálod a rendszert (ez meg előfordulhat), át kell írni, de megéri a fáradságot! A mount_partitions tartalma: #! /bin/bash mount /dev/sda5 /lemez mount /dev/sda1 /lemez/boot mount /dev/sda6 /lemez/tmp mount /dev/sda7 /lemez/usr mount /dev/sda8 /lemez/var mount --bind /proc /lemez/proc mount --bind /dev /lemez/dev Ez azért nem egy nagy mutatvány, mégis mennyit segít! Például nem gépeled el a parancso(ka)t... Most már minden a rendelkezésünkre áll ahhoz, hogy az így elkészített rendszerbe belépjünk. Erre való a chroot parancs. chroot: parancs vagy interaktív shell futtatása speciális gyökérmappában. Mielőtt azonban belemerülnénk az új rendszerbe, érdemes megjegyeznünk, hogy nincs még swap terület bekapcsolva. Valószínűleg nem lesz rá szükség, de mibe kerül bekapcsolni? Utána már ki lehet adni a grub helyreállító parancsát: # chroot /lemez chroot-olt rendszer# swapon /dev/sda2 chroot-olt rendszer# grub-install --root-directory=/lemez (hd0)

16 12 / 12 Ha minden rendben, a grub ilyen értelmű üzenetet küld... Na, de ha nem? A chroot-ból <Ctrl>+D lenyomásával lehet kilépni Ha a chroot üzen... Régebben találkoztam egy olyan karbantartó lemezzel, amelyen a zsh volt az alapértelmezett shell. Meglepetésemre a chroot igen csúnya üzeneteket küldött. Igaza volt, mert a szintaktikailag is korrekt parancs: # chroot /lemez /bin/bash Így már problémamentesen tudtam használni (bash minden Linuxban van) stage1 read not correctly Ezzel a hibával a napokban találkoztam először. A dolog meglehetősen zűrzavaros volt, ugyanis Linux nem volt elérhető, a Windows viszont nem ismerte fel a WiFi kártyát. Sebaj, grub helyreállítás... lett volna, de ezt a hibaüzenetet kaptam: /lemez/boot/grub/stage1 read not correctly és természetesen semmi nem működött. A megoldás: mindent ugyanúgy végig kell csinálni, mint eddig, egészen a swapon paranccsal bezárólag, Meg kell hívni a grub-ot: # grub Probing devices to guess BIOS drives. This may take a long time. Egy darabig dolgozik, majd grub> promptot ad, Meg kell határozni a gyökér partíciót, majd a setup parancsot futtatni: grub> root (hd,0,4) grub> setup (hd0) A második parancs után kiír néhány dolgot, de végül helyreállítja az összes szükséges adatot, betöltőt. Amikor a grub> prompt isméte megjelenik a quit paranccsal kell kilépni! Természetesen más hiba esetek is előfordulhatnak. Ha valaki találkozik itt nem leírt problémával, jelezze nekem.