Végre ellenőrzi a Big Sur telepítője, hogy van-e elég szabad hely az upgrade elvégzéséhez

Címkék

A macOS 11 "Big Sur" telepítőjében a következő amatőr hiba volt: a telepítési folyamat megkezdése előtt a telepítő nem ellenőrizte, hogy rendelkezésre áll-e a szükséges, mintegy 35 GB-nyi szabad hely. A folyamat akkor is elindult, ha nem, így könnyen előállhatott az helyzet, hogy az upgrade folyamat meghiúsult. De akár adatvesztés is. A jó hír, hogy az Apple pótolta a mulasztását, most már ellenőrzi a telepítő a szükséges szabad hely meglétét a folyamat elindítása előtt:

Részletek itt.

Hozzászólások

Programozó urakat kérdezném:

Eltekintve attól most, hogy macOS, Linux, Windows vagy akármi ... hogy a fenében lehet 2021-ben ilyen amatőr hibát elkövetni? Ez kb. olyan, mintha elmennék az Ikeába egy szekrénysorért egy Suzuki Altoval, mert basztam előzetesen, az indulás előtt ellenőrizni, hogy a csomagok be fognak-e férni. Számomra ez érthetetlen.

trey @ gépház

Ugy gondolom, hogy itt nem az tortent, hogy kimaradt volna a szabad hely ellenorzese. Van egy rettentoen hulye, utalatatos talalmanyuk, miszerint minden "torolheto" tartalmat is hozzaszamol a rendszer a szabad terulethez. Nekem jelenleg emiatt, 155.2 GB ures helyet ir a felhasznaloi felulet mindenhol. Ha viszont megnezem a 'df' kimenetet, ott mar csak 61 GB latszik ugyonarra a kotetre szabad teruletnek. A 'torolheto' tartalom itt a felhoben is meglevo, tehat onnan leszedheto tartalmat, a cache es a tmp folderek tartalmat jelenti. Mivel a hely felszabaditasa nem mukodik ennyire "jol" (most nem tudnek egy 128 GB meretu SSD-rol sem imaget kesziteni, mert menetkozben elszallna, hogy nincs eleg szabad hely), ezert szerintem egyszeruen az tortent, hogy nem a valos, hanem a logikai szabad helyet ellenorzi a telepito... Most telepul egy 10.15, hogy megnezzem mit csinal a 11.0 telepito akkor, ha tenyleg nincs annyi hely, logikailag sem.

