Posts Tagged ‘macOS’

Dienstag, 26. April 2022

Firmware des MagSafe Battery Packs aktualisieren

Apple hat kürzlich ein Firmware-Upgrade 2.7.0 für sein MagSafe Battery Pack veröffentlicht, welches die Ladegeschwindigkeit von 5 Watt auf 7.5W erhöht.

MacRumors hat darüber berichtet und ein How To veröffentlicht.

Die Firmware aktualisiert man am Besten, indem man das Battery Pack mit einem Lightning-auf-USB-C-Kabel an einen Mac oder ein iPad anschliesst. Ausser anschliessen kann man nichts tun; das Update wird vom Betriebssystem anschliessend selbständig eingespielt.

Beim Battery Pack meiner Frau (Firmware-Version: 2.5.0b) klappte das Upgrade innert 1-2 Minuten nachdem ich es an mein MacBook Air M1 angeschlossen hatte.

Mein Battery Pack (Firmware-Version: 2.0.2c) hing mit demselben Kabel für ca. 15 Minuten an meinem Mac mini M1 (macOS Monterey 12.3.1), ohne dass sich etwas tat. Danach schloss ich es an das MacBook Air (macOS Big Sur 11.6.5) an, doch auch hier tat sich nach 10 Minuten nichts.

Ohne grosse Hoffnung schloss ich das Battery Pack schlussendlich noch an ein Lightning-auf-USB-A-Kabel an, welches am Thinkvision-Monitor meines Arbeitgebers angeschlossen ist. Der Monitor ist mit Thunderbolt/USB-C an einem älteren MacBook Pro (macOS Big Sur 11.6.5) angehängt.

Und siehe da: Nachdem ich einige Emails beantwortet hatte und das Battery Pack vergessen hatte, öffnete ich nach ungefähr 5-10 Minuten Apfel-Menu > About this Mac > System Report > USB, wählte das MagSafe Battery Pack in der Liste aus, und siehe da:

MagSafe Battery Pack:

  Product ID:	0x1399
  Vendor ID:	0x05ac (Apple Inc.)
  Version:	27.0b
  Serial Number:	DL2FJGDE0NLJ
  Speed:	Up to 12 Mb/s
  Manufacturer:	Apple Inc.
  Location ID:	0x01100000 / 1
  Current Available (mA):	500
  Current Required (mA):	500
  Extra Operating Current (mA):	1900
  Sleep current (mA):	2400

Wieso der Version ein Punkt fehlt, ist mir schleierhaft. Als Originalversion stand in diesem Dialogfeld 20.2c, beim Battery Pack meiner Frau 25.0b.

Tipp: Wer den System Report geöffnet hat, kann mittels Apfel-R den Baum neu anzeigen lassen. Sollte die Firmware in der Zwischenzeit aktualisiert worden sein, spiegelt sich dass im Feld Version entsprechend wieder.

Sonstige Links: Diskussion bei Apfeltalk, Meldung bei Heise sowie Allgemeiner Support-Artikel von Apple.

Tags: , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 6. März 2022

macOS Quick Look funktioniert nicht mehr richtig

Unter macOS Monterey 12.2.1 habe ich seit einigen Tagen das Problem, dass Finders Quick Look nicht mehr richtig funktioniert. Anstelle bspw. ein Video abzuspielen, wird nur das Thumbnail in einer etwas grösseren Form im grauen Overlay angezeigt.

Das Problem scheint bekannt. Die Lösung:

Im Activity Monitor den Prozess QuickLookUIService (Finder) beenden.

Danach funktioniert die Vorschau wieder wie erwartet.

Tags: , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 23. Januar 2022

iMac Late 2015 mit kaputtem Lüfter

Gestern Samstag-Abend: Vor dem-zu-Bett-gehen starte ich die Aktualisierung meines iMac 27 Zoll (iMac 17,1), Late 2015, Quad-Core i7, 24 GB, 2 TB von macOS Big Sur 11.6.1 auf 11.6.2. Ich habe das Gerät im Oktober 2017 für 1950 CHF gebraucht gekauft; da ist das Gerät gerade sieben Monate alt. Schnäppchen!

Heute Morgen ist das elektronische Postfach voll mit in Episoden an- und abklingenden monit-Meldungen. Als ich mich am Vormittag hinter das Gerät setze, ist schnell klar, dass etwas ganz und gar nicht stimmt. Es folgt ein Debug-Marathon, ursprünglich davon ausgehend, dass ich es mit einem Software-Problem zu tun habe. Im Laufe des Tages folgt das (widerwillige) Upgrade auf macOS Monterey, bis ich schlussendlich der Ursache des Ausfalls auf die Schliche komme:

Der im Innern des iMacs installierte Lüfter muss während — oder kurz nach — dem Betriebssystem-Upgrade kaputt gegangen sein.

Die Symptome:

  • Der Prozess kernel_task beansprucht knapp 500 Prozent der CPU-Leistung (siehe Link weiter unten)
  • In der Prozessliste findet man dutzende mds_stores Prozesse
  • Die Kiste läuft, plötzlich wird der integrierte sowie der angeschlossene Dell P2415Q-Bildschirm schwarz — und plötzlich startet der iMac ohne zu tun neu
  • Der per DisplayPort angeschlossene Dell P2415Q verliert andauernd das Signal
  • Jede Aktion im GUI dauert extrem lange — es fühlt sich an, als würde man einen 286er bedienen. Doppelklick, eine Minute warten. Alt-Tab, Sekunden vergehen bis die gewählte Applikation in den Vordergrund tritt
  • Die Eingabe über die Tastatur hakelt extrem — zwischen Tastendruck und Anzeige auf dem Bildschirm können Sekunden vergehen
  • Die Situation verbessert sich spürbar, wenn man das Kabel des externen Monitors abhängt
  • htop weist eine Load Average nördlich von 15 aus
  • Im /var/log/system.log (per SSH eingeloggt kann man das Gerät debuggen, ohne mit dem GUI kämpfen zu müssen) liest man verschiedene komische Meldungen …
    • … der Service mds (Spotlight-Indexierung) muss andauernd Indexierungsprozesse abschiessen. Auch das Deaktivieren von Spotlight mittels sudo mdutil -a -i off (Quelle) bringt nichts
    • … Apps finden Grafikkartentreiber nicht (nicht sicher, ob das wirklich ein echtes Problem ist): VTDecoderXPCService[558]: getattrlist failed for /Library/GPUBundles/AMDRadeonVADriver.bundle/Contents/MacOS/AMDRadeonVADriver: #2: No such file or directory und Dock[1242]: getattrlist failed for /Library/GPUBundles/AppleIntelSKLGraphicsVADriver.bundle/Contents/MacOS/AppleIntelSKLGraphicsVADriver: #2: No such file or directory
    • … immer wieder erscheinen com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): entering bootstrap mode und com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): exiting bootstrap mode
  • Die Ping-Latenz fluktuiert spürbar in einer Art Wellenform; von den erwarteten einstelligen Millisekunden bis zu dreistelligen Werten (siehe Anhang)

Obwohl sich dieser Stackexchange-Artikel und dieser offizielle Apple-Artikel auf (überhitzende) MacBook Pros bezieht, gibt er mir den wichtigsten Tipp: Hitze!

Und tatsächlich, das Gehäuse ist heiss. Und plötzlich erinnere ich mich, dass ich den Lüfter des iMacs verdächtig lange nicht (mehr) gehört habe. Normalerweise lief der täglich mehrmals an, insbesondere, wenn zwei Mal täglich Backups (rsync auf das Synology NAS, TimeMachine auf die TimeCapsule sowie mit Arq zu Backblaze) durchgeführt wurden.

Ich installiere mir die Software Macs Fan Control, welche den Verdacht bestätigt: Die aktuelle Umdrehungszahl beträgt (orange eingefärbt) 0. Minimal müssten eigentlich 1200 Umdrehungen gefahren werde. Ich schalte auf Full Blast (2850 Umdrehungen) — doch kein Wank, kein Geräusch, keine Zirkulation. Währenddessen sehe ich, dass die CPU-Temperatur bei 87 Grad angekommen ist.

Nachtrag: Das geht übrigens alles auch von der Kommandozeile, ohne Installation von Drittsoftware. Um die Temperaturen der CPU-Kerne auszulesen:

# powermetrics --samplers smc | grep -i "CPU die temperature"
CPU die temperature: 47.70 C
CPU die temperature: 46.17 C
CPU die temperature: 46.41 C
CPU die temperature: 46.48 C
CPU die temperature: 46.30 C
...

Um die Lüftergeschwindigkeit auszulesen:

# powermetrics --samplers smc | grep Fan
Fan: 0 rpm
Fan: 0 rpm
...

Und plötzlich macht alles Sinn: Die CPU droht zu überhitzen, weil sie der iMac mangels funktionierendem Lüfter nicht mehr kühlen kann. Deshalb schreitet nun kernel_task zur Tat: Er drosselt alle laufenden Prozesse, damit diese die CPU nicht weiter strapazieren. Für den Benutzer bedeutet das ein extrem träges System. Indem ich den externen Monitor abgehängt habe, läuft die GPU nicht mehr (so) heiss, was ebenfalls Linderung in der „finnischen Sauna“ im Innern des iMac bringt.

Rückblickend ein Wunder, dass ich Monterey während Stunden (!) tatsächlich installieren konnte und die Kiste dabei nicht gegrillt habe (geschweige denn einen Wohnungsbrand ausgelöst habe).

Ich trenne den iMac vom Strom, um den System Management Controller (SMC) zurückzusetzen (Quelle). Leider springt der Lüfter auch danach nicht mehr an. Damit sind alle Lösungsversuche, die auch unter folgender Frage beschrieben wurden, ausgeschöpft: iMac fans stopped, what must I do?

Die leider letzte verbleibende Lösung? Den defekten Lüfter austauschen — hilfreich könnte diese iFixIt-Anleitung sein. Ich habe aber keine Lust, an meinem iMac rumzumechen.

Nun habe ich mir als Ersatz einen Mac mini M1 bestellt.

Sobald das Ersatzgerät da ist, werde ich abklären, wie viel mich bei DataQuest DQ Solutions in Bern ein Austausch des Lüfters kosten wird (ich befürchte mehrere hundert Franken, da der ganze Mac auseinandergebaut und ein Ersatzlüfter eingebaut werden muss).

Dann werde ich mir überlegen müssen, ob ich das Gerät repariere, und falls ja, ob ich es danach wieder in Betrieb nehme, oder es auf Ricardo verkaufe. Vermutlich Letzteres: Die Zukunft gehört M1, und wahrscheinlich wäre das der richtige Zeitpunkt, auch auf dem Desktop den Wechsel zu vollziehen (diesen Text schreibe ich auf einem MacBook Air M1).

Anhang

