Hibás MBR mi módon befolyásolhatja az eszközökről való bootolást?

Adott egy HP Pavilion G6 laptop. Erre sikerült feltelepülnie a Windows 7 mellé a SpyHunter saját mini Linux alapú oprendszerének és a grub4dos-nak. A probléma, hogy nem indul el egyik sem, sérült MBR-re utaló hibaüzenetet dob.

Gondoltam simán helyrerakom egy CD, vagy pendrive segítségével, de egyszerűen nem tudom bootolásra bírni, automatikusan a HDD-ről bootol. Megkérdeztem egy szervizes embert is, ő is tapasztalta már egyszer ugyanezt, szintén egy HP Pavilion laptopon (sérült MBR után nem volt hajlandó másról bootolni, hiába volt jól beállítva a boot sorrend és kikapcsolva a fast boot).

Mégis miért van ez? A dolog mikéntje érdekelne. Hogyan lehetséges ez?

Hozzászólások

"Hogyan lehetséges ez?"

BIOS bug.

Az MBR alatt érthetjük a diszk legelső szektorát (512) bájt, illetőleg csak magát a tényleges boot kódot, ami ennek az 512 bájtos szektornak az első 440 vagy 446 bájtja.

Ha tehát csak a boot kódot szeretnéd kinyírni, akkor:
dd if=/dev/zero of=/dev/sda bs=446 count=1

Ha az egész szektort szeretnéd kinyírni (VIGYÁZZ!!! Ebben benne van a partíciós tábla is!!!) akkor
dd if=/dev/zero of=/dev/sda bs=512 count=1

(Feltételezvén, hogy a diszket /dev/sda-nak hívják)

Működő MBR kódot találsz a SYSLINUX csomagban. (mbr.bin és társai)

Igen, ezzel tényleg csak az MBR kódot írod felül. Az is egyfajta adatvesztés, nem? :)

Hogy a Windows 7 telepítő mit és hogyan képes helyreállítani, azt passzolom.

(Viszont, ha a Windows egy aktívnak megjelölt partícióban van, és az első 446 bájtba beleírsz egy működő MBR kódot - lásd feljebb - akkor annak be kellene bootolnia. Már persze, ha a Windows úgy egyébként "szalonképes" állapotban van.)

A régi szép időkben a BIOS feladata csak annyi volt, hogy a boot média első szektorára (MBR) adja a vezérlést. Ha ott volt valami indítható kód, akkor lőn boldogság.

Manapság azonban az alaplapgyártók és BIOS-készítők szeretnek néha túlságosan is okos lenni.

Az egyik legtipikusabb dolog, hogy a BIOS megnézi a diszken a partíciós táblát, és csak akkor hajlandó az eszközről bootolni, ha ott talál egy aktívnak megjelölt partíciót. Aztán, ha ott éppenséggel nincs MSDOS-kompatibilis partíciós tábla, akkor szívás van. A legutóbb egy Intel szerver alaplapon kellett egy "kamu" partíciós táblát csinálnom, benne egy boot flaggel ellátott 1 cylinder hosszú partícióval. (A diszken egyébként BSD disklabel volt)

Hasonló szívás szokott lenni GPT esetében, bár ott legalább van egy "protective" MBR partíciós tábla, amiben a kamu partíciót aktívvá lehet tenni, hogy meglegyen a BIOS-nak is a boldogság.

Az utóbbi idők egyik legnagyobb szívása a 2-3 évvel ezelőtti, "Hybrid EFI" néven futó BIOS-szal rendelkező Gigabyte alaplapok voltak, ahol GPT esetében a BIOS mindenáron próbált megtalálni valamit a diszken, ami nem volt ott, és ez abból állt, hogy boot előtt az első szektortól az utolsóig végignyalta a diszket. Ez diszk mérettől és sebességtől függően 5-90 percet(!) vett igénybe. Hab a tortán, hogy ha Windows alól hoztam létre a GPT partíciós táblát, akkor a probléma nem jelentkezett, tehát nyilván a Windows "odatesz" valami flaget, amit mondjuk a "parted" nem. Hogy mi ez, arra még nem sikerült rájönnöm, igaz, túlzottan nem is kerestem.

Ja, és a legszebb, hogy mindezt nem csak a tényleges boot diszk esetében, hanem az összes, rendszerben lévő merevlemez esetében. Magyarul, ha a működő oprendszer mellé bedugtam másodiknak egy GPT-s adatdiszket, akkor nem bootolt a gép, csak másfél óra diszk-darálás után...