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.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
En inkabb azon gondolkoznek el, miert van jogosultsaga egy atalagos programnak oda irni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Azért valami lista nem ártana, hogy mik ezek az egyes alkalmazások.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
RTFA: ezt szeretnék összeírni.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Én nem találgatnék, hanem dobnék neki egy levelet. Szerintem készségesen válaszolni fog.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Egy példa: Adobe csomag (Illustrator, Photoshop és társai)
Üdv,
Ned
- A hozzászóláshoz be kell jelentkezni
Acrobat v. flash-player is "tarsai" csoport tagja? Valami konkret link az infodhoz?
- A hozzászóláshoz be kell jelentkezni
Ja, én is tudok egy megoldást, vagy kettőt:
- használj LILO-t,
- ne használj Windozt. :)
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Harmadik: virtualizáció.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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ő
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az eredmény az lenne hogy minden ilyen erőszakos program első dolga az lenne hogy kikapcsolja az általad elképzelt védelmet.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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... :)
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Az eredeti fölvetésedben nem részletezted hogyan is képzelted a kikapcsolhatóság megvalósítását. :-)
- A hozzászóláshoz be kell jelentkezni
- 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!"..
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"Normál esetben az GRUB és a GRUB2 is erre a lemezterületre telepít egyet a kulcsfontosságú összetevői közül."
- A hozzászóláshoz be kell jelentkezni
"ahol ugyan a Stage 1.5 már véget ér, de előbbre, mint ahogy a core véget érne"
- A hozzászóláshoz be kell jelentkezni
Lilo -t, na persze, critical fail.
--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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"
...
- A hozzászóláshoz be kell jelentkezni
HA uborkanép alatt ubuntu felhasználókra gondolsz, akkor megjegyezném, ott sem mindenki síkhülye.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
reménykedtem, hogy senki se veszi komolyan ☺
- A hozzászóláshoz be kell jelentkezni
Bocs, nem vettem észre a szmájlit :P
- A hozzászóláshoz be kell jelentkezni
Bocs, szórakoztatóbbnak tartottam orosz rulettezni, hogy valaki szóvá teszi-e? :P
- A hozzászóláshoz be kell jelentkezni
Amúgy jó volt :D
- A hozzászóláshoz be kell jelentkezni
Nem a Windows-zal van a baj, hanem a Windowra irt egyes alkalmazasokkal.
- A hozzászóláshoz be kell jelentkezni
pontosan...engem az érdekelne, hogy mi a jópikuláért is kell akármilyen alkalmazásnak oda írni a bootloadereken kívül....
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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 ?
- A hozzászóláshoz be kell jelentkezni
Programozó trehányságától függ. Elvileg nem lenne indokolt. Elvileg az sem, hogy valami oda szemeteljen.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
--
CCC3
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egyes BIOS-okban van bootszektor védelem. Azokat is érinti ez a probléma?
- A hozzászóláshoz be kell jelentkezni
Igen, ugyanis nem az MBR-be piszkál bele.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Nemcsak kéretlenül nem szép oda firkálni...
- A hozzászóláshoz be kell jelentkezni
De akkor ez a GRUB-tól éppannyira nem szép, mint a többiektől, nem?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Pont ezért írtam...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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...
- A hozzászóláshoz be kell jelentkezni
+1
Egyetértek.
- A hozzászóláshoz be kell jelentkezni
+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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Magyarul a GRUB-ot lehet "környezetbarát" módon telepíteni multiboot rendszeren - akkor ezt kell tenni.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Speciel ez az a megoldas amit en is hasznalok, a LILOs korszak ota.
- A hozzászóláshoz be kell jelentkezni
Érdekes, én ösztönből így telepítettem. Pedig nem is duálbutus.
--
Fight / For The Freedom / Fighting With Steel
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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- A hozzászóláshoz be kell jelentkezni
Ü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.
- A hozzászóláshoz be kell jelentkezni
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?!
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A GTP header a 449.-dik byte-tal indul.
Szerintem csak virusok irják felül azt a területet.:)
- A hozzászóláshoz be kell jelentkezni
Szerencsére a /boot külön van...
- A hozzászóláshoz be kell jelentkezni
Nálam is. :)
- A hozzászóláshoz be kell jelentkezni
Azon gondolkodok, hogy ennek vajon mi köze a témához.
- A hozzászóláshoz be kell jelentkezni
Gondolom az, hogy akár ide is lehet tenni, még ha a rendszer többi része "távolabb" is van...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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".
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni