Legacy vagy Uefi ?

Szerverek

Sziasztok!

Vásároltunk egy új szervert intel s2600cw széria. Kérdésem, hogy uefi vagy legacy módban érdemes szerintetek használni, telepíteni rá os-t?
Arra gondoltam az uefi csak kinőtte már a gyerek hibáit vagy nem?

Amit szeretnék, hogy a kis gépezet egy jó pár virtuális gépet üzemeltessen. Xen vagy vmware-re gondoltam.
Köszönöm.

  • 25103 megtekintés

( uid_16313 | 2017. 09. 07., cs – 11:27 )

Szerintem valójában nincs nagy jelentösége, mivel ritkán fog boot-olni optimális esetben. Èn személy szerint az UEFI-re voksolnék, mivel az a jelen/jövö megoldása per pillanat, a Legacy-t nem eröltetném, mert emulációs jellege van.

Modern vasra modern bootot.

--
robyboy

( zrubi v | 2017. 09. 07., cs – 13:34 )

Szerintem olvasd el a Xen és a VMware ajánlásait ;)

Vagy simán állítsd Legacy módra, és hagyd a tesztelést, hibakeresést és bejeletést, meg a mosottruhát másra...

--
zrubi.hu

( Mik v | 2017. 09. 07., cs – 14:18 )

Nemrég keresett meg exkolléga, hogy vajon az előző cégnél mi volt? Mondtam neki, hogy passz, sosem állítottuk a szervereken ezt, de mivel nem kellett sem CentOS sem VMware alatt semmi UEFI-hez köthető dolgot állítani ezért erős a gyanúm, hogy a Delleken a legacy az alap...

( end | 2017. 09. 07., cs – 15:18 )

Néhány újabb keletű (valamelyik HP-nál, Core-i5 gen felett.,) "vasnál" azt tapasztaltam, állíthatok én Legacy-t, a legközelebbi BIOS-ba lépésnél, úgyis az UEFI beállítás lesz aktív. (Megjegyzem, a korszerű, új generációs (NVMe SSD-k,) használatához már csak UEFI-n keresztül vezet út.)

( locsemege v | 2017. 09. 08., p – 14:05 )

Előre szólok, ne hallgass rám! Nem szerver, egy picike notebook, UEFI-s, secure boot-os, és már másodjára van az, hogy boot-olhatatlan a gépem, s azzal szívok, hogy próbálom életre kelteni. Sima MBR-nél eléggé fonalas az ügy, de EFI boot-nál csak a bajság van. Jó, tudom, én vagyok a tudatlan tök, de akkor is...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én is azt hittem. Aztán csináltam egy oprendszer upgrade-et, ami után nem boot-olt a gépem. Azóta kinyomoztam az efibootmgr -v paranccsal, hogy az egyes bejegyzések között van eltérés, ki kell törölnöm a régieket. Most nagy nehezen elindult, de még csak unszolásra, úgy, hogy megadtam a next boot-ot, ami csak egyetlen boot-ra érvényes. Aztán tervezem, hogy teszek a gépbe egy 256 GB-os SSD-t, akkor majd kezdhetem elölről ezt a szívást.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Fujitsu Lifebook LH532-es laptoppal szívtam ugyanezzel anno, többször kellett HW-recovery-t csinálnom, mert elszaródott az UEFI boot-menü. 2 év után kijött egy BIOS frissítés a cucchoz, azóta nem szarakodik, működik rendesen.
Szóval erősen függ az adott megvalósítástól. Szervereknél jobban odafigyelnek az ilyenekre mint a consumer cuccoknál.

--
robyboy

Jó, de azt tegyük hozzá, hogy dupla bootmanagerrel (schim, grub) bonyolított, béta disztróról van szó (Fedora 27, ahogy a blogodon olvastam). Egy sima EFI stub bootot használó, rolling release Arch Linux ettől sokkal egyszerűbb, nincs bootmanager, nincs disztrófrissítés (minden frissítés egyben disztrófrissítés is). Van ugyan initramfs, de a pacman frissítéskor (legyen az kernel, systemd új verziója, stb.) kulturáltan megoldja.