Ha lenne egy "dobj ki minden purgeable dolgot" gomb, akkor pl jo is lenne, illetve, ha tenylegesen torolne/takaritania, mikozben telitodik a lemez. De ha a GUI-bol masolok pl a beepitett gyari filekezelovel (Finder), akkor szokott takaritani, de ha a beepitett lemezkezelovel (Disk Utility) keszitek imaget, akkor mar nem. Ugyonigy ha letoltom az Xcode gigantikus tomoritett allomanyat es duplakattintassal kibontom, akkor sem takarit, csak menetkozben szol, hogy betelt a lemez, mikozben meg a sajat allitasa szerint 80 giga ures. Szoval, en szivesen megszabadulnek ettol a featuretol, de nem tudok :(.

Ez kb akkora hülyeség mint, hogy a bankok a folyószámlán lévő hitelkeretet pluszként mutatják, mintha a te pénzed lenne, hogy költsd nyugodtan, van rajta még 200ezer. Ha lehetne állítani hogy ne így mutassa, egy szavam nem lenne, de nem lehet és amikor rákérdeztem, azt mondták ez ilyen és így is fog maradni.

Igen, es nem :( A filekezeloben ha tallozgatsz, akkor mindenhol a "Free" + "Purgeable" terulet osszeadott mennyiseget jelzi. Ha kimondottan rakattintassz a drive "properties" abakara, akkor ott mar ugy irja, hogy "Available: 126 GB (89.67 GB purgeable)", ez mar egy kicsit kozelebb van. Ha elinditod a lemezparticionalasra szant segedprogramot (Disk Utility), meg abban is ugyonezt irja alapbol, viszont ha itt megnyitod a particiod "properties" ablakat (ez nalunk egyebkent a Get Info), akkor itt mar hajlando kiirni, hogy 35 290 923 008 byte ures... Szoval nem, egyszeruen nem lehet ravenni, hogy a tenyleges szabad helyet irja. 

Mivel a terminalban futo, eredendoen nem MacOS dolgoknak lovesuk sincs errol a "trukkrol", ezert ott minden command a valodi helyet latja uresnek. 

Telepítőnél és egyéb rendszerszintű dolgoknál teljesen mindegy, hogy mit ír ki a GUI. Erősen remélem, hogy a (rendszer)programozó urak Cupertino-ban nem végfelhasználóknak mutogatott ikonokból tájékozódnak, hanem API által biztosított rendszerfüggvények visszatérési értékeiből. Olyasmiből, mint amit mondjuk a Win32 API biztosít:

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/

trey @ gépház

Meglepo, de ugy latom, hogy azok a filesystem API-k, amik leteztek a "purgeable space" kitalalasa elott (10.12 ota, azaz kb 7 eve van velunk ez a hulyeseg), azok leteznek most is es a valodi, szabad helyet adjak vissza. Ugyonakkor le van irva a dokumentacioban, hogy ne hasznald, mert van helyette modernebb, jobb. Ami van helyette, az pedig nyilvan mar el ezzel, a purgeable hulyeseggel, igy tobb helyet ad vissza, mint amit kellene. Ha rosszmaju akarnek lenni, akkor azt mondanam, hogy odakerult a telepito kodjahoz valami intern vagy newbie es rogton kigyalulta kodtisztitas cimszoval a regi kodot es kicserelte az uj, modern API hivasokra :D (nem kevesszer lattam en mar hasonlot).

Azt gondolnám laikusként, hogy ahogy én végellenőrzöm egy gyakornok munkáját, úgy ez megvan mondjuk az Apple-nél is. Nálunk pl. a végellenőrzési folyamat az ISO-ban definiált folyamatok szerves része. Azért ezt egy egyszerű diff átnézésével lehetne kezelni.

trey @ gépház

Ez kb. olyan, mintha elmennék az Ikeába egy szekrénysorért egy Suzuki Altoval, mert basztam előzetesen, az indulás előtt ellenőrizni, hogy a csomagok be fognak-e férni.

Ezt annyival súlyosbítanám még, hogy mindezt nem úrvezetőként, hanem hivatásos teherfuvarozóként tenném ... :D :D :D 

trey @ gépház

Igazából ellenőrzi, csak nem egészen / nam mindenhol jól.

Párom gépénél visszadobta a Big Sur update-et, mert nem volt elég hely (kb 3 hete történt, szóval gondolom ott még a régi verzió futott).

Amint legyaktam pár videót, hogy cipőkanálal éppen elég hely volt (pár MB-al több csak, mint amit kért), szépen fel is ment.

Virtualis gepben ellenoriztem, az van, amire gondoltam. Ha a "Free + Purgeable" terulet kevesebb, mint ami szukseges, akkor szol, hogy nincs eleg hely. Ha a "Free" tobb, mint amire szukseg van, akkor gond nelkul telepul. A gond akkor van, ha a "Free" kevesebb viszont a "Free + Purgeable" tobb, mint ami kell, mert akkor elkezdi a telepitest viszont hibara fut (elfogy a tenyleges "Free") es maga ala szarik. 

VmWare alatt mar az elso 10.4-es kikerult Tiger/x86 verziok ota van lehetoseg Macet futtatni. 10.7 ota pedig trukkozes nelkul is mennie kellene (legalabbis OS X alatt 10.7-tol kezdve nem kell kuzdeni, meg telepitot moddolni, ha az ember OS X-et akar virtualizalni). Viszont mivel nincs grafikus gyorsitas, az OS pedig az utolso pixelig tamaszkodik erre, ezert mar egy bongeszo hasznalata is kinkeserves kuzdelemme valtozik. Az olyan nyalanksagokrol, mint iOS Simulator, vagy pl a Photos app, ne is beszeljunk. Ezeknel mar nincs failback sem SW renderelt modra. Szoval ha van telepitod, szerintem annak be kellene tudnia bootolnia EFI-t valasztva firmware tipusnak. 

Milyen szoftvert probalnal ki egyebkent?

Próbáld ki ezt: https://www.funkyspacemonkey.com/updated-how-to-install-macos-big-sur-w…

A big sur-t nem próbáltam még, de Catalina az működött nálam egy ugyanilyen leírás alapján Ubuntun, amikor éppen Safari alatti problémákat akartam megnézni. Akkor ez alapján tettem fel: https://www.funkyspacemonkey.com/how-to-install-macos-catalina-on-linux

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Annyira nem elemeztem, hogy mit csinál, csak kellett gyorsan egy Safari egy ügyfél hibabejelentés miatt, arra meg tökéletes megoldás volt. Használni nem használom, mert egyszerűen képtelen vagyok összebarátkozni a MacOS-el, pedig többször nekifutottam pozitív szemlélettel is :) Legutóbb pár napja vagy 2-3 órán át nyomogattam egy M1 chipes MacBook Air-t, de képtelem voltam még csak megközelítőleg hasonlóan kézreállóra beállítani, mint a WMaker :)

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Köszi, tényleg működni látszik:
- 45 GB-ot igényelt a telepítés
- Lassú nagyon, de valami alapvető tesztelésre jó lehet (az egérkurzort általában követi a megjelenítés).
- egyelőre amit próbáltam rajta, az ment pöccröff, semmi gyanús kompatibilitási problémát nem láttam.