Egyes windowsos alkalmazások bootolásra képtelen állapotba hozzák a GRUB2-t

Címkék

A Canonical alkalmazásában álló Colin Watson tegnapi blogbejegyzésében arra hívja fel a figyelmet, hogy egyes Windows-ra írt alkalmazások bootolásra képtelen állapotba hozhatják a GRUB2-t. Watson szerint ez egy bug, amelynek során ezek a proprietary, Windows-alapú alkalmazások felülírnak bizonyos szektorokat, amelyek a Master Boot Record és az első partíció közti szünetben helyezkednek el. Ezt a rést nevezik "MBR gap"-nek is. Normál esetben a GRUB és a GRUB2 is erre a lemezterületre telepít egyet a kulcsfontosságú összetevői közül.

A GRUB-nál ez a Stage 1.5, míg a GRUB2-nél ez a komponens a "core" (core.img). A Stage 1.5 kevésbé kritikus összetevő és kisebb is, amint a core. Úgy fest, hogy a problémás Windows program(ok) oda ír(nak) a lemezre, ahol ugyan a Stage 1.5 már véget ér, de előbbre, mint ahogy a core véget érne. Éppen ezért jelentkezik ez a probléma a GRUB2-vel.

A problémás programok lehetnek olyan programok, amelyek például úgy jegyzik meg, hogy már telepítve voltak a gépre, hogy erre a lemezterületre tesznek egy jelzést. Hiába távolítja el a felhasználó a próbaverziós programot, majd telepíti újra annak érdekében, hogy ismét használni tudja, a jelzés rajta van a lemezen, így a program "tudni fogja", hogy azt már egyszer telepítették. Ezek a programok - amelyek jó példái a gyenge mérnöki munkának - nem ellenőrzik, hogy valami használja-e már ezt a területet és simán felülírják.

Hogy mi a gond ezzel? Az, hogy a nyílt forrású fejlesztők nem akarják, hogy az emberek rájuk nézzenek rossz szemmel, hq a fenti problémából adódóan bootolásra képtelenné válik a rendszerük. Csak nagyon kevés ember jár utána annak, hogy miért nem bootol a rendszere, viszont sokkal többen vannak, akik egyszerűen csak a fejlesztőket okolják azért, ha az operációs rendszerük nem bootol.

A probléma megoldásához kér Colin segítséget. Készített egy lépésről lépésre leírást, amelyet elvégezhet az, aki ilyen problémába szalad bele. Az így összegyűjtött információkkal Colin-nak lehetősége nyílhat arra, hogy megoldást dolgozzon ki a problémára.

A részletek és az e-mail cím itt.

Hozzászólások

Azért valami lista nem ártana, hogy mik ezek az egyes alkalmazások.

----------------
Lvl86 Troll

Ja, én is tudok egy megoldást, vagy kettőt:

- használj LILO-t,
- ne használj Windozt. :)

--
GPLv3-as hozzászólás.

azért ne kelljen már virtuális gépet futtatni, mert léteznek olyan programok, amik felülírnak egy rendszerbetöltőt. Az olyan mint kocsival menni a szomszédhoz. Vagy áttelefonálni a szomszéd szobába. Vagy baseball ütővel lecsapni egy szunyogot.
--
Dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5

Negyedik megoldás: kell írni egy windows drivert, ami "beül" a valódi fizikai diszk elé, és a fájlrendszereken kívüli területekre író/olvasó programok i/o-ját egy másik diszkterületre átirányíja. A program kikapcsolható lehetne, hogy az említett területek igazi tartalmát is lehessen módosítani.

Gondolom egy drivert nem egyszerű csak úgy szó nélkül kikapcsolni. Nem tudom mennyire lehet Windows szinten szabályozni hogy ki és hogyan férhet hozzá a driverekhez, de elképzelhetőnek tartok egy olyan megoldást hogy csak egy bizonyos tanusítvánnyal ellátott program piszkálhassa az adott illesztőprogramot.

