Ahogyan megöltem a MacBook Air 2017-et

Szerettem volna 3 OS-t bootolni a gépen.  Linux, Windows és a MacOS. Bármely kettő nem gond. Ja de! A Windowst önmagában hekkelni kell, hogy natív telepíthető legyen. A bootcamp-ből kell kioperálni a drivereket, különben nincs natív telepítés.

Kubuntu 19.10 szépen futott rajta OOTB. 

Ha Mac alól indítottam el a Bootcamp-et majd onnan a Windows telepítőt, akkor ez szépen lemegy és működik is. Tényleg nagyon jó. Amikor 3. OS-t kívánom telepíteni, akkor viszont a Windows partíció többé nem indítható. Utánaolvastam, régebben volt hozzá herélt FLOSS bootloader, de az már nem megy ezen a gépen, mert ahhoz ez túl új. Nem hagyott nyugodni a dolog, nem hiszem el, hogy a világon nincs még egy valaki, akinek hasonló igénye volt és meg is csinálta! Több mindennel próbálkoztam, de semmi sem működött. Igazából már presztízskérdésé vált ez a küldetés, mert gazdaságilag nem érte meg, rengeteg elbaszott munkaóra. Persze nyitott voltam a  dologra, mert a HW nekem is tetszik, az OS nem. Azt nagyon gyermetegnek tartom, Linux után a gyerekeim játékaira hasonlít, tudásban is).  Arról már  kisebb értekezést tudnék írni, hogyan nem fog működni a 3 OS egy Mac-en. :) 

Egyik éjjel, de inkább hajnalban valahogy az Apple Support oldalára tévedtem, ahol megláttam egy parancsot amivel lehet az nvram-ban engedélyezni a multiboot-ot több hdd-ről. Egy olyan parancsra gondolj, hogy "sudo nvram param=value" Gondoltam ez lesz megoldás, mert a kurva sok kis partíciót lehet a MacOS nem tudja default kezelni (az optimalizáció miatt, hogy gyorsabb legyen default a gép a userek 99,999999%-ának ;) ). Nem voltam elég figyelmes (én vétkem, én vétkem), ez a parancs csak a 2018 utáni gépeken csinál valamit.... ööö illetve ezen a gépen is!!! Konkrétan reboot után SOHA TÖBBET NEM INDULT EL TŐLE

Nem egyszerűen nem indul, hanem nagyon nem. Logikailag nézve, amikor lenyomja bimbamot a Mac, akkor van bent a "bios" (itt nvram) a RAM-ban és akkor érhetők el a varázsfunkciók sok-sok ujj használata esetén. ;) Ez a gép a fenti parancsot követően nem bimbam-olt így semmilyen funkció nem volt elérhető. Oké. Nem vagyok megijedve, biztosan van valamilyen varázslat "bios" resetre. Van, kell hozzá két/három kéz meg amid van. Deeeeee!!!!! Ezek a varázslatok akkor működnek, ha van bimbam. Na erre is elment kb 6 munkaóra. Volt még egy megoldás aku le-föl, de az sem ment. Végül elvittem a szervizbe ahol két hétig volt (most is ott van) és KICSERÉLTÉK AZ ALAPLAPOT. 

Okkal ugorjuk át nagyvonalúan azt a tényt, hogy olyan parancsot adtam ki, ami nem arra a gépre írt a support.
Mi is történt valójában? Az operációs rendszer alól kiadtam egy parancsot, amivel tönkretettem a gépet. Érted? A HW-t!  Remélem minden Apple szerelmes ezt felfogja, főleg ha kódol, hogy WTF!

Szerintem egy átgondolt HW így működik (BTW:HP ilyen):
- Boot során taposod az ESC-t (mert van rajta) bejön egy menü. Mindvégig egy ujjal tudod kezelni a folyamatot és leszámítva a boot-ot többé semelyik gombot nem kell több másodpercig nyomva tartanod.
- A bios-t nem basztatjuk OS-ből, vagy ha igen kisebb hatékonysággal, mint natív.
- Van rendes bios rendes UI-val.
- Ha írunk egy programot x.x verzióra akkor csinálunk hozzá getVersion()  és getMinVersionRequirement() függvényeket (vagy valami hasonlót) amiket használunk is.
- Nem írunk olyan programot ami tönkreteheti a HW-t

