![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2022\/02\/grafik-13.png\")
<\/a><\/figure>\n<\/div>\nWer Windows verwendet, muss die neue Version per Hand herunterladen und installieren. Allerdings erscheint ein Hinweisfenster beim Start einer veralteten Version:<\/p>\n
<\/a><\/figure>\n<\/div>\nEin Klick auf „Ja“ f\u00fchrt zur Downloadseite. Dort kann man die neueste Version f\u00fcr Windows, Ubuntu (Linux) und MacOS herunterladen.<\/p>\n
Verbesserung der „Erweiterten Optionen“<\/h2>\n
Die gr\u00f6\u00dften Verbesserungen gibt es in den „Erweiterten Optionen“. In vorherigen Beitr\u00e4gen zur Einrichtung habe ich ja schon \u00f6fter empfohlen, dass man mit STRG + SHIFT + X <\/strong>das Betriebssystem auf der Karte vorkonfigurieren kann. Vor allem bei Server-Installationen ohne grafische Oberfl\u00e4che ist das praktisch, da sich u.a. Hostname, WLAN und Passwort\/SSH-Schl\u00fcssel festlegen lassen. So braucht man keine an den Pi angeschlossenen Peripherieger\u00e4te.<\/p>\n Ein Kritikpunkt am Imager war von mir, dass diese erweiterten Optionen ziemlich versteckt und kaum dokumentiert sind. Beides wurde in 1.7 verbessert: Nach der Auswahl des Betriebssystemes erscheint rechts unten ein kleines Zahnrad. Die Tastenkombination funktioniert als Abk\u00fcrzung weiterhin – wer sie nicht kennt, findet die M\u00f6glichkeit dar\u00fcber trotzdem.<\/p>\n Mein zweiter gro\u00dfer Kritikpunkt zu dem es mittlerweile auch mehrere GitHub-Tickets gibt: Dieses Vorkonfigurieren funktionieren nur beim Raspberry Pi OS zuverl\u00e4ssig. Unter anderen Betriebssystemen kommt es zu mehr oder weniger schweren Problemen. <\/p>\n Ein Beispiel: Ich habe angefangen Ubuntu auf dem Pi zu testen, das wurde im Forum von mehreren von euch gew\u00fcnscht<\/a>. Beim Starten schaltete sich der Bildschirm nach einigen Sekunden einfach ab. Wie sich nach einiger Fehlersuche herausstellte, lag das Problem am Imager. Das Skript zur Vorkonfiguration wirft dort einen Fehler, wodurch der Pi heruntergefahren wird. Schon alleine weil man die Bildschirmausgabe aufgrund der Geschwindigkeit nicht lesen kann, ein schwer zu findender Fehler. Seit mehreren Monaten gibt es Tickets dazu, jedoch bisher keine L\u00f6sung oder zumindest ein Hinweis.<\/p>\n Version 1.7 hat hier zwei wichtige \u00c4nderungen vorgenommen. Sie haben den neuen „Einstellungs“-Knopf nur noch f\u00fcr kompatible und wohl getestete Distributionen eingeblendet. Bei allen anderen wird er ausgeblendet:<\/p>\n Das ist schon mal sinnvoll, allerdings erscheint er nach wie vor \u00fcber das Tastenk\u00fcrzel. Hier w\u00e4re ein weiterer Hinweis praktisch, v.a. weil der Einstellungs-Knopf so neu ist. Immerhin gibt es damit aber zum ersten mal \u00fcberhaupt irgend eine sichtbare Anzeige, an der man erkennen kann, ob die Erweiterten Optionen unterst\u00fctzt werden.<\/p>\n Praktisch: Die Tastenkombination f\u00fcr die erweiterten Optionen wurde nun endlich dokumentiert. Am Ende der Readme befindet sich ein kleiner Absatz dazu. <\/p>\n Die zweite \u00c4nderung ist technischer Natur: F\u00fcr Ubuntu wird nun CloudiIit unterst\u00fctzt. Das ist ein Standard, um in einer Yaml-Datei alle notwendigen Einstellungen vorzugeben. Beim ersten Start wird sie ausgelesen und das System entsprechend konfiguriert. Ich habe mit CentOS unter Terraform bereits CloudInit verwendet. Das Format hat manchmal seine T\u00fccken, grunds\u00e4tzlich ist es eine sehr sinnvolle Idee. Damit sollten die Probleme l\u00f6sbar sein, sodass sich auch Ubuntu vern\u00fcnftig mit dem Imager flashen l\u00e4sst.<\/p>\n Zur Anpassung des Raspberry Pi OS wird noch auf systemd.run<\/strong> gesetzt. Der Kernel-Parameter erlaubt die Ausf\u00fchrung eines Shellskriptes beim Start. Funktioniert, hat sich in meinen Tests aber als fehleranf\u00e4llig herausgestellt. Au\u00dferdem kann man es nur unter Distributionen mit Systemd nutzen. Das ist heutzutage zwar die Mehrheit, doch es gibt Gr\u00fcnde, auf ein anderes Init-System zu setzen. Dies hat beispielsweise das schlanke Alpine Linux getan<\/a>. CloudInit wird zwar von einigen Distributionen unterst\u00fctzt, aber nicht von allen. Eine L\u00f6sung f\u00fcr alle Distributionen wird es wohl auf absehbare Zeit nicht geben.<\/p>\n Wie man dem Changelog zu Version 1.7<\/a> entnehmen kann, gibt es noch ein paar weitere \u00c4nderungen:<\/p>\n Etwas verwirrend ist die Ank\u00fcndigung, der Imager w\u00fcrde nun Telemetriedaten erfassen. Dies ist schon seit geraumer Zeit der Fall:<\/p>\n Auch die Dokumentation gibt es schon l\u00e4nger. Neu ist lediglich, dass die Daten an raspberrypi.com statt .org gesendet werden. Vermutlich ist das damit gemeint <\/p>\n Wenn ihr ein Image mit dem Imager auf eine Karte schreibt, wird Name, Adresse und Kategorie des Abbildes erfasst. Au\u00dferdem sammelt das Programm grundlegende Daten eures Computers wie Betriebssystem, Version, Prozessorarchitektur, Lokalisierung (Sprache und Land), die Imager-Version und Revision des Pi. Die Revision wird vmtl. nur dann erfasst, wenn man den Imager auf einem Pi startet – das ist ebenfalls m\u00f6glich, man kann ihn dort \u00fcber das Paket rpi-imager<\/strong> installieren.<\/p>\n Das ist – verglichen mit leider manch anderen Anwendungen – in meinen Augen noch durchwegs akzeptabel. Falls ihr diese Daten dennoch nicht senden m\u00f6chtet, beschreibt der Telemetrie-Abschnitt in der Readme<\/a>, wie man dies deaktivieren kann.<\/p>\n<\/a><\/figure>\n<\/div>\nKlarere Benutzeroberfl\u00e4che f\u00fcr andere Distributionen<\/h3>\n
<\/a><\/figure>\n<\/div>\nWeitere Verbesserungen und Fehlerkorrekturen<\/h3>\n
\n
Telemetrie: Telefoniert der Imager nach hause?<\/h2>\n
<\/a><\/figure>\n