Egyébként nem kell szívni az új SSD-vel, csak rsynccel vagy tar-ral átvinni a rendszert meg az adatokat, meg arra figyelni, hogy a partíciók sorrendje meg azonosítók (mind a lemez, mint a partíciók PARTUUID-je, mind a fájlrendszerek UUID-i) megegyezzenek. Tessék szépen jó Schönherz-kolis nerdnek lenni, ha már egyszer egy teljesen halott platformot használunk :D

Szerintem néhány évtizede jártam utoljára a Schönherz koliban. Nem Fedora bug, mert boot-ol, ha a next boot-ot megmondom neki. Csak a szokásos: ebben a vacakban be vannak drótozva a file-ok, elérési utak, nagyon úgy tűnik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

>Egy sima EFI stub bootot használó, rolling release Arch Linux ettől sokkal egyszerűbb

+1

Systemd-boot (régebbi nevén gummiboot) van a rendszer alatt nálam is, egyszerű mint a bot és kiválóan működik, mindaddig amíg nem kell dualboot. Bár én dualbootos gépen is ezt használom, nálam külön merevlemezen figyel a Win és a Linux, saját bootloaderrel, rendszer induláskor meg BIOS boot menüből választok, melyik induljon.

2-3 hetente ha át kell jelentkeznem Windowsra, ilyen gyakoriságú OS váltás mellett nem olyan nagy érvágás ez az extra lépés, ellenben sokkal tisztább, szárazabb érzés így elkülönítve tárolni az OS-eket (ha kell, bármikor átrakom másik gépbe bármelyik rendszert).

Pedig hogy pont egyszerűbbek ezek. Kivéve a secure boot, azt ki kell kapcsolni, mert semmi ellen nem véd már. AZ UEFI/EFI/GPT viszont jó dolog, mind egyszerűbb, mint a BIOS/MBR/GRUB és társai. Az UEFI fejlettebb rendszer, bár konkrét gyártó implementációjától is függ, de nincsenek meg benne a BIOS limitációi (méretkorlátozás, CPU nem kell, hogy valós módban menjen, az UEFI gyorsabban detektálja és ellenőrzi a hardvereket). Az EFI boot is egyszerűbb, nem igényel külön bootmanagert, elég csak egy EFI bejegyzés, vagy egy FAT32-es EFI partíció némi indító- és .conf-fájllal, és minden OS bootolni fog. A GPT megint csak jó dolog, nincsen benne 2TB-os partíciókorlátozás, nem vagy 4 elsődleges partícióra korlátozva, nem kell bootflaggel szórakozni, nem kell a partícióknak sorrendben lennie, meg egy csomó egyéb dolgot tud.

Ezért ha a gép tudja, meg az OS sem túl régi, megéri használni az UEFI bootot. Már csak azért is, mert a modern gépek egyáltalán nem támogatják a BIOS-os megoldást, csak emulálják, megint csak implementációtól függ, hogy milyen sikerrel, és milyen kompatibilitási fokkal vagy bugokkal.

Először én is féltem az UEFI-től, mikor először UEFI-s gépem lett, mert a neten csupa rosszakat írtak róla, a legtöbb ember szív akármilyen OS telepítésével, főleg a linuxosok. De aztán, ahogy utánaolvastam, meg elkezdtem használni, kellemesen csalódtam benne, egyáltalán nem bonyolult, csak meg kell érteni a működési elvét.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Az EFI egy nem létező (értsd: réges-rég megoldott) problémát akar megoldani.
Nekem az a véleményem, hogy semmi sem lett jobb vele. Most már a FAT fájlrendszer lett a szabvány?? Komolyan???
Az eddigi egy bináris helyett most már hármat kell szállítani a bootmanager-ekhez (legacy, 32 meg 64 bit efi), mert az EFI ugye annyira jó, hogy még ezt sem tudja kezelni. Ezt az egészet fűszerezi, hogy egyes processzor gyártók sem bírják normálisan implementálni, és a 64 bites processzoruk valamiért csak 32 bites EFI image-el indul...