Na ezért nem lesz a következő 15 évben sem Mac-em. Ezért fogok mindenkit lebeszélni róla, kivéve akinek a szellemi szintje olyan alacsony, amit az IT Mac-el orvosol.  Az Apple termékek az IT világ legszebb ipari hulladékai. Ha ezek után megkérdezed miért, akkor neked még egyszer el kell olvasnod ezt a bejegyzést. ;)

 

Hozzászólások

subscribe, ez a thread is jonak igerkezik

Biztos, hogy nem egy "viktim szájsz nevö jutá" dologgal állunk szemben?!

trey @ gépház

Huuuuu, hat azon kivul, hogy en aki kozismerten ko alatt lakik, mint a nagybeka, es ez biztos igy van, meert itt is megaszondtak a szakertest, na lenyeg, hogy en is tudom mi az a "viktim szajsz..."

A fenti tunetbol az tudnam diagnosztizalni, hogy baj van, tobb is.

1, macbookot akarsz hasznalni

2, macbookon windowst hasznalni

3, kurva sok idod van ilyen hulyesegekre

Egyebkent szeretem az ilyet olvasni. Igen, en is rengeteg idot vesztegetek masmilyen hulyesegekre. :D

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Nem vagyok biztos benne, hogy ismered a legendás topik-ot, amire trey célzást tett, úgyhogy belinkelem. Már elmúlt 10 éves!!!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Szerkesztve: 2019. 11. 21., cs – 11:44

> Az operációs rendszer alól kiadtam egy parancsot, amivel tönkretettem a gépet. Érted? A HW-t!

Becsszó nem az Apple védelmében írom ezt, de ilyesmire bizony Linux esetében is volt már precedens, amióta a systemd boldogít minket...

Sz*rk: Sőt, egy gyors keresés után megállapítottam, hogy a windóztíz megjelenése után ez az említett platformon már mindenapossá - és automatizálttá! - vált (ld. WU).

Ezert fordulunk szakemberhez ha valamihez nem ertunk es nem magunk berheljuk.

Ja, azt hittem, hogy valamit mondani is akartál. Hogy a fenti igényeket itt és itt ki tudják elégíteni nem berheléssel. Jól jött volna az infó, mert van, hogy olyan cégeket szolgálunk ki, amik béren kívüli juttatásként Mac-et (is) biztosítanak a dolgozóik részére és ott néha igényként merülnek fel ilyen vad dolgok. Ezért vettem volna szívesen az ilyen szakember említését, aki ért hozzá.

trey @ gépház

Csak egy orokervenyu igazsagra vilagitottam ra miszerint ha valamiben nem vagyunk biztosak de legalabbis batrabbak vagyunk mint amilyen figyelmesek akkor utana nem sirunk, hogy elbaszodott valami illetve nem a gyartot hibaztatjuk.

Egy rakas gyarto cuccat tonkre lehet vagni rossz fw-vel.

Amikor egy tizezer forintos routeren kellett fw-t frissiteni, kb haromszor ellenoriztem le a checksumot a letoltott fajlon, tobbszor osszehasonlitottam az about page-en a hardver es fw verziokat a letoltott fajl adatlapjan szereplo kompatibilitasi listaval, majd a hw verziokat a ket helyrol egymas ala kopztam notepadben hogy tuti ne nezzek be valamit.

Persze el lehet viccelni azzal, hogy "Te ugye nem kódolsz?", de egy fejlesztonel pont, hogy indokolt lenne egy minimalis alapossag munkavegzes kozben. Az Apple-nel is, ofc, de itt szerintem kozos a felelosseg, hozzaertes/korultekintes nelkul nem erdemes fw-t berhelni.

Végülis, elég egy malware-t írni rá és kifingatni vele az összes sebezhető Apple gépet. Az ilyen beállításokat nem szokás futó OS felől elérhetővé tenni. Vagy szervizmenüben (BIOS és társai) vagy OS boot time paraméterként. De semmiképpen nem runtime paraméterként. Ha ennek elérését nem tiltották OS alól, az bizony ordas hiba.

trey @ gépház

Tudnom kellene valahonnan?

Igen, meghozza onnan, hogy a nvram turkalasa elott megnezed, milyen verzioju HW-t keszulsz eppen teglasitani, az About this Mac ablak masodik soraban.

Ha egy mas eszkozon nekiallsz fw-t frissiteni, nem nezed meg, milyen verziorol van szo, csak letoltod az elso zip fajlt ami szembe jon, es kezdodhet a flasheles? :)

En ugy olvastam, hogy a nagy szakertelmedben neked sikerult a webrol osszegooglizott, utanaolvasas nelkul kopipesztelt paranccsal brickelni. Ha ezt a support.apple.com tette veled, akkor sowwy. 

Van egy csomo apple szar nalunk, gyakran elek en is a kritika jogaval - de ez a "azellen nem ved" erveles eleg gyenge. Nem vilagos, hogy minek oltel annyi idot bele, ha lathatoan ennyire elvezted/ertesz hozza.

(Valamiert az a postod remlik ide, amikor az olasz banki ugyintezonek magyaraztad (eves ~100 eur szamlavezetesi dij kapcsan), hogy neked par ezer eur apropenz.)

Onnan volt a parancs igen, a support.apple.com -ról.

 

Keversz két dolog itt: "eves ~100 eur szamlavezetesi dij kapcsan), hogy neked par ezer eur apropenz.)"

1. Zavar az éves díj
2. Kötekedett azzal, hogy a  sógornőm utal nekem alkalmanként több ezer eurót. Azt mondta azt ne csináljuk

Mind a kettő zavart, de ne keverjük össze.

Nem vonom ketsegbe - azt sem zarom ki, hogy igazad van. 

Valami van az eloadasmododban, vagy nem tudom, de mintha gyakran elnel szamomra eletidegen gondolatalakzatokkal. A szal onnan indult, hogy jobban ertesz hozza, mint a hazai service →←ennek ellenere a kulfoldi service oldalarol masolt paranccsal sikerult brickelned, mert nem olvastal utana.

https://hup.hu/comment/2408010#comment-2408010

 

https://support.apple.com/hu-hu/HT202796

"Nyissa meg a Terminal alkalmazást, amely az Alkalmazások mappa Segédprogramok almappájában található. 
Írja be a következőt, majd nyomja le az Entert: sudo nvram enable-legacy-orom-behavior=1.
Ha vissza szeretné vonni a parancsot, írja be a következőt: sudo nvram -d enable-legacy-orom-behavior."

A vastagított ölte meg.

Kicsit azért kiragadtad a dolgokat a kontextusából, azt a mondatot is elolvastad, ami közvetlenül afölött van, amit bemásoltál ide?

"A 2015 elején és a korábban forgalomba hozott Mac-modelleken letiltható ez a biztonsági funkció, és így automatikusan betölthető a kiegészítő ROM-firmware. "

Na és persze:

"Ezzel egy fontos védelmi elemet távolít el, amely a Machez fizikai hozzáféréssel rendelkező személyeket akadályozza meg az illetéktelen hozzáférésben. "

És akkor szerinted tényleg a support a hülye?

1. Mondtam ilyet?

2. Írja valahol, hogy többe nem fog bootolni a gépe?

 

Azt hiszem szövegértésben nem én véreztem el most kettőnk közül. Mint láthatod ez az oldal arról szól, hogy amikor nem látod a partíciót bootnál, mit csinálj. Nálam meg pont ez volt a gond. 

Igen, mondtál. Mégpedig azt, hogy a support oldal brickelte a géped, ami egyszerűen nem igaz.

"ps.: nem 3rd party brikkelte, hanem a support.apple.com"

A support.apple.com nem brickelte a géped, Te brickelted a géped, mert ignoráltad a bekezdés első felét. Értem, hogy felbosszantott a dolog, de iszonyú magas lovon ülsz és küldesz el mindenkit, aki nem veregeti a vállad. Beletoltál 10+ órát, hogy brickeld a MacBookod, miért kisebbíted az érdemeidet, legyél rá büszke! Vagy gondolkodj el rajta, hogy esetleg Te hibáztál, vagy amit akarsz. :)

Ez valami olyasmi lehet, mint pl. az UEFI: hatékony, flexibilis, felhasználóbarát. (Ezek az eufémizmusok azt jelentik, hogy nehezen vagy sehogy sem lehet azt csinálni, amit te szeretnél.)

Végül elvittem a szervizbe ahol két hétig volt (most is ott van) és KICSERÉLTÉK AZ ALAPLAPOT. 

Továbbra is lásd Louis Rossmann Youtube csatornáját. _Bármi_ gond van, az almás gééééééniuszok közlik, hogy alaplapcsere. Még ha csak egy szalagkábel csúszott is ki a helyéről...  (https://www.youtube.com/watch?v=o2_SZ4tfLns)

Ja, hogy ahol forrasztva van az SSD, ott cseszheted az adataid, amiről nem volt backupod? Ígyjárás. Ja, hogy ahol nincs forrasztva az SSD és még át is tudnád tenni másik gépbe, ahol semmit nem tudsz róla semmit leolvasni, mert alaplaphoz van társítva és csak az eredeti lappal tudod olvasni? Ígyjárás (oks, ezt PC-n is el tudod játszani, ha TPM-mel lekódolod a lemezt).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Különben szerintem is a csere a hozzáértés hiányát mutatja.

Nekem volt még egy tippem a javításra, de körülményes lett volna kipróbálnom:

USB külső hdd ami rendelkezik a Mac "bios" számára kedves partícióval rádug. Elképzelhető, hogy az említett parancs mégis csak ment, de eredményként kizárólag külső hdd-t várt volna a "bios", ami amíg nem jelent meg nem volt bios boot és "bimbam".

Persze, ha ez igaz, akkor ez is egy ótvar nagy bug. Szóval nem javul a reputáció. :)

Különben szerintem is a csere a hozzáértés hiányát mutatja.

Igen. De ha minden szervizt felszerelnenek mindennel + JO szakemberekkel vilagszerte, hogy gyors es idotallo javitast hajtsanak vegre az eszkozodon, nem erne meg nekik.

Valojaban neked sem eri meg, mert te sem akarod megyeszer visszavinni, ha nem sikerult jol a reballing...

A markanak is rosszat tesz es igy meg Pistike is meg tudja javitani neked es valoszinuleg menni fog meg evekig.

Ezeken a gépeken még tényleg BIOS van?

Nem tudom. Én egy nvram paramétert állítottam át.

https://support.apple.com/hu-hu/HT204063

 

"Az NVRAM-ban tárolható beállítások közé tartozik a hangerő, a kijelző felbontása, a kiválasztott indítólemez, az időzóna és a legutóbbi kernelpánik adatai. Az NVRAM-ban tárolt adatok a Mactől, illetve a Machez használt eszközöktől függően eltérők lehetnek."

szerintem probald ujra, hatha ezzel az alaplappal mukodik

 

 

;)

Azt olvastam, hogy a Mac OS jobb, mit a Windows.

Szerkesztve: 2019. 11. 21., cs – 22:49

Ezert vettem kulon gepet Linuxhoz. Es a Macbookon marad a macOS. Amiota nem BIOS van, hanem "nebancsdazssd egyik particiojat, vegkepp ne a particios tablajat" efi, faszom se tudja kovetni, hogy mit lehet letorolni a rendszerdiskrol es mit nem, es fog-e egyaltalan (akar Apple akar nemApple) gepen mukodni valami, ha a rendszerdisken levo Efit veletlen letorlom, vagy megrosszabb, tonkremegy a rendszerdisk. Linuxek meg azt se tudjak ma mar eldonteni, hogy /efi vagy /boot/efi vagy /boot/efi/efi ala szabvanyos-e epp ma mountolni, es mar a grub telepites is sokkal veszelyesebb nullarol epitkezve parancssorrol igy erzesre. Nem kockaztattam egy ilyen draga es forrasztott SSD-s gepet, vettem hozza kulon egy matricas laptopot. Nem veletlen, hogy nagyobb distrokhoz Linux on Mac leirasok is utoljara 4-5 eves hardverekre vannak, hiaba fut amugy kesobbieken is. Es nem, nem az az indoklas, hogy a macOS fejlodott.