64 bytes from 1.2.3.4: icmp_seq=11856 ttl=64 time=5.659 ms
64 bytes from 1.2.3.4: icmp_seq=11857 ttl=64 time=5.565 ms
64 bytes from 1.2.3.4: icmp_seq=11858 ttl=64 time=8.133 ms
64 bytes from 1.2.3.4: icmp_seq=11859 ttl=64 time=6.890 ms
64 bytes from 1.2.3.4: icmp_seq=11860 ttl=64 time=6.753 ms
64 bytes from 1.2.3.4: icmp_seq=11861 ttl=64 time=14.673 ms
64 bytes from 1.2.3.4: icmp_seq=11862 ttl=64 time=52.217 ms
64 bytes from 1.2.3.4: icmp_seq=11863 ttl=64 time=101.217 ms
64 bytes from 1.2.3.4: icmp_seq=11864 ttl=64 time=153.161 ms
64 bytes from 1.2.3.4: icmp_seq=11865 ttl=64 time=11.308 ms
64 bytes from 1.2.3.4: icmp_seq=11866 ttl=64 time=6.809 ms
64 bytes from 1.2.3.4: icmp_seq=11867 ttl=64 time=9.474 ms
64 bytes from 1.2.3.4: icmp_seq=11868 ttl=64 time=5.172 ms
64 bytes from 1.2.3.4: icmp_seq=11869 ttl=64 time=6.211 ms
64 bytes from 1.2.3.4: icmp_seq=11870 ttl=64 time=7.839 ms
64 bytes from 1.2.3.4: icmp_seq=11871 ttl=64 time=5.575 ms
64 bytes from 1.2.3.4: icmp_seq=11872 ttl=64 time=5.559 ms
64 bytes from 1.2.3.4: icmp_seq=11873 ttl=64 time=20.077 ms
64 bytes from 1.2.3.4: icmp_seq=11874 ttl=64 time=60.732 ms
64 bytes from 1.2.3.4: icmp_seq=11875 ttl=64 time=107.225 ms
64 bytes from 1.2.3.4: icmp_seq=11876 ttl=64 time=159.577 ms
64 bytes from 1.2.3.4: icmp_seq=11877 ttl=64 time=6.760 ms
64 bytes from 1.2.3.4: icmp_seq=11878 ttl=64 time=13.282 ms
64 bytes from 1.2.3.4: icmp_seq=11879 ttl=64 time=15.027 ms
64 bytes from 1.2.3.4: icmp_seq=11880 ttl=64 time=6.770 ms
64 bytes from 1.2.3.4: icmp_seq=11881 ttl=64 time=4.986 ms
64 bytes from 1.2.3.4: icmp_seq=11882 ttl=64 time=5.948 ms
64 bytes from 1.2.3.4: icmp_seq=11883 ttl=64 time=8.361 ms
64 bytes from 1.2.3.4: icmp_seq=11884 ttl=64 time=5.632 ms
64 bytes from 1.2.3.4: icmp_seq=11885 ttl=64 time=21.801 ms
64 bytes from 1.2.3.4: icmp_seq=11886 ttl=64 time=66.570 ms
64 bytes from 1.2.3.4: icmp_seq=11887 ttl=64 time=109.075 ms
64 bytes from 1.2.3.4: icmp_seq=11888 ttl=64 time=153.075 ms
64 bytes from 1.2.3.4: icmp_seq=11889 ttl=64 time=10.720 ms
64 bytes from 1.2.3.4: icmp_seq=11890 ttl=64 time=8.682 ms

Tags: , , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 23. November 2021

Xerox B215 druckt gelegentlich, aber reproduzierbar Zeichensalat

Seit längerem habe ich das gelegentliche Problem, dass unser neuer Xerox B215 Multifunktionslaserdrucker bei einigen Druckaufträgen unter macOS 11.6 Zeichensalat ausdruckt, und das über dutzende von Seiten.

Gestern war es wieder einmal so weit. Ich hatte eine zu druckende PDF-Datei, die bei jedem Druckauftrag solchen Zeichensalat produzierte.

Nach einigen Recherchen im Netz dann die Lösung: Printing gibberish or random characters in Xerox B215:

I’ve found that most of the problems were due to „Airprint Secure“. I disabled airprint and it seems to have reduced the cases.

Anstelle von (Secure) AirPrint habe ich den Drucker neben AirPrint nun mittels Internet Printing Protocol (IPP, Port 631) eingerichtet. Diesen neuen Drucker ausgewählt, und das PDF druckte auf Anhieb problemlos.

Tags: , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 14. Oktober 2021

OpenInTerminal meldet „Waiting…“

Vor einiger Zeit habe ich hier im Artikel Öffne Terminal mit dem aktuellen macOS Finder-Pfad über die macOS Finder-Erweiterung OpenInTerminal geschrieben.

Folgendes Problem tritt dabei periodisch auf: Klickt man auf das Finder-Icon, heisst es im aufklappenden Dialog lapidar „Waiting…“

Die Lösung, eine Antwort auf meinen Bug-Report: Option-Klick auf Finder und Relaunch anwählen.

Tags: , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 29. August 2021

/dev/disk unter macOS deutlich langsamer als /dev/rdisk

Kürzlich beim zurückschreiben eines SD-Card RPi Backups auf eine neue SD-Card:

Starting imaging './emeidi-dashboard.img' to /dev/disk4 ...
^C11128+0 records in
11127+0 records out
11667505152 bytes transferred in 3849.682711 secs (3030771 bytes/sec)
Done.

3030771 bytes/sec, das sind 2959 kilobytes/sec oder 2.89 megabytes/sec. Eine 32GB SD-Card schreibt man also in 11’072 Sekunden, das heisst … in unglaublich langen 3 Stunden.

Tags: , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. Mai 2021

setlocale: LC_ALL: cannot change locale

Seit ich mein MacBook Air mit M1-Chip und macOS Big Sur verwende, erhalte ich beim Login auf meinen Raspberry Pi 3 über SSH folgende Warnung zu Gesicht:

ssh dashboard
Linux DASHBOARD 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
Last login: Sat May  8 05:00:24 2021
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Ursache des Problems: en_US.UTF-8 ist in /etc/locale.gen kommentiert:

$ cat /etc/locale.gen | grep -v "^#"

en_GB.UTF-8 UTF-8

Somit die Datei öffnen, die Zeile mit en_US.UTF-8 suchen, ent-kommentieren, speichern und dann folgenden Befehl ausführen:

# locale-gen

Via: warning: setlocale: LC_ALL: cannot change locale

Beim nächsten Login erscheint die Fehlermeldung nicht mehr.

Tags: , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. März 2021

csshx läuft unter macOS Big Sur nicht mehr

Ich verwende csshx unter macOS gelegentlich, um mich gleichzeitig auf mehrere Linux-Maschinen zu verbinden und dann auf allen Maschinen dieselben Kommandos auszuführen.

Unter macOS Big Sur läuft csshx auf Anhieb nicht (mehr):

$ csshx
Unimplemented: POSIX::tmpnam(): use File::Temp instead at /System/Library/Perl/5.28/darwin-thread-multi-2level/POSIX.pm line 185.
Unimplemented: POSIX::tmpnam() at /usr/local/bin/csshX line 1130.
BEGIN failed--compilation aborted at /usr/local/bin/csshX line 1130.

Die Lösung:

$ defaults write com.apple.versioner.perl Version -string 5.18

Quelle: csshX not working on Mac OS Big Sur

Tags: , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 23. Februar 2021

iMac auf Mac mini M1 migrieren wird zu Mac mini M1 frisch aufsetzen

Vorweg: Apples macOS-Team hat hier mehrere Male grossen Mist gebaut. Unmöglich, dass ein Normalanwender diese Probleme selber lösen könnte.

Ein Bekannter hat sich kürzlich ein gebrauchtes iPhone 11 Pro geleistet.

Ein paar Tage nach dem Kauf nahm er Kontakt mit mir auf und fragte mich, wieso die Photos.app auf seinem iMac nur die Vorschaubilder der mit dem neuen iPhone geschossenen Photos anzeige, nicht aber das Original, wenn man es in der Grossansicht öffnet.

Der Fall war für mich rasch klar: HEIC. Beim iMac handelte es sich um das Early 2008-Modell, welches bis macOS El Capitan (10.11) aktualisiert werden konnte, welches vor fünf Jahren erschienen war. Unmöglich, dass die darunter laufende Photos.app HEIC versteht.

Selbstverständlich hätte ich den Bekannten nun anweisen können, das iPhone so zu konfigurieren, dass es Bilder anstelle im HEIC-Format als JPEG in iCloud Photos ablegt. Doch welcher verantwortungsbewusste ITler nutzt die Gunst der Stunde nicht, um einen solchen Bekannten zu überzeugen, doch den 13-jährigen iMac und das fünfjährige macOS mit etwas Modernem zu ersetzen?

Wir schauten uns auf Revendo kurz einige gebrauchte iMacs an, unter welchem Big Sur noch installierbar ist — doch angesichts des Wechsels der Prozessorarchitektur tendierte ich nach einem kurzen finanziellen Überschlag dazu, anstelle eines Intel-iMacs doch lieber einen Mac mini M1 mit einem höher auflösenden Bildschirm mit 22–24 Zoll Diagonale zu kaufen. Ein iMac M1 wäre mir lieber gewesen, doch dieses Teil wird wohl erst irgendwann einmal in diesem Jahr erscheinen.

