Üdv!
Egy régóta fennálló probléma mibenlétét szeretném megérteni, illetve keresem rá a megoldást. Biztos van, aki jártasabb a témában.
Tehát:
Van egy MSI B250 PC MATE alaplap, amit teljes egészében UEFI módban használok, nincs semmilyen legacy biosos bootolgatás.
Van egy 120GB-os M.2 SSD, amin van egy /boot (EFI), egy / és egy adatpartíció. Tehát ide van a Manjaro is feltelepítve. És van egy merevlemezes partíció, amire pedig a Windows 10 van felrakva, hogy ha kéne szkennelnem negatívokat (fotós vagyok) vagy photoshopolni, akkor legyen. Azonban valamiért telepítéskor a Windows bootloadere is beköltözött az SSD-n lévő /boot -ba. (milyen hülye voltam, hogy nem szedtem ki telepítés előtt...)
Ezzel az a probléma, hogy egy nagyobb Windows frissítés, netán egy UEFI frissítés után a Manjaro Linux bejegyzés nemes egyszerűséggel eltűnik a választható boot opciók közül és azt csak egy Windows alatt lefuttatott script segítségével tudom helyreállítani. Ez éppenséggel működik tökéletesen, csak nagyon bosszantó és számomra érthetetlen ennek a problémának az oka.
Van ötlete valakinek, hogy mi okozza ezt? Valószínűleg a fájlok nem tűnnek el, csak az UEFI nem látja ezt, a script lefutásáig.
A script így néz ki:
bcdedit /set {bootmgr} path \EFI\manjaro\grubx64.efi
bcdedit /set {bootmgr} description "Manjaro Linux"
A script lefutása után az UEFI ismét látja a boot bejegyzést, a GRUB pedig eleve nem is törlődött, csak a bejegyzés tűnt el. Hogy lehetne kiküszöbölni egy ilyet a jövőben?
Hozzászólások
Most csináltam Win 8.1 és Arch Linux kombót hasonló módon, csak itt én raktam a windows boot partíciójára a linuxot. Bár még nem frissítettem a windowst és nem tűnt el, de ez a script egyszerűbb, mint egy live boot és visszaállítás. Külön boot partíciót meg szerintem hiába csinálsz, ha nem veszi fel a windows automatikusan a linux indítóját, akkor mindegy.
Egy Win 7 és linux esetén úgy csináltam, hogy két partíción volt a két indító, de ott nem álítódott el egyszer sem.
--
Dell Latitude 5480, Arch Linux & Xfce
Ezzel az (U)EFI-vel úgy vagyok, hogy kellett ez, mint sántának a hátára púp. Egyfelől nem minden gépen szabványos az implementációja, másfelől szerintem a Windows agresszíven átrendezi az egészet frissítéskor, aztán konfigolhatod vissza. Azt mondanám, legyen natív Linux azon a gépen, virtuális gépben pedig Windows, ha muszáj, de inkább ne, mert minek.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
+sok.
windowsnak virtuális gépen a helye. natív vason ha van mellette egy normális oprendszer akkor csak káoszkodik.
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
Én is virtuális gépben tartom a wint.
---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...
És komolyan megveszitek hozzá a "dobozos" / Pro listaár: 77.690.- Ft / licencet??? (:)) - Mivel nincs tapasztalatom, és talán többünknek sem, - Az MS mennyire hagyja háborítatlanul, azaz aktiválva a virtuális gép frissítésekor, esetleg más rendszerre mozgatáskor a (az akár "dobozos"..!) Wint? (Mert ha "snap"-ből indul, az elég korlátos tud lenni..)
Kis google-fu tudással össze lehet hozni ezt különösebb probléma nélkül. :)
Mondjuk adott egy fizikai gép, teszem azt egy laptop a megfelelő win licenc-el, akkor ezzel a kis script-el megoldhatod, hogy a Windows virtualizáltan fusson, úgy mintha a valódi hardveren futna - nincs aktivációs probléma. Lényegében a fizikai gép acpi slic tábláját 'eteti' meg a virtuális géppel.
Olvasnivaló itt: https://glemsomtechs.blogspot.com/2018/07/acpi-slic-in-virtualbox.html
Nem teljesen értem a problémát. Raktam már Windowst dualbootban külön HDD-re, külön SSD-re, most is mindhárom gépemen van Windows dual-bootban Ubuntu mellett. Pont Photoshopnál vagy videószerkesztésnél nem mindegy, hogy natívan fut-e vagy sem, főleg ha nem akar valaki GPU-passthrough-val próbálkozni mert mondjuk nincs szabad 5-10 órája ilyenekkel berhelni.
Ahogy én használom: GRUB-hoz nem nyúlok, nincs GRUB menüm, alapból betölt az Ubuntu, mindegy merre (másik HDD/SSD-n, vagy csak partición) van a Windows. Ha külön Windows kell, UEFI menüből bebootolom. Ez akkor is működik, ha a Windows bitlockerrel van titkosítva és GRUB-ból nem tud bebootolni.
szerk.: látom lentebb írtad, hogy egyes gyártók rosszul kezelik az UEFI-t. Velem ez még nem jött szembe, olyan persze már volt, hogy a Windows berakta magát felülre egy frissítés után, de "BIOS"-ban visszaraktam az Ubuntut elsődleges boot bejegyzésnek és hónapokig ment tovább gond nélkül. Kisebb Windows frissítések meg nem is nyúltak hozzá.
Nem meglepő, a Windows így szokott viselkedni.
Régen, amikor még volt dual bootos gépem, külön partíción volt a Linux és a Windows. A Win, amikor valami miatt felülírta az MBR-t, nem törődött esetlegesen létező más oprendszerekkel. Számára ő a fontos és kész.
A Linux meg végignézte, hogy mik vannak, megtalálta a Windows-t is és betette a választható opciók közé.
Akkoriban Win telepítés után Linuxot live CD-ről újra kellett indítani, és az MBR-t visszaállítani.
Az UEFI-s dologkat nem ismerem, de ennek alapján azt feltételezem, hogy nem te csinálsz valamit rosszul, csak ugyanaz történik, kicsit másképp.
Amúgy a leírásból úgy tűnik nekem, hogy a windows boot managerét használod, és abból lehet kiválasztani a linuxot.
Nekem régebben jobban bejött az, hogy a linux boot managerét használtam, amiből a windows-t ki lehetett választani. Fogalmam sincs, hogy ez megoldaná-e a problémádat, de esetleg egy próbát megér. (Ha egyáltalán jól értelmeztem azt, amit írtál és tényleg ez a helyzet).
A baj az, hogy van alatta egy réteg. Az (U)EFI bejegyzés alapján indul egyáltalán a Grub. Tehát bejegyzed, hogy induljon a Grub, választhatsz is a Windows és a Linux között, mert tudod jól konfigurálni. A gond azzal van, hogy egy Windows frissítés alkalmával a Windows jegyzi be magát elsőként az EFI boot-ba, s örülhetsz, ha csak ez történik, s a Grubot indító bejegyzést nem törli. Onnantól kezdve hiába minden, ott van a Grub, de az EFI közvetlenül a Windows-t indítja, mintha nem is lenne más.
Tehát az a probléma, hogy EFI - ha úgy tetszik, BIOS - szinten már van egy bootmanager, ami megelőzi a Grubot, s ebbe a Windows pofátlanul és agresszíven módosít, teszi magát első helyre. Sőt, erre sokszor segítenek az alaplap gyártók a nem szabványos EFI implementációval.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ahogy a kolléga írta.
Részletesebben:
Van egy UEFI boot partíció. UEFI esetén erre szükség van. Egy FAT32 formátumú partíció, kb 500MiB és minden UEFIs rendszer ide rakja a rendszertöltőjét. A Windows a saját Boot Managerét, a Linux a Grubot.
Mármost magában az UEFI-ben nem úgy zajlik a bootolás, mint MBR esetén, hogy az adott merevlemezre célzol, aminek van egy boot szektora és onnan tölt be a rendszer, hanem az UEFI érzékeli, hogy az adott diszk boot partícióján milyen bejegyzések vannak és ezek alapján maguknak az oprendszereknek a lehetőségeit kínálja csupán fel. Aztán a szokott módon beállíthatsz egy boot sorrendet. Ez nekem alapból a GRUB, ami amúgy megjeleníti a Windowst is, de fordítva nem: A Windowsé nem jelenítené meg a Linuxost.
Mármost egy nagyobb Windows frissítés (pl új build) után a Manjaro Linuxos bejegyzés nemes egyszerűséggel törlődik. Vagy pl a minap frissítettem az UEFI-t és szintén eltűnt a linuxos bejegyzés. Csak azt veszed észre, hogy automatikusan a Windows bootol és kész.
A vicces az, hogy a Windows saját installerében, ha particionálsz és csinálsz egy X méretű partíciót, a rendszer jó eséllyel beszúr neked elé egy kb 500MB-1GB körüli partíciót, mint "System Reserved", ami valójában épp az EFI boot partíció. Ilyet a Vista óta csinál minden windows. Ha először Windowst, majd Linuxot telepítesz, akkor fasza, mert a Linux okos és megadhatod, hova települjön a rendszertöltő, hol legyen a /boot. A windows meg kiválaszt valami neki szimpatikusat, mint egy parazita önkényesen beköltözik és szarik a világba. Gusztustalan egy oprendszer, by-design. Ha nem lenne rá feltétlen szükség, nem engedném éles hardverre. Csak sajnos a Core i3 kicsit kevés egy rendes virtualizáláshoz az Intel HD Graphics-al ellentében. Amíg desktopon nekem ez teljesen kielégítő, addig virtuális gépben édeskevés. Főleg ha 16Mpix-eles fotókat dolgozok ki. :(
Amúgy tök jó az UEFI-s rendszeröltés, fullHD-ban megy meg baromi gyors így SSD-ről, stb, csak a Windows, mint mindig, most sem játszik szépen és nagyon bosszantó, hogy bármikor megfingathatja a fő oprendszeremet.
Manjaro Linux + KDE Plasma
Ilyen miatt egyébként nem lehetne valamit indítani a Microsoft ellen? Míg más operációs rendszer észlel maga mellett minden, már korábban telepített rendszert, addig a Windows ezeket teljesen figyelmenkívül hagyva teleszemeteli a MBR-t, felülírva mindent ami addig ott volt. Én is sokat szívtam anno olyan gépekkel, amiken Linux volt, de szükség volt egy Windows-ra is mellé, és akkor lehetett GRUB-ot javítani.
---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
Ők csak megjavítják a gépedet, hogy probléma nélkül induljon a Windows, ha a trehányul Linuxszal előtelepített gépre tettél egyet. :) Hiszen nyilván azért vetted Linuxszal a gépet, mert az adott hardware csak úgy volt elérhető a boltban.
Érted már? ;)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Sajnos semmi nem gátolja őket benne. Nem lehet kötelezni őket, hogy több rendszert támogassanak egy gépen. Gerinc meg nincs bennük annyi, hogy megtegyék puszta jóindulatból. Egy normális megoldás van amit már itt többen is írtak: natív linux és VM Windows vagy persze only windows.. de az vessen magára. :)
---
return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);
A probléma okát alapvetően itt látom: teljes egészében UEFI módban használok, nincs semmilyen legacy biosos bootolgatás.
Alapvetően nincs vele baj. A Windows működésével annál inkább...
Én nem vagyok híve a "használjunk 40 éves technológiát" alapelvnek, nem azért van bleeding edge disztróm.
Manjaro Linux + KDE Plasma
én azt mondom hogy ha van egy negyven éves, kipróbált-bejáratott technika, akkor az ostobaság netovábbja egy újat szabványosítani egy nem létező igény kielégítése végett.
kicsit elvonatkoztatva a konkrét kérdéstől: mi az a _felhasználói_ igény amit az uefi kielégít és nem volt rá már eddig is egy jól bevált megoldás? komolyan érdekelne.
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
Azzal a bejáratott technikával az a baj, hogy egyetlen szektornak is csak egy része lenne a boot kód, az a talán 440 byte pedig finoman szólva elég kevés még akkor is, ha BIOS hívásokra támaszkodhatunk. Így aztán kell további hely partícionálatlan területen, amellyel meg az a baj, hogy mivel senkié, így mindenkié. Azaz, ha a rendszertöltőről azt mondjuk, teheti magát oda, akkor bármi más is, s ez a bármi más teheti majd indíthatatlanná a gépet. Szokásjog alapján működik, nem pedig specifikáció, szabványok miatt.
Ettől függetlenül én sem szeretem, ha érthetetlenre bonyolítanak valamit. Az RS232-n sincs tápfeszültség, az eszköz nem azonosítja magát, a sebesség is lehet eltérő, s akkor baj van, viszont RS232-t implementálni könnyű. Ezzel szemben az USB átgondolt, mindent (is) tud, viszont a teljes protokoll implementálása igen goromba, mezei halandó kész library-kat használ. Jobb nem tudni, hogyan működik.
Az előbbi csak egy másik példa volt. Igen, számtalan gondja van az MBR-nek, az RS232 kommunikációnak is, de legalább egyszerűek, és ez egy igen vonzó előny.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Én még csak lilo-t használtam, de nem tudok róla, hogy a [maste]boot-rekordon (stage1) és a saját map-fájlján (stage2) kívül máshová is települne.
Boldogult úrfi koromban próbálgattam, hogy hová lehet tenni a stage1-et (boot=): floppy boot sector (nem WinDos fájlrendszer esetén); HDD-MBR; primary partíció boot-sector (nem WinDos fr); extended partíció boot-sector; logikai partíció boot-sector (nem WinDos fr).
Ez így ment addig, míg a mostani laptopomon (Samsung RV511HU), azt nem mondta a Windows 7, hogy őtet a lilo ne indítsa, mert az sérti az ő lelki csipkéit. (Nem is a legelején, hanem az első néhányezer rendszerfájl betöltése után.) Hát akkor előre a fejlődes útján, EasyBCB to the rescue. (Szerk: de lehet, hogy EasyBCD az igazi neve, csak én vagyok vaksi.)
Úgy tudom, a liloval az a baj, hogy nem ismeri a filerendszert, így ott - szerintem, de javíts ki, ha nem mondok igazat - követelmény, hogy címfolytonos legyen az adott file a filerendszeren. Ha fragmentálódna a stage2, abba szerintem a lilo belebukna.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
> Úgy tudom, a liloval az a baj, hogy nem ismeri a filerendszert,
Igen, pont ez a célja és értelme, hogy ne kelljen egy minikernelt beletenni egy bootloaderbe...
Nálam most ilyen a /boot/map:
Ezek szerint ez a 20KB-t egybefüggően helyezkedik el a diszken, a stage1 tudja, hogy mely abszolút szektorpozíciókon van, és be tudja tölteni a BIOS lba-s hívásaival.
Én ezt értem, csak ez rétegeken való átnyúlás. Mi van, ha egy filerendszert úgy implementálnak, hogy nagyobb címektől kisebb felé helyezkedik el a file, vagy random címeken? Most tekintsünk el ennek értelmetlenségétől. A fragmentálódás viszont valós veszély, illetve az, hogy a stage2-t innentől kezdve tilos másolni. Például egy defragment utility simán elmásolhatja fizikailag más helyre úgy, hogy logikailag nem mozdul, ugyanabban a könyvtárban marad.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nagyon igaz, olyan fájlrendszerre nem tehetjük, ahol a fájlok kifejezett felhasználói kérés nélkül elmozdulhatnak.
Sőt, ahogy így visszagondolok, a külön kicsi /boot-partíció gondolata már akkor megvolt, amikor az (u)efi-t kitaláló tudósok még egyetemre jártak; pl: http://forum.index.hu/Article/viewArticle?a=45698186&t=9028250
Amúgy a lilo is megtehetné, hogy ismer egyetlen filerendszert, de csak egyet. Akármennyire is korszerűnek mondják ezt az UEFI csodát, egy huszáros megoldással oldották meg, hogy kötelező elöl egy FAT32, ebben vannak az indításhoz szükséges file-ok. Az, hogy nem naplózó filerendszer, senkit sem érdekel.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
jogos amit leírtál, viszont lássuk be a boot szétbaszását a /boot/EFI partíció se zárja ki. én legalábbis többször láttam olyat hogy az UEFI boot baszódott el, jellemzően persze a windows önkényes "rendszerhelyreállító" frissítései során mint hogy a legacy boot akadt volna be, bár egy szar oprendszerrel ugyebár tudjuk hogy semmi nem lehetetlen.
ami a szokásjogot illeti, az UEFInek bár van specifikációja, mégis hány olyan esetet tudunk amikor azért nem működik valami mert valamelyik gyártó a fejébe vette hogy ő majd jobbantudja.
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
+1
Én is jobban tartok az UEFI-től. Az alap felállás az, hogy a nem szabványos UEFI implementációval megáldott Acer ES1 notebook-omra telepítek egy Fedorát, akkor miután elkészült, nem indítható el a gép. :) Az elején levert a víz, hogy akkor hogyan tovább, vagy ez tégla, különösképp, hogy a secure boot miatt nem is lehet bármit csak úgy elindítani, de amióta tudom, mit kell csinálni, már nem aggódom. A titok nyitja, hogy az EFI indítójában csak "Linux" és "Windows" nevű bejegyzések szerepelhetnek, minden mást - pl. "Fedora" - ignorál a rendszer, mintha ott sem lenne.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Acert nem vásárolunk. Mondd utánam: a-c-e-r-t n-e-m v-á-s-á-r-o-l-u-n-k! :D
LOL :DD
Ennek ellenére nagyon elégedett vagyok vele, csak ki kellett ismerjem a nyűgjeit. Az elején szivatott, de már jó ideje uralom a helyzetet. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nálam a "nem lehet a biosba belépni, csak ha háromszor egymás után kikapcsolod a gépet a boot folyamat közben" c. faszságukkal örökre elvesztettek. Ez az a szint, amit konkrétan büntetni kéne, az illetékes döntéshozó nevelő célzatú fizikai inzultálásával (lásd még: fa testápoló). Abból talán tanulna az illető... (nobody fucks with the jesus)
Engem beenged. Lehet, hogy valaha valamit elgomboltak, de gondolom, náluk sem állt meg az élet, kijavíthatták már.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ez volt a dokumentált, hivatalos belépés módja. Ez nem bug, hanem feature. Nehogy véletlenül belépjen a paraszt, és esetleg elrontsa a gépet...
Na, ezzel viszont nem találkoztam. Nyomok F2-t, aztán beenged.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
kicsit elvonatkoztatva a konkrét kérdéstől: mi az a _felhasználói_ igény amit az uefi kielégít és nem volt rá már eddig is egy jól bevált megoldás? komolyan érdekelne
1) egynél több oprendszer értelmes támogatása a bios/uefi oldaláról
2) a boot loader számára egy _értelmes_ hely biztosítása (a basszuk bele a boot loadert az mbr utáni random reserved szektorokba, ahol aztán random módon felülbasszák egymást, az kurvára nem értelmes)
3) emberi sebességű bootolás (nézd meg, hogy egy brand szerver biosos bootolásából hány perc, amíg eljut egyáltalán odáig, hogy az mbr-t betöltse!)
4) a gyárilag beégetett támogatással rendelkező eszközökön felül más, drivert igénylő hw-ekről/protokollokkal történő bootolás (pl. iscsi hálózaton keresztül)
5) ip stack a biosban (pl. tcp/ip alapú bootoláshoz, tcp/ip alapú firmware update-hez)
Ebből amúgy a 3) az, amit még a mezei paraszt is észlel. Amikor 8sec alatt be tud bootolni egy modern os ssd-ről, akkor nagyon látványosan észrevehető, hogy egy buta laptop (amiben azért elég mérsékelten nőhetnek új hw elemek) is elszüttyög fél-egy percet a bootolás előtt legacy módban.
Na nekem az a fél-egy perc kb 3 másodperc mielőtt bootolná az ssd-ről a rendszert, pedig legacy bios van a laptopon.
nekem konkrétan az UEFI boot sokkal lassabb volt, mondjuk az Acer híres a szar implementációiról
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
1) egynél több oprendszer értelmes támogatása a bios/uefi oldaláról
IMO az alaplapnak nem feltétlenül kell oprendszert indítania. a bootloaderek erre vannak kitalálva, ne akarjunk már mindent az alaplapba erőszakolni.
2) a boot loader számára egy _értelmes_ hely biztosítása (a basszuk bele a boot loadert az mbr utáni random reserved szektorokba, ahol aztán random módon felülbasszák egymást, az kurvára nem értelmes)
ezt őszinténszólva nem látom be miért lenne érdemi szempont. a probléma ugyanúgy fennáll az UEFI-vel is, szóval bonyolultabb lett de a problémát nem oldotta meg.
3) emberi sebességű bootolás (nézd meg, hogy egy brand szerver biosos bootolásából hány perc, amíg eljut egyáltalán odáig, hogy az mbr-t betöltse!)
oké, de az szerver. egyszer kell elindulnia, akkor felőlem szüttyöghet rajta negyed órát. utána úgyis hónapokon keresztül minimum menni fog. amúgy 8 másodperc... elég lassú boot time mit ne mondjak. én legacy boot mellett hozok olyan 3-4et. ez nem faszméregetés hanem az hogy ha normálisan be van állítva akkor tapasztalataim szerint nincs gond.
4) a gyárilag beégetett támogatással rendelkező eszközökön felül más, drivert igénylő hw-ekről/protokollokkal történő bootolás (pl. iscsi hálózaton keresztül)
ezzel nem fogok vitatkozni, maximálisan igazad van. viszont ezen a téren nem vagyok benne biztos hogy az UEFI a legértelmesebb megoldás (én speciel kifejezetten örülnék neki ha létezne olyan alaplap amin van egy pici flash memória, indításkor egyetlenegy standard módon a vas elindítja ami ezen csücsül innen meg az történik amit ebbe a kicsi cuccba te kézzel belepakoltál. ami felőlem lehet valami UEFI implementáció is. ja, van is ilyen, lásd Talos II)
5) ip stack a biosban (pl. tcp/ip alapú bootoláshoz, tcp/ip alapú firmware update-hez)
nem. basszameg az alaplapban NE legyen IP stack. kurvára ne legyen, majd akkor pofázzon a hálózattal ha elindítok rajta valamit aminek pofáznia kell a hálózattal. az IME-nek is az egyik agyrákja ez hogy rohadtul nem tudjuk hogy pontosan mit is csinál benne a TCP/IP stack, értelmes ember meg nem akar backdoort a vasra.
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
1) egynél több oprendszer értelmes támogatása a bios/uefi oldaláról
IMO az alaplapnak nem feltétlenül kell oprendszert indítania. a bootloaderek erre vannak kitalálva, ne akarjunk már mindent az alaplapba erőszakolni.
A bootloaderről beszélünk. Több oprendszer -> szükségszerűen több bootloader. Tehát átfogalmazom: több feltelepített bootloader támogatása.
2) a boot loader számára egy _értelmes_ hely biztosítása (a basszuk bele a boot loadert az mbr utáni random reserved szektorokba, ahol aztán random módon felülbasszák egymást, az kurvára nem értelmes)
ezt őszinténszólva nem látom be miért lenne érdemi szempont. a probléma ugyanúgy fennáll az UEFI-vel is, szóval bonyolultabb lett de a problémát nem oldotta meg.
A probléma nem áll fenn az uefi-vel, mert lett egy standardizált hely, az uefi partíció, ami azért van, hogy oda lehessen jól specifikált környezetbe egynél több bootloader kódját berakni. Ezt uefi nélkül is kb. pont így tudnád megcsinálni normálisan (kézzel), amire amúgy az 1) pont miatt szükséged is van, mivel az mbr örökség miatt minden oprendszer hozza magával a saját maga által menedzselt bootloadert, és a közös használatnak nincs standardja (ergó szopás megcsinálni kézzel). Tehát az az állítás, hogy a valós problémára (hogy lesz nekem egymástól függetlenül több oprendszerem több bootloaderrel, amik nem basszák egymást felül) nincs az uefi által adottnál nagyságrendileg egyszerűbb megoldás. A kézi megoldás nyilván tudja ugyanezt komplexitásban, csak éppen nem standardizált, ergó sokkal nagyobb szopás. A megvalósítás részletein (pl. miafaszér kellett fat32-t használni) lehet elmélkedni, de a valós igényen és a koncepción szerintem nem érdemes.
Ezt el is fogadnám, a gond csak az, hogy vagy az MS piszkálja az EFI bejegyzéseket, vagy a nem szabványos UEFI implementáció következménye, hogy amennyiben megjelenik egy Windows bwjwgyzés is a Linux mellett, úgy mindenképp az lesz az első, s figyelmen kívül lesz hagyva a boot order. Innentől kezdve viszont a dolog úgy áll, hogy míg MBR alapon van esély arra, hogy egy Windows frissítés nem ront el mindent, addig UEFI használata esetén egy Windows frissítést követően megszűnik a másik oprendszer indíthatósága.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
hogy míg MBR alapon van esély arra, hogy egy Windows frissítés nem ront el mindent
Nincs. Egy windows install pl. automatikusan felül fogja baszni az mbr kódot is, és a bootable flaget is, ergó legközelebb mindenképpen a win fog bootolni.
Szóval ez a hajó így is, úgy is elment a szabványtalan implementációk miatt.
Mondjuk emlékszem még vagy 25 évvel ezelőtt voltak olyan túlokos bios implementációk, amiket meg lehetett kérni, hogy az mbr tartalmát tegyék el, és onnantól kezdve nem lehetett biosba lépés nélkül oprendszerből megváltoztatni, mert a bios visszaírta a kódot... ez valami vírusvédelem címén futott, az mbr vírusok ellen volt meglehetősen hatásos :D
3) emberi sebességű bootolás (nézd meg, hogy egy brand szerver biosos bootolásából hány perc, amíg eljut egyáltalán odáig, hogy az mbr-t betöltse!)
oké, de az szerver. egyszer kell elindulnia, akkor felőlem szüttyöghet rajta negyed órát. utána úgyis hónapokon keresztül minimum menni fog. amúgy 8 másodperc... elég lassú boot time mit ne mondjak. én legacy boot mellett hozok olyan 3-4et. ez nem faszméregetés hanem az hogy ha normálisan be van állítva akkor tapasztalataim szerint nincs gond.
A szervereknél is gáz. Amikor troubleshootolás van, akkor kurvára nem azzal szeretném tölteni az időmet, hogy 5-10 perceket várok egy nyamvadt bootra (true story!), mert a világ összes minden szarára rápróbál a bios (esetleg van a gépben egy-két kártya, amiről akár bootolHATNÉK is, ha akarnék, de nem akarok, így viszont kivárhatom annak az inicializálását is), hogy hátha van olyan alkatrész a gépre rádugva (vagy mitudomén mi a szar tart nekik ennyi ideig, de látványos a dolog). És egyáltalán nem vígasztal, hogy amikor éppen minden rendben van és jól be van állítva, akkor gyors tud lenni...
Amúgy nekem a vacsiúj 5590-es dell is tudja azt, hogy a bekapcsolástól a grubig több idő telik el, mint a grubtól az ubuntu loginig. Pedig a linux nem is bootol nagyon gyorsan...
És hogy ennek mi köze az uefihez? Hát az, hogy a legacy biosnál nem volt specifikálva, hogy milyen hw elemeket kell a rendszernek inicializálni (rendes speckó se nagyon van igazából), és miket nem, míg az uefinél már gondoltak erre. Így megengedik maguknak a gyártók, hogy egy csomó perifériával nem foglalkozik a bios uefi módban, kivéve persze, ha explicite bekapcsolod a bios konfigban.
Hogy meg lehetett volna ezt csinálni uefi nélkül is? Persze, de valahogy nem jutottak el erre a felfedezésre.
4) a gyárilag beégetett támogatással rendelkező eszközökön felül más, drivert igénylő hw-ekről/protokollokkal történő bootolás (pl. iscsi hálózaton keresztül)
ezzel nem fogok vitatkozni, maximálisan igazad van. viszont ezen a téren nem vagyok benne biztos hogy az UEFI a legértelmesebb megoldás (én speciel kifejezetten örülnék neki ha létezne olyan alaplap amin van egy pici flash memória, indításkor egyetlenegy standard módon a vas elindítja ami ezen csücsül innen meg az történik amit ebbe a kicsi cuccba te kézzel belepakoltál. ami felőlem lehet valami UEFI implementáció is. ja, van is ilyen, lásd Talos II)
Hát azon nem fogunk összeveszni, hogy az uefi mennyire (nem) jó implementáció... de az igény szerintem maximálisan valós. A fentieken felül pl. a "hogyan konfiguráljuk a bios beállításokat hálózaton keresztül" is egy nagyon valós igény lenne amúgy.
5) ip stack a biosban (pl. tcp/ip alapú bootoláshoz, tcp/ip alapú firmware update-hez)
nem. basszameg az alaplapban NE legyen IP stack. kurvára ne legyen, majd akkor pofázzon a hálózattal ha elindítok rajta valamit aminek pofáznia kell a hálózattal. az IME-nek is az egyik agyrákja ez hogy rohadtul nem tudjuk hogy pontosan mit is csinál benne a TCP/IP stack, értelmes ember meg nem akar backdoort a vasra.
Sajnos az ip stack kell a 4)-hez (pl. iscsi, mint legtriviálisabb példa). Az okés, hogy akinek nem kell, az majd nem kapcsolja be (ez most is így szokott lenni az uefi-vel), de hogy az ultrabuta udp/dhcp/tftp protokoll-szentháromságnál valami bonyolultabb is rendelkezésre álljon, azt nem érzem eltúlzott igénynek.
A végét nem egészen értem (illetve alig valamit is, csak egyszerű programozó vagyok): ha már egyszer az uEFI miatt úgyis muszáj HDD legyen abban az istenölelte gépben, akkor miért kell a BIOS-nak netwörkölnie? Derék user telepíthet a HDD-re olyan network-boot-ot, amilyet csak jónak lát.
Nem szeretnél iscsi bootoláshoz külön hdd image-et felrakni a gépre. Pont azért akarsz iscsi bootolást, hogy ne kelljen a gépre semmit se telepíteni, ne legyen semmi, ami elbaszódhat (mert valami felülírta), vagy ami alól egy nem redundáns, relatíve meghalásra hajlamos hw komponens ki tudna hullani. És pláne nem szeretnél kettő hdd-t berakni a gépbe erre a célra, amikor valójában pontosan nulla darabra lenne szükséged.
Szóval van hdd nélkül élet, az uefi tud menni hdd nélkül is.
Mellesleg, a másik funkció, amihez kell ip stack a biosba, hogy lehessen a bios funciókat (beállítások, firmware update) működő oprendszer, működő hdd nélkül is távolról használni.
Az alapvető elvárás, hogy ha kiterjedt desktop flottát üzemeltetsz, akkor ne kelljen fizikailag a géphez odasétálni szinte semmilyen karbantartási/telepítési okból. Márpedig ugye a windows az a valami, ami rendszeresen igényli a törődést, sokszor újratelepítés formájában.
Egyébként természetesen van/volt a uefi-től független megoldás erre a remote management problémára is: a mei/amt. Amit még többen rühellnek, holott a világ legnagyobb ötlete volt (az már más kérdés, hogy az intel-féle implementáció a legnagyobb jóindulattal is egy marék fos).
ad1) Hogyan kellene támogatni az OS-t BIOS-oldalról?
ad2) A lilo valahogy megoldja ezt a dolgot: van egy saját külön 'map' fájlja a stage2 számára
ad3) a BIOS inicializásának gyorsítása egyáltalán nem indokolja a bootolás felkavarását
a 4-5-höz nem értek, sőt, bevallom számomra sötét mágiának hangzik.
"mi az a _felhasználói_ igény..."
A felhasználó jól felfogott érdeke, hogy már a Windows indulása előtt, (v. Win nélkül is) lehessen a gépet távolról elérni, pl. a gyártónak BIOS-t frissíteni..
Milyen gyártónak? Az Acernek? Hogyan igazolja a derék Acer, hogy ő jóhiszemű BIOS-frissítő, és nem Haxor Hugó személyesen?
Nem mintha a legacy bios használata esetén a Windows nem vágná boldogan agyon az MBR-t, hogy telepítése után a Linuxodnak a nyomát se lásd a boot folyamat során.
Hasonló problémakörök esetén én általában EasyBCD-vel szoktam próbálkozni. Otthoni/személyes használatra ingyenes.
Ez nálam úgy van, hogy az Arch Linux a fő rendszer, az UEFI systemd bootot használ (/boot/loader/loader.conf és /boot/loader/entries/arch.conf alapján), semmi GRUB vagy sallang. A másik SSD-n meg UEFI bootos Win10 Prof van. Egyik rendszer sem tud a másikról, nincs boot menü. Tehát nem is dual boot, hanem kétszeres single boot. Alapból az Arch indul, ha az F12-re rátaposok, akkor elő tudom hozni az UEFI bootválasztóját, és kiválasztom a másik SSD-t. Így OS frissítés nem tudja elx@rni a bootolást. Nem kell vele vergődni, nem kell GRUB-ot frissítgetni.
No keyboard detected... Press F1 to run the SETUP
Grubot máskor sem kellene, az tenné a dolgát. A Windows szúrja el az EFI bejegyzéseket.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
De pont ezért csináltam meg úgy, hogy nincs se GRUB, meg a windowsos SSD-nek is saját EFI partíciója van, saját .EFI bootfájlokkal. Így egyik rendszer sem rondít oda a másik térfelére, teljesen függetlenek boot manager szinten is.
Az egyik titka valóban az, hogy amíg a Windowst felhúztam, addig kivettem a linuxos SSD-t, majd utána visszatettem. Elég szomorú, hogy telepítéskor még mindig nem lehet megadni a Windowsnak, hogy más háttértárakhoz nem nyúlhat hozzá, meg hogy melyik meghajtóra tegye a bootfájlokat.
De aki nem bízik ebben a módszerben sem, annak az is megoldás lehet, hogy a Linux UEFI boottal van fent, a Windowst meg MBR Legacy boottal telepíti, így a Windows megint csak nem tud belerondítani a Linux UEFI bootjába.
No keyboard detected... Press F1 to run the SETUP
Szerintem nem érted, amit írok. Az nem baj, ha a Windows ír az EFI partíción lévő filerendszerre, hiszen az azért van. Épp az lenne az EFI lényege, hogy attól még a másik oprendszer boot file-jai megmaradnak. A gond azzal van, hogy az EFI bejegyzéseket rombolja szét a Windows. Ezek a bejegyzések szerintem az alaplapon flash memóriában vannak tárolva, nem pedig háttértáron. Innentől kezdve lényegtelen, hogy lehúzod-e a telepítés idejére az SSD-t a SATA portról.
A másik, hogy nem minden alaplap tud legacy boot-ot, s ez egyre inkább így lesz.
Arról beszélek, ami az efibootmgr paranccsal piszkálható. Windowsra is megvan ehhez a parancs, csak nem emlékszem már a nevére.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ez részben igaz, de az UEFI nem csak UEFI-bejegyzés alapján tud bootolni, hanem EFI partíció lévő .conf fájl alapján is megtalálja, hogy milyen OS-eket mivel lehetne betölteni.
Acert nem ismerem, de hallottam hírüket, hogy milyen fos UEFI implementációkat csinálnak. Rendes gépeken nincs ezzel gond.
Legacy bootot azért ma még a legtöbb gép támogat. Talán 1-2 táblagép lehet kivétel.
No keyboard detected... Press F1 to run the SETUP
A Dell legfrissebb szériája (5490/5590) már nem hajlandó belső diszkről bootolni, csak UEFI módban. Más helyről igen, de onnan nem. Ez szintén pöcs dolog, tegyük hozzá.
Már minden modern OS támogatja évek óta az UEFI-t. Ez UEFI only boot azoknak érvágás, akik legacy OS-t akarnak rajta használni, WinXP, DOS, OS/2, hasonlók.
Szerintem egyáltalán nem pöcs dolog, érdemes ezeket a régi legacy protokollokat meg az értelmetlen visszafelé kompatibilitást dobni. Különben sose lesz fejlődés, mindenki leragadt volna már a 16 bites DOS korszakban.
No keyboard detected... Press F1 to run the SETUP
Off: Ilyenkor tudom megérteni Dolores Umbridge kollégát: a fejlődés jó dolog, de a változtatás kedvéért való változtatást jó lenne megszüntetni.
On: Windows esetében a 'támogatja' azt jelenti, hogy BIOS/MBR esetén meg tudja 'ölelni' a többi OS bootját, UEFI/GPT esetén pedig úgyszintén.