Ez a pazarlo vilag egyszeruen ilyen lett: egy gep, egy OS. Mint a telefonoknal, csak azokon root access-ed sincs.

Nekem arra kell, hogy mai napig van par program, ami csak Winen meg macOS-en fut (koztuk az MS Office is). Ezeket akkor mar inkabb macOS-en futtatom, mert azert megse Winen kelljen mar.

De ablakkezelesbol en is jobb szeretem az X-es megoldasokat, foleg miota 10.11 kinyirta a full screen vs teljes kepernyo viselkedeset.

Annyiszor leírtam. :(

1. Nem magamnak vettem. (ez h1-es sor)
2. Közben tönkrement az Asusom (tudom laptop gyilkos vagyok)
3. Érdekelt a dolog, mert az Apple vas tetszik, minden más rajta nem.
4. Gondoltam amíg nem kártalanítanak nem veszek magamnak gépet, nehogy az legyen, hogy végén kapok még egy gépet
 

Ez a jelenség elméletileg bármilyen UEFI platformon előfordulhat. Az operációs rendszer a SetVariable() UEFI runtime service-t meg tudja hívni -- ez így van tervezve (ld. UEFI spec). Ha a módosítás tárgyát egy non-volatile változó képezi, akkor az a módosítás az alaplapi flash-ben fog tárolódni (vagy -- elméletileg -- bármilyen más tartós tárban, amely túléli, ha az alaplap teljes áramellátása megszűnik).

A változó módosításának konkrét hatása attól függ, hogy a változó mire való. A UEFI spec definiál egy bizonyos namespace GUID-ot, és azon belül néhány (nem kevés) változót, amelyek hatása pontosan specifikált. Bármely platform vendor generálhat magának tetszőleges számú namespace GUID-ot, másokkal való koordináció nélkül (ld. uuidgen), azon belül pedig úgy nevez el változókat, és arra használja azokat, ahogy neki tetszik. Ilyen változókba OS alól csak akkor érdemes belepiszkálni -- eltekintve mondjuk a kifejezetten erre szánt vendor utility-ktől --, ha pontos dokumentációnk van a firmware-ről. A vendor ugyanis nem feltétlenül szánja az adott változót végfelhasználói felületnek, és nem feltétlenül végez sanity check-eket a változó tartalmán. Ha szemetet írunk bele, abból lehet a firmware-ben buffer overflow, integer overflow, vagy kontrollált, de nekünk nem tetsző viselkedés.

Az efibootmgr utility-t bizonyára sokan ismerik és használják: na, az pont ilyen változó-manipulációt végez, csak éppen standard (a UEFI spec-ből származó) változókon dolgozik (BootOrder, Boot####, Timeout, BootNext, stb; a namespace GUID pedig EFI_GLOBAL_VARIABLE: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C).

A baj az, hogy általában nincs semmilyen eszköz vagy szoftver, ami a fenti szolgáltatás alatt helyezkedene el. Az alatt névutó megvilágításához gondoljunk például egy diszkre (HDD, SSD, USB pendrive, mindegy). Tegyük fel, hogy vírusos lesz, vagy eltolunk valamit a bootloader konfigban vagy bootloader bináris(ok)ban, és a  gép egyszerűen nem indul. Nincs semmi veszve, rádugjuk egy másik gépre a diszket (vagy a gépet beindítjuk másik boot media-ról), és az eredeti diszket "adatszinten" legyaluljuk. Innentől újra van egy használható, újratelepíthető diszkünk. Ez azért működik, mert a diszk leválasztható, és van szoftver (nevezetesen egy másik OS), amit a diszk elrontott állapota alá be tudunk dugni. (Ebben a példában eltekintek attól, hogy a diszkvezérlőn is lehet flash...)

Na, ez az alsóbb szintű szoftver v. eszköz az, ami általában nincs az alaplapi flash-hez, vagy legalábbis nem feltétlenül szabványosan. Létezik JTAG (meg van sok firmware security előadás / prezentáció, amelyben flash-t olvasnak ki, meg fejtenek vissza, lásd pl. itt), de ez mind platformfüggő, és idő- és szakértelem-igényes. Ha könnyen hozzáférünk is a hardverhez, még mindig ott van a probléma, hogy nem feltétlenül tudjuk, milyen UEFI változóval toltuk el a dolgot, milyen módosítást kellene visszavonni. A diszkes példára visszatérve, nem feltétlenül állunk neki a partíciós táblát vagy a boot sectort reszelgetni, hanem gyakran letakarítjuk az egészet (úgyis van backup :)) -- és sajnos ez a "letakarítjuk az egész flash-t" az, ami egy végfelhasználóknak szánt platformon elérhetetlen.

A konkrét esetben a szerviz számára is egyszerűbb volt az egész alaplapot kicserélni (csak azért, hogy a flash ismert és működőképes állapotba kerüljön!), mint

  • vagy kicserélni csak a flash-t az alaplapon,
  • vagy a flash (ill. a benne élő non-volatile változók) tartalmát hardveres eszközökkel megváltoztatni (és persze mire?).

Még az edk2 (EFI Development Kit II) projektben is, mely a UEFI és a PI (Platform Init) specifikációk nyílt forrású referencia implementációja, többször előfordult olyan patch, amelynek hatására egy korábbi firmware verzió által eltárolt UEFI variable tartalmat az új firmware verzió már nem tudott visszaolvasni. Bizonyos esetekben ez implementációs hiba volt (például annak nyilvántartásában, hogy egy adott hálózati kártyához, PXE vagy HTTP(S) netboot céljára, hogyan rendelünk IP címet: sehogyan, statikusan, vagy DHCP-vel). A legfrissebb ezzel kapcsolatos hibajegy, amelyről tudok, itt van. Más esetben pedig egyenesen UEFI spec szintű inkompatibilitás kúszott be (pl. a SATA device path node-ok reprezentációja megváltozott, így egy firmware frissítés hatására korábbról meglévő UEFI boot opciók érvénytelenné válhattak).

QEMU/KVM virtuális gépen OVMF firmware-t futtatva (mely egy edk2 platform) ez a fajta probléma jól demonstrálható. Nagy különbség fizikai platformokhoz képest, hogy egy virtuális gép alatt mindig van egy szoftveres réteg: a VMM őrzi ill. kezeli a guest számára a variable store-t. (Pl. QEMU/KVM + OVMF esetében egy normál host-oldali állományban.) Így a variable store file-t mindig újra lehet formázni a guest-en kívülről, a guest alatt. (Pl. QEMU/KVM + OVMF esetében simán letörlöd a korrupt v. használhatatlanná vált varstore-t, leállított guest mellett, a guest következő indításánál pedig a libvirt daemon újra létrehozza a varstore-t a varstore template-ből.)

Nyilván az is egy lehetőség, hogy a platform vendor megpróbálja előre felvértezni a változóit valamiféle kompatibilitással; itt egy példa az OVMF-ből.

Összefoglalva, a probléma gyökere az, hogy a UEFI variable store-hoz nincsen olyan szabványos felhasználói felületű eszköz -- akár szoftveres, akár hardveres --, amellyel a varstore ("flash") teljes összezagyválódása után is vissza lehetne állítani az eredeti gyári tartalmat.

"Nincs semmi veszve, rádugjuk egy másik gépre a diszket (vagy a gépet beindítjuk másik boot media-ról), és az eredeti diszket "adatszinten" legyaluljuk. Innentől újra van egy használható, újratelepíthető diszkünk. Ez azért működik, mert a diszk leválasztható, és van szoftver (nevezetesen egy másik OS), amit a diszk elrontott állapota alá be tudunk dugni. (Ebben a példában eltekintek attól, hogy a diszkvezérlőn is lehet flash...)"

Ez volt az egyik gondolatom. Nem volt megoldás. Gyalu is volt, másik diszk is.

"ugorjuk át nagyvonalúan azt a tényt, hogy olyan parancsot adtam ki, ami nem arra a gépre írt a support"

Igen, ugorjuk át a hiba valódi okát, hogy figyelmetlen voltál. Így indul egy igazi, professzionális hibakeresés...

"Az operációs rendszer alól kiadtam egy parancsot, amivel tönkretettem a gépet. Érted? A HW-t!"

Ha annyira értenél hozzá, mint amennyire büszke vagy magadra, akkor tudatában lennél annak, hogy 

"NV-RAM and EEPROM memory is flash memory." 

Vagyis igen erősen hardverközeli dolgok. Márpedig, az NVRAM bizgatása majdnem olyasmi szintű dolog, mintha firmware-t cserélnél a gépen. És mi történik, ha elrontod a firmware cserét? Úgy van, tégla lesz a gépből. És ez a technológia nem új, még csak nem is az Apple találmánya, 1999-ben már lehetett BIOS-t frissíteni az IBM PC-ken.

Akik ismernek itt a HUP-on, azok biztosan tudják, én lennék a legutolsó, aki ok nélkül védi az Apple-t. De ebben az esetben bizony elég bizonyosan PEBKAC történt, függetlenül attól, hogy a kedves felhasználónak van-e akkora arca, hogy belátja ezt vagy sem.

Ha valamihez nem értek, nem nyúlok hozzá, ez a szabály sokkal régebbi, mint a személyi számítógépek. Kell keresni egy olyan embert, aki ért ehhez, akár itt a HUP hasábjain, akár másutt és beszélgetni vele. De leginkább, ha valami veszélyesnek néz ki (márpedig az Apple support oldalain szinte biztosan köré van írva az NVRAM bizgató parancsnak, hogy tönkreteheted vele a gépet), akkor elhiszem, hogy az veszélyes is, és megfelelő óvatossággal közelítek a témához, például elolvasom, mit csinál az a parancs, és mit az adott paraméterekkel.

És tudni kell beismerni, ha hibáztunk. 

Sajnálom, ha ezért blokkolni fogsz, de a lényeg ettől vajmi keveset változik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szerkesztve: 2019. 11. 22., p – 12:48

Szerintem ez nem annyira nagy dolog.. Én anno a routeremmel csináltam hasonlót. Egy Asus WL500G Premium volt ha jól emlékszem.

Sajnos így jár aki az nvramban turkál figyelmetlenül. Gondolom az Apple-nél nem tettek az UFI-be ilyen védelmet, mert amit te szeretnél az az üzlet szempontjából eléggé a periféria szélére tartozik.

Az érem másik oldala nyilván az, hogy ez egy újabb fegyver lehet a sok kreténnek aki meg akarja szívatni a másikat egy bűvös paranccsal. (Mint például a PC gyilkos pendrive.)  Bár ha ez a parancs csak recovery módban adható ki akkor azért nem olyan vészes a helyzet.

Igen, meg ott a JTAG interface.

Egyébként szerintem megfelelő eszközökkel ez az alaplap is javítható lenne. Az hogy egyből alaplapot cseréltek, amennyire én tudom más gyártók szakszervizében is így van. A Dellnél így működik, mind a "kijövős", mind a "bevivős" garancia esetén is.

Tipikusan nem. Az atlag usernek a rendszer az elso inditaskor az arcaba nyomja, hogy itt az icloud, oda fognak menni a kepek, ha nem tetszik, opt out. 

Ha van olyan embertipus, akinek a nyaralasi fotoiert nem aggodok, az az atlag apple user. A legveszelyesebb az, aki szakertonek gondolja magat, nem backupol, majd utana mindenfele utanajaras nelkul copypaste-elt parancsokkal brickeli a gepet.

5gb a default icloud

Igen, es? 300 forintba kerul a nagyobb csomag, ha jol remlik? Vagy hany gigasnak kene lennie ingyen? Nem ertem, hogy jon ez ide?

Megtörtént egy barátommal:

Szerintem meg nem tortent meg. Pontosabban valami hasonlo tortent, ami az idok soran egy ilyen jo kis anekdotava egyszerusodott, strategiailag elhallgatva a PEBKAC reszleteket.