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

 ( trey | 2010. augusztus 29., vasárnap - 15:42 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

En inkabb azon gondolkoznek el, miert van jogosultsaga egy atalagos programnak oda irni.

--
http://bsdbased.com

Mert (winver >= vista)
? telepítéskor emelt jogkörrel fut a telepítő
: telepíteni csak rendszergazdai jogú accounttal lehet.

Szvsz. sudo apt-get install esetén is ugyanúgy lenne joga oda írni egy postinstall scriptnek.

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

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

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

RTFA: ezt szeretnék összeírni.

--
trey @ gépház

Gondolom a cikk nem született volna meg, ha nem tudnának már most néhány olyan szoftverről, ami oda szemetel.

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

+1

Én nem találgatnék, hanem dobnék neki egy levelet. Szerintem készségesen válaszolni fog.

--
trey @ gépház

Egy példa: Adobe csomag (Illustrator, Photoshop és társai)

Üdv,
Ned

Acrobat v. flash-player is "tarsai" csoport tagja? Valami konkret link az infodhoz?

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

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

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

Harmadik: virtualizáció.

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

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

Gyengébbek kedvéért: dualboot szvsz szívás. Kb. 6-7 éve volt az utolsó alkalom, hogy egynél több rendszert a gépen, ami nem virtuális.

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

Gazdaságosabb a dualboot folyamatos használat mellett egy olyan 15000 forintos gépen aminél kb. 10000 forint lenne a ram és proci bővítése...
- - - - - - - - - - - - - - - - - - - - - - - - -
Fejlődőképes hiperláma, és okleveles érdekfeszítő

Nekem még semmi bajom nem volt vele.

Arra azért jó a dual-boot, hogy ha a gépen nem megy valami hardver Linux alatt, akkor megnézem Windows-ban (a driver felrakása után). Ha ott megy, akkor legalább tudhatom, hogy nem hardver hiba és lehet vele próbálkozni Linux alatt is.

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.

Az eredmény az lenne hogy minden ilyen erőszakos program első dolga az lenne hogy kikapcsolja az általad elképzelt védelmet.

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...

Nyilván kell rá egy admin enable/disable flag, amivel az adminisztrátor tudja letiltani a működést. Ez lehet akár passwordös is, és akkor jöhetnek a túlbuzgó programok, próbálkozhatnak... :)

É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?

Ugyanonnan mint az amelyik "legálisan" akarja kikapcsolni. Te írtad:

"A program kikapcsolható lehetne, hogy az említett területek igazi tartalmát is lehessen módosítani."

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 :)

Az eredeti fölvetésedben nem részletezted hogyan is képzelted a kikapcsolhatóság megvalósítását. :-)

- 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!"..

vagy grub1-et? biztos bennem van a hiba, de betölti a rendszert:)
--
Dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5

"Normál esetben az GRUB és a GRUB2 is erre a lemezterületre telepít egyet a kulcsfontosságú összetevői közül."

"ahol ugyan a Stage 1.5 már véget ér, de előbbre, mint ahogy a core véget érne"

Lilo -t, na persze, critical fail.

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

Van egy ősöreg Bo szerverem, ami hibátlanul megy LILO-val.

Mondjuk csak 1 gépem van duál booton GRUB-bal, de azzal sincs hiba.

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

Azt hiszem kezdünk Windows-szerű problémákra Windows-szerű megoldásokat keresni, és az nem az lesz, hogy Lilo -t pakolunk. (értsd: eddig tudtuk hogyan kell egy fejbelőtt Grubot helyrehozni, az uborkanép viszont nem).

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

HA uborkanép alatt ubuntu felhasználókra gondolsz, akkor megjegyezném, ott sem mindenki síkhülye.

Vagy aki mégis, az már párszor elközösülte a grubját, és aki nem túlságosan síkhülye, az vissza is tudta állítani…
Gondolom a Lomtárból kell visszaállítani a törölt grub.loader fájlt, nem?

A cikk szerint a core.img-t írja felül (legalábbis egy részét) kérdés nélkül. Kizárt, hogy itt bármi is a lomtárba kerülne... :S Felülírt szektorokat marhára nehéz (ha egyáltalán sikerül) helyreállítani.

reménykedtem, hogy senki se veszi komolyan ☺

Bocs, nem vettem észre a szmájlit :P

Bocs, szórakoztatóbbnak tartottam orosz rulettezni, hogy valaki szóvá teszi-e? :P