Die Wahl fiel auf einen Mac mini M1 mit 8G RAM und 512GB SSD, sowie einen Dell P2421DC. Tastatur und Maus würde ich ihm schenken, da ich noch ein Magic Keyboard und eine Magic Mouse (beide mit Lightning-Ladeanschluss) herumliegen hatte.

Nachdem die Ware per Post eingetrudelt war, machte ich mich auf den Weg zum Bekannten, um die Migration vorzunehmen. Ich verband den iMac mittels Ethernet-Kabel mit dem Mac mini, startete auf beiden Geräten den Migration Assistant, und sagte dem Mac mini, dass er nun alle Kontos und Daten vom iMac herüberkopieren sollte. Der Vorgang benötigte über vier Stunden, angabegemäss mit einer Übertragungsrate von 20 MBit/s (dem iMac hatten wir vor einigen Jahren zum Glück eine SSD verpflanzt, sonst hätte der Kopiervorgang vermutlich noch deutlich länger gedauert). Da ich noch einen anderen Termin wahrnehmen musste, wies ich den Bekannten an, die Migration gelegentlich mitzuverfolgen und die Installation danach auf dem Mac mini abzuschliessen, sobald alle Daten kopiert worden sind.

Am Abend meldete der Bekannte, dass alles geklappt hätte, er nun aber ein Problem habe, das neueste macOS Big Sur-Update einzuspielen: Der Mac mini akzeptiere im Software Update-Dialog das Kennwort seines Benutzerkontos nicht — Logins nach einem Neustart funktionierten hingegen. Nichts half — Neustart, Kaltstart, neues Admin-Konto einrichten. Das Internet ist voll mit Geschichten zu diesem Problem.

Nach vermutlich einer Stunde hin und her sandte mir der Bekannte mit dem iPad angefertigte Bildschirmfotos des Migrationsassistenten (zum Glück hatte er diese selbst angefertigt, aber zu meinem Pech hatte er mir das bis 60 Minuten in den Supportfall nicht erzählt). Und da las ich zu meinem Schrecken:

Sorry. An error occurred while transferring your information.

Die Autorisierung zum Erstellen neuer Benutzer auf dem System konnte nicht erhalten werden.

Der Bekannte führte die Installation anschliessend fort, realisierte aber nicht, dass macOS ihn nun aufforderte, ein neues Benutzerkonto zu erstellen. Das tat er brav.

Als ich das realisierte, erklärte ich Abbruch der Übung. Der neue Ansatz für den nächsten Tag war: Mac mini M1 platt machen, macOS Big Sur fabrikneu installieren, Benutzerkonto manuell erstellen und die Daten von iMac dann manuell rüberkopieren.

Am nächsten Tag also die Plattmacherei: Ich bootete den Mac mini M1 in den Recovery-Modus, indem ich die Power-Taste betätigte und zehn Sekunden lang gedrückt hielt. Ich wechselte in das Disk Utility und löschte („Erase“) die zwei Macintosh HD- und die Data-Partition und formatierte sie als AFPS neu. Anschliessend liess ich macOS auch über die Recovery Console neu installieren.

Ich aktivierte den Mac mini, und danach wollte ich den initialen Benutzeraccount erstellen. Nachdem ich die Informationen in das Formular eingefüllt hatte, klickte ich auf „Continue“ … und dann passierte für gefühlte 10 Minuten lang nichts. Schlussendlich die Fehlermeldung:

Computer account creation failed

Your computer account could not be created with the name and password specified. Please try again.

Der Klick auf „Try Again“ brachte nix.

Nach einigen Recherchen im Netz dann die Erkenntnis, dass man in der schönen, neuen ARM64-Welt die Macintosh HD- und Data-Partition nicht einfach platt machen darf. Stattdessen müsse man den Mac mini in den Device Firmware Update (DFU)-Modus booten und einen Restore durchführen. Dazu sei ein USB-C auf USB-C-Kabel nötig, sowie ein zweiter Mac (egal ob Intel oder ARM).