Nem kikapcsolni kell (hiszen arról van szó, hogy valamennyi diszk i/o keresztülcammog rajta, és ha "védett" területre megy az írás, akkor azt egy fájlrendszeren belüli állományba rakja le. Nem véletlenül írtam, hogy cammog az adat, hiszen ebben az esetben minden egyes írási kérelemre lefut legalább egy összehasonlítás... Ja, és mi van akkor, ha olyan infót akar valamilyen sw oda bevésni, ami a boot-folyamat, illetve a driverek betöltődése előtt kell később? Lehet ilyen? Elképzelhető... Ekkor viszont csak meg kell tudni kerülni ezt a védelmet...

És ugyan honnan fogja tudni a program, hogy mit és hogyan kell kikapcsolni? Honnan jön rá, hogy az ott valami kikapcsolandó dolog? Belehardkódolják a driver nevét a programba? És ha telepítéskor adhatja meg a felhasználó, hogy milyen néven kerüljön fel a gépre? Akkor azt hogy találja ki?

Nade a program csak nem annyira intelligens, hogy
- elolvassa a doksit, hogy hogyan is kéne kikapcsolni,
- kitalálja, az adminisztrátor milyen nevet adott a device drivernek,
- kitalálja, az adminisztrátor milyen passwordöt adott meg a kikapcsoláshoz.

Az utolsót érzem a legütősebb érvnek :)

- A program nem fog neked doksit olvasni, de a programozó biztosan fog, ettől nem kell tartanod :)) És a legújabb bugokat javító verzióba ez a feature is be fog akkor kerülni :)
- Nem kell kitalálnia - ahhoz hogy bármi ilyet implementálhass rendszer közeli tereületn kell legyél, és az OS által biztosított lehetőségeken keresztül elérned ezt az igényed ( ergo mindezt a MS-nek kell megcsinálnia, hacsak nincs sok pénzed, hogy a saját drivered aláirattasd az MS-el :D )
- EZ viszont butaság.. Nem kell neki kitalálnia.. egyzerűen meg kell kérdeznie a felhasználót, hogy "A futtatáshoz rendszergazdai jogok kellenek. Biztosan futtatni akarod a programot? Ha igen add meg a jelszavad". aka UAC..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

nem vagyok nagy guru, kérdésem is lenne :)

Ha a windows külön fizikai hd-n van, a linux is külön hd-n saját mbr-el, de a bios-ban az van beállítva hogy a linux-os hd-ről boot-oljon fel a grub2 akkor gondolom nem írnak bele a windowsos programok, vagy igen ?

Na erről van szó. Igaz ez a legdrágább megoldás, de a legtisztább is.

Mindegyik oprenccer a saját loaderét szereti használni: Linux, BSD, Windoz. Ebből természetesen a Windoz a legfosabb, ami alá be se lehet mountolni a többi partíciót 3rd party megoldások nélkül.

Ezért szeretem én is külön vinyóra pakolni a különböző OS-eket és BOIS boot selectorát használni. Virtualizációt, mint programozó nem kedvelem.

--
GPLv3-as hozzászólás.

Ahha. Akkor ezért nem akart nekem egyik napról a másikra grub2-vel bootolni egy HP laptop, amin WinXP lakik?

Így 4 vagy 5 hónap távlatából jó tudni.

elég hülye megoldás.. miért nem küldenek alaplap vagy egyéb hardverről infót a neten keresztül a regisztrációhoz? mondjuk virtualizált rendszerben mindegyik kijátszható.

még jó pár éve nyomdai előkészítéshez használtam PDFSnake nevű app-ot, remek Acrobat-ba beépülő program. akkor még nem volt elterjedt a virtualizáció, és szerintem ez a progi is így csinálta, mert a demót frissen újra telepített gépre sem tudtam visszatenni. ezért tartottam ezt a megoldást azóta jobb ötletnek.

gondolom drága szoftverekhez megérné a plusz költséget, ami a regisztrációhoz kellene.

Egyes BIOS-okban van bootszektor védelem. Azokat is érinti ez a probléma?

Nem biztos, hogy ez leállítaná őket, már csak azért sem, mert nem feltétlenül a GRUB2 a jogos használója a területnek (hanem pl. egy másik betöltő vagy ennek más verziója).