Amúgy jó volt :D

Nem a Windows-zal van a baj, hanem a Windowra irt egyes alkalmazasokkal.

pontosan...engem az érdekelne, hogy mi a jópikuláért is kell akármilyen alkalmazásnak oda írni a bootloadereken kívül....

Mondok jobbat: külön minek boot manager? Van élet a BIOS után is.

Szerk: most látom, hogy nem azt írtam, amit akartam.

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

Mondjuk valaki nagyon okosnak és furfangosnak képzeli magát, csak a körülményekkel nincsen tisztában. (Vagy éppen nagy ívben tojik rájuk.)

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 ?

Programozó trehányságától függ. Elvileg nem lenne indokolt. Elvileg az sem, hogy valami oda szemeteljen.

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

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.

+1
--
CCC3

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ó.

Miért akarnának erre külön infrastruktúrát tartani? Miért ne használják a te erőforrásodat, ha az nem kerül nekik semmibe? Internet sincs mindenhol.

--
trey @ gépház

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.

Igen ezért van elmozdulás a felhők felé. Ott a szoftver bérlését gyerekjáték megoldani. A nagy testvér könnyebben szemmel tart.

Ezért mondom: GPL > all.

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

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

Igen, ugyanis nem az MBR-be piszkál bele.

A boot sector védelme erre a területre nem vonatkozik.

Ez valahol a boot sector és az első partíció kezdete közötti rész.

Mindenesetre nem szép dolog kéretlenül odafirkálni...

Esetleg leállnának ezzel a tevékenységgel, ha kiadna valaki egy "TRIAL MARK REMOVE AND GRUB2 RESTORE" programmal. Ha lenne egy elterjedt program, ami a trialok bejegyzését kitörli, akkor nem lenne értelme a fejlesztőknek azt piszkálni.

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...

Nemcsak kéretlenül nem szép oda firkálni...

De akkor ez a GRUB-tól éppannyira nem szép, mint a többiektől, nem?

Ugyanannyira. A probléma megbeszélése elment megint a "ki a hibás" felé. A blogbejegyzés nem arról szól, hogy a Windows programokat hibáztatja, hanem arról, hogy megoldást találjon az ilyen programok kikerülésére, azaz az egymás mellett élésre.

--
trey @ gépház

Pont ezért írtam...

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.

Wáháhá, ez nagy poén, de például tök király ha egy duálbútos cuccon újrarakod a grubot és mehet a wines demó telepítés végtelenszer! Pont ezért kell a lista, hogy tudjuk, mit lehet kijátszani!

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.

"szvsz GRUB is legalább annyira hibás"
Azért én a GRUB-nál több létjogosultságot látok az MBR-Gap turkálására, másrészről egy szimpla végfelhasználói program ami csak trialtime-validationre használja, legyen szíves megnézni, hogy ott mit ír felül...

+1

Egyetértek.

+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 keverjük a dolgokat! Azért valóban szól, hogy az MBR-t felülírja - de arra nem emlékszem, hogy azért is szólna, hogy az MBR gap-ba is írkálna...

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.

Magyarul a GRUB-ot lehet "környezetbarát" módon telepíteni multiboot rendszeren - akkor ezt kell tenni.

Értem.
Így érdemes a GRUB-ot a saját partíciójára rakni.

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.

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).

Speciel ez az a megoldas amit en is hasznalok, a LILOs korszak ota.

Érdekes, én ösztönből így telepítettem. Pedig nem is duálbutus.
--
Fight / For The Freedom / Fighting With Steel

"Master Boot Record és az első partíció közti szünetben helyezkednek el. "

A grubnak ott az MBR, abba irkáljon.
Semmivel sincs több joga ott lenni, mint a másolásvédelemnek.

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)

+1

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!

+1

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#Booting_GRUB_for_DOS_via_the_Windows_NT.2F2000.2FXP.2F2003_boot_manager
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

Vagy hogy azt a területet valahonnan mindig újraírja :P

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Ü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?

A GTP header a 449.-dik byte-tal indul.
Szerintem csak virusok irják felül azt a területet.:)

Szerencsére a /boot külön van...

Nálam is. :)

Azon gondolkodok, hogy ennek vajon mi köze a témához.

Gondolom az, hogy akár ide is lehet tenni, még ha a rendszer többi része "távolabb" is van...

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.