Egyéb információk

Újdonságok a BIOS kapcsán

1995-ben a Microsoft kiadott egy specifikációt a BIOS int 0x13-as API-jának (API=Application Program Interface) bővítésére (azt viszont nem tudom, van-e már BIOS, ami támogatja ezt). Itt már nem 16 bites regiszterekben történik a C/F/S paraméterek átadása a BIOS és az applikáció (adott esetben a boot-oló program) között, ezzel lehetővé válik, hogy 1024 cilindernél (illetve 8 GigaByte-nál) nagyobb lemezeket is kezelni lehessen BIOS hívásokkal. Az új függvények magukban foglalják szektorok olvasását (int13/42) és írását (int13/43), és még egyéb, kisebb jelentőségű hívásokat. Van lehetőség a lemez geometriájának lekérdezére is, de tipikusan erre nincs szükség, mivel a címzés ezen új függvényeknél 64 bites lineáris szektorcímmel történik - néhány évig bizonyára elég lesz ebből a címből az alsó 32 bit is, azzal is 2048 GigaByte-ra nőtt fel a felső kapacitáshatár :-)

Az említett függvényekről alapvető információkkal a következő lapok szolgálnak: Check Extensions Peresent, Extended Read, Extended Write és Data Structure.

A BIOS bövítésével egyidőben bevezettek néhány új partíció típuskódot is:

A fentebbiek közül azoknál a típuskódoknál, ahol INT13EXT szerepel, a BIOS bővítésen keresztül férhet hozzá a boot-oló program a lemezegységhez. A partíciós bejegyzésben ilyenkor figyelmen kívül vannak hagyva a C/F/S stílusú címek, csak a lineáris (relatív) szektorcím és a szektorméret az érdekes. Természetesen a logikai partíciók láncolójának (extended partíció) is kellett új típuskód, így már két speciálisan kezelendő kód is van (0x05 és 0x0F).

A partíciós bejegyzésben a lineáris szektorcím méretét ezen INT13EXT stílusú típuskód esetében sem növelték meg 32 bitről 64 bitre (bár az új BIOS függvények 64 bites címekkel képesek dolgozni), így 2048 GigaByte (2 TeraByte) méretű lemezt lehet kezelni. Ez jó ideig elegendőnek tűnik még. Megjegyzendő viszont, hogy ez a korlát csak az elsődleges partíciók esetében szerepel így. Extended partíció láncnál minden egyes új partíciót a hozzá tartozó másodlagos partíciós táblához képesti relatív szektorcíme címez (lásd a A másodlagos partíciós táblák sajátosságai című fejezetet). Ezért a logikai partícióknak a méretére igaz csak a 2 TeraByte-os korlát, összes kapacitásuk lehet nagyobb 2 TeraByte-nál. Persze ilyenkor az MBR-ben lévő Extended partíció nem tudja lefedni a lánc teljes méretét, de ez valószínű nem okoz majd gondot.

Néhány szó a lilo-ról

A lilo a Linux Loader rövidítése, egy többféle operációs rendszert betölteni képes program. Fő célja persze az, hogy a Linuxot betöltse. (A Linuxról olvashatsz többek között a Magyar Linux Alapítvány honlapján.) Nem óhajtok a lilo-ról sem kimerítően beszélni (pl. a fontosabb dolgok közül nem beszélek az /etc/lilo.conf file tartalmáról, a -r opcióról, stb.), csak néhány érdekességet írok itt le.

A boot-olás szempontjából a legfontosabb információ az, hogy a Linux nem BIOS hívásokkal kezeli a hardware-t, így a merevlemezt sem. Boot-oláskor viszont a lilo-nak nincs más választása, hisz olyankor még nincs bent a memóriában a kernel. Továbbá a kernelt magát (általában) már a Linux file-rendszeréről kell betöltenie, aminek felépítését, így a benne lévő file-ok helyét is maga a kernel tudja.

Ezt a dilemmát a lilo úgy oldja meg, hogy valójában két részre bomlik:

Az /sbin/lilo-t Linux alatt futtatva az lekérdezi a kerneltől, hogy a betöltendő file-ok (pl. maga a kernel (tipikusan /boot/vmlinuz)) blokkjai hol (vagyis milyen C/F/S címen) találhatók a lemezen, és ezeket az adatokat beírja a /boot/map file-ba. Persze ennek a file-nak a helyét is lekérdezi, ezt az adatot magába az MBR-ben lévő programocskába írja bele. Így aztán boot-oláskor BIOS hívásokkal tud hozzáférni mindenhez, ami számára fontos.

Ezek után nyilvánvaló, hogy minden kernelfordítás után újra kell futtatni az /sbin/lilo-t, hogy az új kernel elhelyezkedését a map file-ba írhassa. Ha ezt elmulasztjuk, könnyen lehet, hogy a régi kernel indul el, még ha le is töröltük a lemezről :-)

Minden file, amire a boot-olás során szükség van, és amiket BIOS hívásokkal kell elérni, a /boot/ könyvtárban található. Ezek tehát azok a file-ok, amiknek a lemez első 1024 cilinderén belül kell lenniük, hisz a BIOS (az előzőleg említett BIOS bővítés nélkül) csak ezeket képes kezelni. Nagy kapacitású lemez esetén elegendő egy kis méretű partíciót kreálni a lemez elején és a /boot/ könyvtárat ebbe helyezni, ezzel elérhetjük, hogy a kritikus file-ok BIOS-ból olvashatóak legyenek.

Gondot okoz viszont az, hogyha a kernel a BIOS-tól eltérő geometriát feltételezve adja meg a file-ok helyét, hiszen így boot-oláskor teljesen fals helyről beolvasott adatokat próbál a processzor utasításként végrehajtani. Ennek eredménye tipikusan az, hogy a kezdeti LILO feliratnak csak a fele (LI) jelenik meg a monitoron, aztán a gép lefagy.

Ilyen esetben általában elegendő megoldás az, hogyha bekapcsoljuk a lilo linear opcióját az /etc/lilo.conf-ba írt linear kulcsszóval, vagy az /sbin/lilo -l opcióval. Ennek hatására a map file-ba nem a C/F/S cím, hanem a lineáris szektorcím kerül bele, és ezek alapján a betöltő program a boot-olás során közvetlenül a BIOS-tól lekérdezett geometria szerint alakítja ki a C/F/S címeket.

Tulajdonképpen nem értem, hogy miért nem ezt a megoldást használja alapértelmezésben a lilo. Ha valaki tudja ezt, vagy van, akinél a linear opció ellenére sem müködik a boot-olás, ossza meg velem a tapasztalatait.

Up Arrow
Tartalomjegyzék
Az Extended partíció Left Arrow