Gondolom, a fejlesztők ezt találták a legeredményesebb megoldásnak arra nézve, hogy akár egy rendszerújratelepítést követően is képesek legyenek megállapítani, egy program telepítve volt-e már a gépen. Akár több módszert is együttesen alkalmazva.

Egyedül arra nem gondoltak, hogy lehet olyan betöltőprogram, amely - sokkal inkább jogosan mint ők - saját céljaira használná ezt a területet.
Bár úgy vélem, ugyanilyen alapon szerencsétlen esetben ezen programok "jelölői" is összeakadhatnak, de mindegy...

Egyes Windows-ra írt alkalmazások fejlesztői panaszkodnak, hogy a GRUB működésképtelen állapotba hozhatja az alkalmazásaikat, mivel az úgynevezett "MBR gap"-be helyez el információkat, anélkül, hogy ellenőrizné, hogy használja-e már valami a területet. Az IEEE ezért tegnap megalapította az MBR Gap Alliance-t, amely az MBR gap bitjeinek kiosztását fogja koordinálni a szoftvergyártók között.

Erdekes elgondolas volt az MBR Gapot felhasznalni, de mivel nincs szabvany ra, hogy odda tilos irkalni, vagy hogy minek kellene ott lenni. Igy szvsz a GRUB is legalabb annyira hibas, mint a tobbi kedves trukos masolas vedelmet haszanlo program.

+1

Semmi bajom a felhasználói programokkal, ha tájékoztatnak róla, hogy mit csinálnak telepítéskor. A GRUB figyelmeztet, hogy az MBR-ben lévő kódot cserélni fogja. Vajon a trial erről tájékoztat, vagy csak sunyiban ír oda, mikor te a Program Files-t adtad meg, mint telepítési cél.

Ne vegyétek teljesen készpénznek, amit írok, de...

...az MBR elvileg az első szektora a lemeznek, ami alapesetben 512 byte méretű. Igaz?

Tudomásom szerint a Windows XP boot sectora is ennél nagyobb méretű, talán 2 kB-os?

Ha ez így van, tulajdonképpen ez is használja az MBR gap egy részét. Rosszul gondolom?

A fentiek tudatában és azokat igaznak vélve elég merésznek tűnő feltételezés a kérdéses programok írói számára, hogy az ezen felül maradó területet soha, semmilyen körülmények között nem fogják használni... akár a Windows egy újabb verziójának hivatalos betöltője, akár bármi más.

Ha jól sejtem, és feltéve, hogy valójában az 1. "sávtól" kezdődik az első partíció, valamint egy sáv 63 sector, 1 sector pedig 512 byte, akkor nagyjából 32256 körüli byteról van szó, vagyis ~31 Kbyteról maximum.

Nyugodtan javítsatok. :)

javítalak:

az mbr, az első szektor, 512 byte.
ebben van a partíciós tábla (első része), meg a boot block, amit a bios betölt.
ennek annyi a feladata, hogy kikeresse az első bootolhatónak jelölt partíciót, betöltse annak a boot blockját, és elindítsa. ez elfér az 512 byte-ban, és os független.

az os-eknek az lenne a feladata, hogy a saját partíciójukba rakják a boot kódjukat - a windows ezt is csinálja!

a grub is használható így: csinálsz egy linuxos partíciót (mondjuk 100mb méretben), _oda_ telepíted az grubot (meg praktikusan a /boot partíciót): pl. root (hd0,0) setup (hd0,0), aztán ezt a partíciót nevezed ki bootolhatónak. se a windows nem fogja bántani, se más.
lehet a grubot úgy is felrakni, hogy root (hd0,0) setup (hd0), azaz az mbr-be rakja a saját boot blockját, és akkor kénytelen partíciókon kívülre rakni a 1.5-ös fázis tartalmát - na ez az, ami gáz.

Annak meg utána kéne néznem, mi rémlik a Windowssal kapcsolatban, emlékeim szerint nem csak az első 512 byte-ot foglalja/használja.

a saját partícióján azt csinál, amit akar, mellesleg én úgy emlékszem, hogy de, csak az első szektort használja, azon felül minden fájlokban van (konkrétan a boot loader az NTLDR-ben, utána pedig az tölt minden mást).