Az MBR lehet hogy tákolás volt annak idején, de valahol igencsak elegáns koncepció, hogy a diszk első szektorát kell futtatni. Persze, vannak limitációi, meg tény hogy a bios disk access elavult, de olyan jól működött ez 30+ évig.

GPT-t nem keverném ide, mert GPT/legacy is működik normális hardveren. Persze találkoztam olyannal is, ami nem volt hajlandó GPT-ről bootolni, csak UEFI-ben, mindegy mi volt beállítva. Ugyanez a diszk egy másik gépben meg vígan ment.

Én még olyan procit nem láttam, ami csak 32 bites EFI-vel indul csak, szerintem nem a procitól függ, hanem az alaplap UEFI-implementációjától. Amelyik gép UEFI-s volt, azokra mindig 64 bites OS-t telepítettem EFI boottal, és mind elsőre megette. Az is igaz, hogy mind inteles procis gép volt, de azok között a legkülönfélébbek, Core 2 Duo, Core Celeron/Pentium, i3-i7, asztali és mobilprocik vegyesen. Nem kerülöm az AMD-t, csak a véletlen műve, hogy nem került be a szórásba.

A GPT-nél sem kell túl sok szektort beolvasni. Az UEFI-nél azt kell érteni, hogy a mai technika, a gépben lévő sokféle integrált hardver, sok meghajtó, multi OS-ses felállás kinőtte már a BIOS/MBR kereteit. Ha meg már előre akartak lépni a gyártók, akkor nem egy régi szabványt foltoztak tovább a jelenlegi igényekig, hanem egy újat kezdtek, amiben több évnyi tartalék is van. Abban az egyben egyetértek, hogy illett volna a 32/64 bit támogatást megcsinálni, hogy ne legyen gond, de más hátrányát nem látok az UEFI-nek.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Egyes Intel Atomoknál van ez a helyzet, bár lehet hogy tényleg alaplapi probléma, ezt nem tudom.

Értem én, hogy vannak esetek, ahol az MBR már komoly limitáció (különösen ugye a 2 TB feletti diszkeknél), de ezt a GPT megoldja, és GPT-ről is lehet hagyományos módon bootolni, amihez nem kell fájlrendszer drivert írni a "BIOS"-ba.
OK, pl. Raspberry Pi, meg néhány embedded rendszer szintén hasonlóan csinálja, az az előnye megvan neki mindenképp, hogy nem kell hogy a boot sectorba kerüljön a futtatandó bináris. De ezt egy u-boot is megcsinálja.
Tehát nekem épp az a bajom, hogy az a szoftver, ami arra való hogy elindítsa az OS binárisait, eddig megvolt, és szoftver volt.
Most már nincs meg (nem szükséges), de bele van égetve a vasba. Mit könnyebb frissíteni? Flash-t vagy egy GRUB-ot?
És azért jönnek elő bőven problémák az EFI implementációkkal, nem lehet azt mondani, hogy minden pöccre menne vele.
A másik problémám pedig az, hogy ha ma kitalálnak egy szabványt, az általában rövidebb életű lesz, mint az elődje. Ezért írtam hogy 30 évig elvoltunk a hagyományos boot processz-el, én biztosan nem adnék 30 évet az UEFI-nek. Max. akkor, ha annyira marginalizálódik a PC piac, ha nem lesz értelme már változtatni rajt.

Nem a fejlődés ellensége akarok lenni (tényleg nem), értem hogy a szoftverek egyre többet tudnak, és ez természetes is, csak vannak dolgok, amik annyira kipróbáltak, és olyan nehéz őket megváltoztatni visszamenőlegesen, hogy nem érdemes. Különösen ha a nyereség egyébként nem túl nagy.
Most lehet kövezni, de nekem a systemd-vel is ez a bajom :D

Aztán, ha egy kikapcsolhatatlan secure boottal van megáldva az egész, akkor lehet egy sort aggódni az aláírások helyességén is, meg azon, hogy minden úgy menjen, ahogy azt elképzeled.