Zum Glück gibt es in unserem Haushalt zwei MacBook 12 Zoll, davon eines in meinem Besitz. Dieses musste nun zusammen mit einem Original Apple USB-C-Ladekabel für den Restore herhalten.

Doch hier nun das nächste Problem: Den Mac mini in den DFU-Modus zu booten, ist mit vielen Fallstricken umgeben. Schlussendlich half dieses Video eines Dritten (wie peinlich, wenn Apples Supportseiten weniger helfen als YouTube-Videos):

Apple Configurator 2 muss aus dem App Store heruntergeladen und gestartet werden. Wichtig ist dann, das USB-C-Kabel vom MacBook an den USB-C-Anschluss direkt neben dem Ethernet-Port des Mac minis anzuschliessen. Anschliessend zieht man das Stromkabel aus dem Gerät, zählt auf fünf, drückt den Stromschalter und steckt während man den Schalter gedrückt hält das Stromkabel ein.

Apple Configurator 2 zeigt nun mit einem riesigen Symbol und dem Schriftzug DFU an, dass der Mac mini im DFU-Modus läuft.

Anschliessend klickt man mit der rechten Maustaste auf das Symbol und wählt Restore aus. Der Mac mini wird gelöscht, partitioniert und danach das aktuellste macOS heruntergeladen und frisch auf den Mac mini rüberkopiert.

Und endlich, bei diesem nun mehr dritten Anlauf den Mac mini aufzusetzen klappte die Installation endlich wie am Schnürchen: Ich konnte das Benutzerkonto einrichten und das Konto erhielt auch tatsächlich Administratorenrechte. Jetzt endlich läuft die Kiste, und wie!

Nachtrag

According to the small print in Apple’s Platform Security Guide, when you set up a new M1 Mac, or set one up after restoring it in DFU mode, the primary admin account created is special: it’s the Owner account of that Mac. During that inital setup, the Mac sends a request to Apple for that Mac’s signed Owner Identity Certificate (OIC). This is based on a private key generated in the Secure Enclave known as the Owner Identity Key (OIK).

Each M1 Mac has just a single OIK, and access to that is confined to that primary admin user of the internal SSD, who is thus its Owner.

Quelle: Last Week on My Mac: The perils of M1 Ownership

Tags: , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 1. Dezember 2020

Mehrere Unix Timestamps auf der macOS Kommandozeile in Daten umwandeln

Voraussetzung: MacPorts und das Utility gdate (unter Linux: date) (Teil des Pakets coreutils) sind installiert.

$ python -mjson.tool < netatmo.json | grep utc | cut -d ":" -f 2 | awk '{print $1}' | xargs -I '{}' gdate -d "@{}"
Mon Nov 30 22:28:06 CET 2020
Mon Nov 30 22:27:57 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:27:38 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 17:07:34 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:46 CET 2020
Mon Nov 30 22:07:42 CET 2020
Mon Nov 30 22:07:00 CET 2020
Mon Nov 30 22:07:07 CET 2020

Im vorliegenden Fall nahm mich Wunder, wann meine Netatmo-Sensoren das letzte Mal einen Wert an den Server übertragen hatten.

Mindestens zwei Stationen mit einer handvoll Sensoren haben den Wert seit gestern nicht mehr aktualisiert. Ich vermute auf Grund dieses Absturzes.

Hierzu lud ich über die Netatmo API das JSON mit den Daten aller meiner Stationen herunter, gab das JSON schön formatiert aus (ein Key-Value Pair pro Zeile), selektierte die Zeilen mit dem Attribut time_utc, isolierte deren Wert — die Unix Timestamp (ein Integer), entfernte die Leerzeichen vor und nach dem Wert und übergab die Liste der Werte mittels xargs dem Tool gdate zur Umwandlung in ein menschenlesbares Datum.

Tags: , , , , , , , , , , , , , ,
Labels: Apple, IT, Linux

Keine Kommentare | neuen Kommentar verfassen