Szerintem: Egy "tisztességes" program a merevlemezre a fájlrendszer szolgáltatásait felhasználva ír. (Kivételt képeznek ez alól a merevlemezt tesztelő/buheráló programok, például egy particionáló program.) Az MBR és az első partíció közötti terület nem része a fájlrendszernek, így azt a fájlrendszer szolgáltatásaival nem lehet elérni. Egy átlagos felhasználói program ne irkáljon közvetlenül, az operációs rendszert kikerülve, a merevlemezre. Még akkor sem, ha demo változat. Semmilyen operációs rendszer alatt!

-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)

Multiboot-os gépen tehát célszerű MBR helyett a Linux boot, vagy root particiójának boot rekordjába telepíteni a GRUB-ot, oda már csak nem írnak a windows alatti programok.
--
Légy derűs, tégy mindent örömmel!

Alternatívaként lehetséges úgy Linuxot indítani, hogy nem piszkálunk hozzá a Windows BOOT szektorához.
http://grub4dos.sourceforge.net/wiki/index.php/Grub4dos_tutorial#Bootin…
Annyi trükk még volt vele, hogy nem tudott EXT4 fájlrendszert bootolni ezért csak a Linux partícióra telepített frissebb GRUB-ot töltöm be vele.
Tulajdonképpen leszedhettem volna teljesen a gyári Windowst, mert azóta, hogy ezt beállítottam el sem indítottam. Elég vacak anyagból csinálja az MS a matricát, mert már alig olvasható a Windows kulcsa.

mekkora feszt jelentene megoldani, hogy se a grub 1 se a grub 2 ne írjon oda innentől?

gondolom biztos többe minthogy összeírják a sok galád windows alkalmazást :)

No rainbow, no sugar

Üdv,

Valaki megjegyezte, hogy lehet inkább LILO-t használni.

A probléma egyébként már LILO-val és win98al is létezett, a windowst muszáj volt az első partícióra telepíteni, mert ha a Linux volt előrébb, akkor pár blokkot sikeresen felülírt belőle.

Furcsállom, hogy ennyi ideig tartott míg megtalálták újra a problémát :) Remélem azért találnak valami jó megoldást.