Nekem az a bajom ezzel a technológiával - bár nem ismerem eléggé -, hogy kevésbé a felhasználóé és jobban a gyártóé a gép, tehát nagyobb a kiszolgáltatottság.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem jott at :)
Arra probaltam utalni, hogy ugysem tudsz neki mit csinalni.

BIOS es EFI ugyanugy lehet szar is meg jo is, a gyarto sara :)
van olyan kb. 10 eves szerver ahol mar efi van, semmi baja.

nem a boot miatt kell EFI hanem mert annyi HW komponens lett a vasakban ami mar tulno a bios-on, kellett valami komolyabb, raadasul EFI-t "kivulrol" tudod konfigolni szabvanyosan.

az en regi dzsunka PC-m meg ilyen "feligmeddig" EFI, ha hattertarat cserelek, akkor kivulrol kell betolni a megfelelo bejegyzest(efibootmgr vagy a windowsos megfeleloje), egy rendes EFI-vel tallozhatod melyik file-t akarod inditani, lehet szerkeszteni/torolni a bejegyzeseket...

Mar a KVM-qemu EFI-je is baromi jo. https://fedoraproject.org/wiki/Using_UEFI_with_QEMU

Horror sztorik vannak, az nekem is van. Még amikor az UEFI terjedőfélben volt kaptak szülők új budget gépet már ilyen alaplappal, aminek volt egy vicces bugja, hogy a csili-vili grafikus BIOS csak 4:3-as monitoron működött, 16:9-en zöld, vagy talán kék képernyőt kapott az ember (Gigabyte volt asszem).

Hogy hogy derült ez ki? Eredetileg 4:3-as monitoruk volt, azzal raktam fel nekik a gépet, így nem tűnt fel. De később kaptak új, 16:9-es monitort, a régit meg elvittem magammal. Egyszer csak bekrapált a Windows, újra kellett volna rakni nekik, amihez boot sorrendet kellett volna állítani... Persze nyilván pont a gariidő lejárta után történt ez.

Ettől még nem lesz szar dolog a UEFI, ez színtisztán a gyártó sara, mint ahogy az is, hogy ha kikapcsolhatatlan a secure boot.

Ha jól emlékszem akkor az egész uefis marhaság bevezetésének az egyik fő indoka az volt, hogy majd csak jól aláírt rendszereket lehet indítani a számítógépen és az milyen jó lesz a felhasználónak. Abban az esetben amit idéztem ez meg is valósult. A szétrohadt vindózon kívül semmit nem lehetett elindítani azon a három samsung laptopon. Semmilyen külső eszközről nem lehetett rendszer indítani. A két gyártó (samsung - microsoft) jól kicseszett a vásárlóval mert mindhárom laptop (sok százezer forint) egy év után ment a kukába.

Most meg az van, hogy ha van lehetőség rá akkor gyorsan kikapcsoljuk az uefit, hogy elkerüljük az ilyen és hasonló szopásokat. Így aztán sok értelme van az uefinek...

Notebook-omon ránézésre az, ki van szürkítve a menü. Google-t nem néztem még, a fedorás csapat aláírja mindig. Eddig egyetlen kernel nem volt aláírva, nem is boot-olt be a gép vele, de azt a build szerverről szedtem, még nem volt kint az update repóben. Azonnal jeleztem is a hibát, nehogy belekerüljön az update-be, mert akkor sokan megszívták volna.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak nem Acer Aspire ES1-132? Minap szívtam egy ilyennel... Mondjuk tele az internet figyelmeztetéssel, hogy ez a gyártmány erős szálakkal kötődik a Windows 10-hez, de meg kellett oldani a dolgot, a tulajnak Ubuntu kellett. Találtam megoldást, de ráment egy fél munkanapom. A probléma lényege, hogy az újabb BIOS-okban (a gépen a legújabb 1.15-ös van) sikerült ügyesen fixen kódolni az útvonalakat, így az EFI/ubuntu láthatatlan - ennek teljes tartalmát át kell másolni egy létrehozott EFI/Linux könyvtárba (kizárólag ezt látja, különben "No Bootable Device" hibaüzenet) - de ez sem elég, a telepítéshez használt USB-s kulcsról még be kell másolni a BOOTx64.EFI-t ugyanide. Na most mire én erre rájöttem... Próbáltam én mindent, rEFInd, efibootmgr - semmmi... Szóval nekem ez az UEFI-dolog nem hiányzik a boldogságomhoz...