Az MBR gap terület hivatalból felhasználatlan terület és mint ilyen, a "senki földje". Persze ha senkié, akkor mindenkié - hiszen az alapállás, hogy más úgysem használja. A pofára esés abból van, amikor ezt többen is így gondolják, mert innen kezdve jön a mély döbbenet, hogy ki merészelt hozzá piszkálni az én eldugott kis adataimhoz... Így első körben a GRUB2 borul - helyre állítása után jó eséllyel a Windowsos proggy fog érdekesen működni, de nem probléma, mert a reinstall után menni fog - csak ismét a GRUB2 áll fejre... :-(

Megjegyzések:
- a GRUB2-nek mint rendszer betöltő cuccnak több létjogosultságát látom az MBR gap-ban, mint bármi más nem rendszer töltő stuff-nak. Ezzel együtt a nullát nagyobb számmal szorozva is csak nullát kapok - azaz a GRUB2-nek sem igazán itt van a helye. Szerintem.
- nem teljesen értem azokat a hozzászólásokat, amelyek azt mondják, hogy mielött ide a program bármit ír, ellenőrizze, hogy a terület nem használt. Ezzel az alapvető problémám - túl azon, hogy a GRUB2 sem(!) ellenőrzi (telepítsük _elöbb_ a kérdéses Windows programot és _utána_ a GRUB2-t! A GRUB2 az MBR felülírásért ugyan szólni fog - az MBR gap felülírásért nem és nyugodtan le fogja gyakni a Windowsos program által oda tett cuccost), hogy mi legyen az ellenőrzés alapja? Ez hivatalból nem használt terület, sehol semmi nem vezet arról nyilvántartást, hogy ez haszánaltba lett-e véve vagy sem. Innen kezdve? Jelezném: nem elfogadható válasz, hogy ha csak 0 byte-ok vannak ott, akkor nem használt. Ha valaki feltett Linuxot, GRUB-2-t, majd akár megvált a Linuxtól, akár inkább LILO-ra váltott, az MBR gap felszabadult - de tuti nem állt vissza a tisztán 0 byte-os állapot.
- azt csak nagyon halkan jegyezném meg, hogy ha valaki olyan perverz, hogy _kézzel_ adja meg a partíciós határokat és az első partíció közvetlenül az MBR után a 2. szektoron kezdődik, akkor azzal mi van? Mert az oké, hogy _szokásjog_ a partíció első szektoron kezdése - de _nem_ _kötelező_! Itt hova kerül a stage 1.5 vagy a core.img?! Itt hova ír rejtett adatokat a Windowsos proggy?! Legyünk optimisták és tegyük fel, hogy megtörténik az ellenőrzés, hogy van-e MBR gap és elegendő-e a mérete arra, amire nekünk kell. (Jelzem: nem vagyok meggyőzve arról hogy történik ilyen ellenőrzés, de ha nem történik, akkor az automatikusan az első partíció tönkretételét jelenti!!!) (Azt is jelezném, hogy _régi_ winyó esetén nem biztos, hogy lesz egy sávon 63 szektor! Van olyan winyó is, ahol csak 15 szektor van egy sávon - ott az MBR gap súlyos kilobyte-okkal lesz kisebb!) Szóval ilyen esetben hova is íródik az MBR gap-ba szánt adat?!

Mi a helyzet a GPT-vel?

Az első szektorban a legacy MBR van, de azt közvetlenül a GPT Header követi.

Mi történik ha a Windows-os alkalmazás felülírja azt a területet?

Szvsz a probléma lényegét tekintve két külön dologról van szó.
Nem az a baj, hogy az init fájl, vagy a kernel sérül, hanem az, hogy a bootloader boot recordon kivül található részei felüliródnak (ha az a master boot recordba lett telepitve).

A probléma nem orvosolható /boot partició létrehozásával, csak a kissé fentebb leirt módon. comment/1105849

Szóval, szerintem teljesen lényegtelen, van e /boot particiód, vagy nincs. Nem itt van a kutya elásva.

Valaki javitson ki, ha tévedek.

Persze, de ha megvan ez a partíció, a probléma elkerülhető, ha ide kerülnek az adatok, ahogy fentebb is írták.

Ellenben az okozhat problémát, ha ezek az adatok túl hátul vannak a merevlemezen, ezért szoktak még egy boot partíciót is csinálni a lemez elejére.
Tehát szerintem az orvoslás szempontjából fontos lehet, de nem elégséges a /boot partíció megléte.

Amúgy ha jól sejtem, elsősorban azt szeretnék megoldani, hogy a Grub olyan helyet találjon magának, amit ezek a programok nem használnak, így a továbbiakban azt ő használhatja.

Erre sok esélyt nem látok. Legalábbis önmagában a "gyártók" nem fogják megmondani, hogy pl. a 7314. byte 3. bitjét használja, mert ezzel együtt azt is elmondja, hogy lehet megszabadulni a jelölésétől.

Kötöm az ebet a karóhoz.:)
A topic szempontjából lényegtelen, hogy van-e /boot, vagy nincs.

ha csak /-od van a win particioja mellett, akkor is orvosolható a probléma. Tehát (az én észjárásom szerint) "lényegtelen, hogy van-e /boot, vagy nincs". Nyilván a megoldás során "túl hátul lévő adatok" esetén könnyebb dolgunk van.

De akkor sem releváns.

Ha csak / van, könnyebben előfordulhat, hogy BIOS limit miatt a fenti módon nem orvosolható a probléma.
Itt segíthet a /boot külön partíciója.

A túl hátul lévő partíció esetén arra gondoltam, hogy pl. egyes BIOS-ok képtelenek az 1024 cylinder feletti területről indítani a BOOT folyamatot, így ez ebben az esetben hátrány.

Jelen probléma megoldása az lenne, ha kiderülne, ki, hol helyez el ilyen extra információkat az MBR és az első partíció közötti "résben".

Nekem ezt többször eljátszotta az új ubuntu úgy, hogy win el sem volt indítva telepítés és update között. Arra tudok csak gondolni, hogy megzavart a mellette levő reiserfs még akkor is, ha ő maga ext4-en volt.