Azt azért vegyük figyelembe, hogy egy szabványt nem a Tesco value Éjször Suxxxpire gép fostos Win10 only implementációja alapján kell temetni, ami még a consumer cuccok között is a legalja. Bár ha EFI partíciós boot van, akkor a bootx64.EFI mindig kell (vagy egy ennek megfelelő EFI-fájl, nem muszáj ennek lennie a nevének), meg ha initramfs-es a disztró, akkor az initramfs image(-ek) is kellenek.

De, az! Köszönöm a segítséget, valahol itt lesz a kutya elásva, mert ha az efibootmgr-rel next boot-nak megadom a Fedorát, akkor elindul, persze, csak egyszer.

A bedrótozás egyfelől lehet, hogy véd a téglásítás ellen, másfelől viszont szívás, mert nem tudom úgy módosítani a paramétereket, ahogyan szeretném.

Folytatom a küzdelmet, aztán meglátom, feléled-e rendesen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, az volt a megoldás, amit írtál. Látva az efibootmgr -v kimenetét, ezt csináltam még:

cp shimx64.efi BOOTX64.EFI

Most már csak az lesz a szívás, hogy szerintem a grubby nem ezt a grub.cfg-t fogja kernel frissítéskor módosítani, s majd szerkeszthetem manuálisan, ami kell. Bár megnézem, konfigurálható-e a grubby.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( taarzaan | 2017. 09. 08., p – 18:18 )

Szerintem a firmware-bios támogatások alapján érdemes dönteni: pl raid, mdadm, hálókártyák/pxe boot, ilyesmi. Lehet ez-az bugos/kevésbé támogatott.

UEFI-vel és GPT partíciókkal szerintem is csak a szopás van, de biztos jó, ha már megtanulta az ember, hogy mihez hogy nyúljon...

Ha össze tudod rakni legacy-val azt, amire szükséged van, szerintem felesleges szívni az UEFI-vel.

Ha meg ráérsz és szívesen kockáztatsz, akkor hajrá :) De készülj fel pár tanulókörre :)

( gdavid v | 2017. 09. 10., v – 14:40 )

Eddig inkább azt mondtam volna, hogy UEFI. de legutóbb jó három-négy órát sz*vtunk UEFI miatt. RH alatt egy frissítés után az uefi miatt nem indult el, nem akarta betölteni a ramdisk-et, hiába generáltam újra vagy új kernel, régi kernel... Tucatnyi egyező hw -ből kettőben valami elmászott így egy másik szerverből kellett egy működő lemezt beletenni, az meg elindult. Na az uefi újratelepítése oldotta meg a dolgot...
legacy-nal ilyen problémám még nem volt.

( neutrino v | 2017. 09. 11., h – 15:25 )

Vannak dolgok amik legacyn mennek csak rendesen (pl iPXE). Mostnában elég sok BL460c g8/9 szervert telepitek és sajnos az UEFI csak gondot okoz.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

( bigfoot v | 2017. 09. 11., h – 21:15 )

+ 1 legacy, minek szopni a bizonytalannal ha a másik tuti stabil. + bekapcsolod 3 év után meg ki aztán kuka ("normális esetben" :) )

( Robika88 | 2017. 09. 13., sze – 09:09 )

Igen, akkor mindenkinek vegyes a véleménye, főleg gyártó szempontjából. Maga az alaplap legacy-t állított default értéken, így hagytam azon. Uefi módban a boot képernyő érdekes volt, pl grafikai hibát dobott a saját logojára. Mivel szívni nem akarok vele, így a jól bevált maradt. köszönöm mindenkinek