Samstag, 17. Juni 2023
Das geht, aber erfordert DSM 7 sowie die Installation eines offiziellen, kostenlosen Pakets namens … exFAT Access:
Can I use exFAT external storage devices with my Synology NAS?
Eine unter macOS als exFAT formatierte USB-Festplatte wurde nach der Installation des Pakets umgehend erkannt und unter usbshare1 gemountet.
Montag, 2. Januar 2023
Die Feiertage sind für mich auch immer der Zeitpunkt, um mal wieder so richtig aufzuräumen. Dieses Jahr — ein Jahr nach dem Umzug — war der Keller dran. Unter anderem ging es Bundesordnern mit Unterlagen seit Mitte 1990er bis 2011 an den Kragen.
Mit meinem Fujitsu ScanSnap iX 1500 wurden alle Blätter gescannt, danach lief mit ABBYY FineReader PDF for Mac die OCR-Texterkennung darüber, und schlussendlich habe ich die PDFs auf dem lokalen Laufwerk abgelegt.
Ein Ordner enthielt auch CDs und DVDs für Web-Projekte der späten 1990er und frühen 2000er. Zum Glück hatte ich mir — in weiser Voraussicht — vor einiger Zeit ein Apple SuperDrive (A1379) gekauft, welches mit USB an beliebige Computer angeschlossen werden kann.
Bevor ich also die CDs und DVDs entsorgte, wollte ich die Daten damit ebenfalls auf den lokalen Computer sichern.
Erkenntnis: Von ungefähr einem Dutzend CDs und DVDs waren alle (!) noch lesbar. Bei zwei Datenträgern motzte macOS aber, dass diese ein „nicht unterstützes Format“ aufweisen (Nachtrag: Vermutlich weil unter Mac OS 9 gebrannt).
Ich entschied mich, noch nicht aufzugeben, und das Laufwerk an einen Linux-Laptop anzuschliessen. Das war aber gar nicht so einfach: Das Laufwerk machte zwar kurz ein Geräusch, nachdem es an USB angeschlossen wurde, doch die CD wurde nicht eingezogen.
Am USB-Bus wurde das Gerät angezeigt:
# lsusb ... Bus 002 Device 011: ID 05ac:1500 Apple, Inc. SuperDrive [A1379] ...
Nach etwas Recherche dann die Lösung:
Quelle: Apple’s SuperDrive tweak for use with Linux, Use Apple’s USB SuperDrive with Linux,
Tags: Apple, CD, CD-ROM, Debian, DVD, DVD-ROM, Linux, mount, SuperDrive, umount, USB
Labels: Apple, IT
Montag, 13. April 2020
Gestern half ich einer Bekannten, ihr HP ProBook 6570b mit einer vom Software-Hersteller nicht mehr unterstützten Windows 7 Professional-Installation auf Windows 10 zu lüpfen.
Diese unsägliche Upgrade-Odyssee bestätigte mir wieder einmal, dass mein Entscheid 2004 richtig war, Windows den Rücken zu kehren und auf Mac OS X (heute: macOS) sowie Debian GNU/Linux zu setzen.
Frickelmässig hat sich im Umgang mit Windows kaum etwas geändert — mit Backup-Image, dateibasiertem rsync-Backup, Installationsdatenträger herunterladen und erstellen sowie drei (!) Installationsversuchen (Stichwort: 0x800f0955 - 0x20003 und „The installation failed in the SAFE_OS phase with and error during INSTALL_UPDATES operation.“) habe ich gut und gerne 12 Stunden verbraten.
Ein kleines Problem ganz zu Beginn: Der USB-Installationsdatenträger, ein 8GB USB-Stick, wurde vom HP BIOS anfänglich nicht als Bootquelle aufgeführt (beim Booten ESC drücken, dann F9). Nach viel Haare ausreissen dann die Erkenntnis auf Grund eines Tipps in einem Forum: Ich hatte den Datenträger an einem der zwei SS (SuperSpeed) USB-Anschlüsse auf der rechten Seite des Geräts angeschlossen. Das BIOS erkennt aber nur USB-Datenträger, die am linken USB/eSATA-Anschluss angeschlossen werden.
Wie bescheuert ist das denn?!
Tags: 6570b, Boot, bootable, booten, Hewlett Packard, HP, Microsoft, ProBook, SS, SuperSpeed, USB, USB2, USB3, Windows 10, Windows 7
Labels: IT
Sonntag, 13. Januar 2019
Über die Jahre hat sich bei uns so einiges an portabler Elektronik angesammelt, welche Strom frisst und dementsprechend regelmässig geladen werden muss. Aus diesem Bedürfnis hat sich folgende Ladestation am Eingang zu unserer Wohnküche entwickelt:
Was erkennt man auf diesem Photo?
Tags: AirPods, Base, Baseus, Bose, DC-50, DT-900, DT-901, EXPEDIT, Fatboy, IKEA, iPad, iPhone, iPhone X, KALLAX, Ladekabel, Ladestation, Logitech, Nokia, Qi, RINNIG, USB
Labels: IT, Shopping
Dienstag, 16. Oktober 2018
Von meinem Dashboard, meinem ganzen Stolz über all die Jahre, habe ich hier ja bereits mehrere Male berichtet (Ausgangspunkt).
Seit Juni 2016 verwende ich zum Betrieb des Dashboards einen Raspberry Pi 3 — und wahrscheinlich genau so lange hat das Ding mir auf dem Bildschirm einen gelben Blitz angezeigt:
Bis letzte Woche hatte ich keinen blassen Schimmer, was dieses Symbol zu bedeuten hat — nerven tat es auf jeden Fall. Doch dann stolperte ich auf Grund folgender Fehlermeldung im Debian Kernel Log (unter /var/log/kern.log) …
... Oct 9 05:00:06 DASHBOARD kernel: [ 2.116304] Under-voltage detected! (0x00050005) Oct 10 05:00:08 DASHBOARD kernel: [ 2.089827] Under-voltage detected! (0x00050005) Oct 11 05:00:07 DASHBOARD kernel: [ 2.080389] Under-voltage detected! (0x00050005) Oct 11 05:17:06 DASHBOARD kernel: [ 2.080005] Under-voltage detected! (0x00050005) Oct 11 05:17:04 DASHBOARD kernel: [ 2.071669] Under-voltage detected! (0x00050005) Oct 11 05:17:04 DASHBOARD kernel: [ 2.089371] Under-voltage detected! (0x00050005) ...
… über folgenden Artikel:
If a lightning bolt image appears in the top-right corner of the screen, it means Raspberry Pi is not getting enough voltage (4.65V according to this forum post).
Quelle: Lightning Bolt (Under-Voltage Warning) on Raspberry Pi
All die Jahre erschien dieses Symbol, aber ich realisierte nicht, dass mir mein RPi3 etwas Wichtiges damit sagen wollte!
Ich hätte das Problem wie im Artikel beschrieben mit der Quick-and-Dirty-Symptombekämpfungslösung wegmachen können (avoid_warnings=1-Eintrag in /boot/config.txt), doch ich war an der tatsächlichen Lösung des Problems interessiert: Mehr Volt für meinen RPi!
Der Raspberry Pi hängt seit 2014 an einem AOC E2460SHU Monitor, für welchen der Hersteller mit einem roten und einem Power-Schriftzug markierten USB-Anschluss wirbt (Direktlink auf das Bild). Daran konnte es doch nun kaum liegen?!
Zu Beginn der Recherche machte ich den Fehler, dass ich nach Lösungen für zu wenig Ampere (Strom) über den USB-Bus suchte. Dabei stiess ich auf folgendes Kabel („Dual Input USB Power“) und war kurz davor, es zu bestellen — bis ich mir noch einmal die Fehlermeldung zu Gemüte rief. Dort liest man nichts von „under-current“, sondern von „under-voltage“, das heisst zu tiefer Spannung!
Nach wenigen Minuten stiess ich auf unzählige Forumsbeiträge zum Thema; einen Interessanten hier:
Stutzig wurde ich, als in mehreren anderen Forenbeiträgen empfohlen wurde, nicht zuerst die Stromquelle selber als Problem zu vermuten, sondern auch das verwendete USB-Kabel genauer anzuschauen und gegebenenfalls auszuwechseln. Begleitet wurden diese Empfehlungen von Rückmeldungen vieler Benutzer, die rein mit dem Austausch des Kabels die Meldung weggebracht hatten.
Doch wieso ist das so? Folgende zwei Artikel geben Auskunft über das Phänomen:
In vielen Fällen rührt das Problem davon, dass man keine qualitativ hochstehenden USB-Kabel verwendet (ja, ich weiss, vergoldete HDMI-Kabel für 99 CHF …). Das heisst anstelle von explizit „Charging Cable“ genannten Waren nur „Data Cables“. Das Problem der qualitativ minderwertigen Kabel ist, dass sie einen zu kleinen Querschnitt und somit einen zu hohen Widerstand haben. Dies führt dazu, dass die 5V Betriebsspannung am USB-Anschluss (der Stromquelle) bis zum RPi problemlos um 0.25V bis über 0.5V abnehmen kann — und somit wie oben genannt weniger als 4.65V beim Raspberry Pi ankommen (Grafik).
Kann wirklich das USB A-auf-USB Mikro-Kabel das Problem sein?! Offenbar schon, wenn man folgenden Artikel in einem RPi-Forum durchliest: Best Micro USB cables
Ein gutes Kabel erkennt man, wenn es einen Aufdruck mit einem numerisch tiefen AWG-Wert enthält.
Zurück von der Arbeit durchsuchte ich meinen USB Mikro ZIP-Lock-Sack. Rasch musste ich feststellen, dass kaum (mehr) Kabel einen AWG-Wert angeben. Einige wenige Kabel hatten einen Aufdruck, und ich machte mich daran, das bis heute genutzte USB-Kabel des RPi auszutauschen.
Kabel Nummer 1:
Kabel Nummer 2:
Kabel Nummer 3:
Ich muss noch bemerken, dass ich das Kabel seit langem nicht mehr direkt in den USB-Port des Monitors einstecke, sondern noch ein USB-Winkelstück (90 Grad; männlich, weiblich) gekauft habe, damit das Kabelende nicht so hässlich am oberen Ende des Monitors heraussticht. Ein solches Stück kann selbstverständlich auch noch zu Spannungsverlusten führen; in meinem Fall ist der Verlust zusammen mit einem qualitativ hochstehenden Kabel aber offenbar vernachlässigbar.
Leider sind die Kernel-Meldungen nicht ganz weg. Seit Austausch des Kabels habe ich in kern.log folgende Einträge gefunden:
... Oct 16 19:18:55 DASHBOARD kernel: [ 370.259369] Under-voltage detected! (0x00050005) Oct 16 19:20:06 DASHBOARD kernel: [ 440.980952] Under-voltage detected! (0x00050005) Oct 16 20:31:53 DASHBOARD kernel: [ 4748.658891] Under-voltage detected! (0x00070005) Oct 16 20:38:41 DASHBOARD kernel: [ 5156.348023] Under-voltage detected! (0x00050005) Oct 16 20:49:53 DASHBOARD kernel: [ 5828.208492] Under-voltage detected! (0x00070005) Oct 16 20:53:00 DASHBOARD kernel: [ 6015.403857] Under-voltage detected! (0x00070007) ...
Tags: 0x00050005, 4.65V, Ampere, AWG, kern.log, Mikro, RPi, RPi3, Spannung, Strom, Under-voltage, USB, Volt
Labels: IT, Linux
Sonntag, 8. Juli 2018
Seit Jahr und Tag bin ich auf der Suche nach einer Daten-SIM-Karte, welche ich als Out-of-Band-Lösung in meinen drei Netzwerk-Standorten installieren kann.
Die SIM möchte ich in ein UMTS-Modem einbauen, welches ich entweder extern per USB oder intern per Einbau an den ThinkPad-„Server“ der jeweiligen Location anhänge.
Fällt das Internet aus, oder verliere ich aus irgendeinem Grund den Remote-Zugriff ins LAN, aktiviert sich die SIM-Karte von alleine, meldet seine IP bei einem Dienst wie DynDNS, öffnet einen VPN-Tunnel und bietet mir so die Möglichkeit, Probleme aus der Ferne zu diagnostizieren.
Mit SimplyMobile von Swisscom scheint das nun Realität zu werden:
Quelle: SIMPLYMOBILE PREPAID
Fazit: Das Basteln kann beginnen!
Tags: M2M, Machine-to-Machine, OOB, Out-of-Band, Redundanz, SIM, SimplyMobile, UMTS, USB
Labels: IT
Samstag, 10. Februar 2018
Kürzlich habe ich dank der Funktion dmidecode nicht nur herausgefunden, wie ich aus der Ferne feststellen kann, um welchen Gerätetyp es sich bei einem Laptop-Server konkret handelt …
... Handle 0x000E, DMI type 1, 27 bytes System Information Manufacturer: LENOVO Product Name: 4236MBG Version: ThinkPad T420 Serial Number: XXXXXXX UUID: 045E0181-510B-110B-BEFD-D0C20D7188AE Wake-up Type: Power Switch SKU Number: Not Specified Family: ThinkPad T420 ...
… sondern auch, dass die BIOSse meiner Thinkpad-Flotte wohl mal aktualisiert werden sollten:
... BIOS Information Vendor: LENOVO Version: 6QET69WW (1.39 ) Release Date: 04/26/2012 ...
Erstaunlicherweise unterhält Lenovo seine Support-Seiten vorzüglich und es fanden sich innert weniger Minuten alle Seiten mit BIOS-Updates für meine Thinkpads X200s, X201, T400 und T420.
Da auf den Dingern kein Windows läuft, kann man das Update über diesen Weg vergessen. Glücklicherweise bietet Lenovo auch noch CD-Images (sog. ISOs) an, mit welchem die ca. 40MB Updatedaten auf CDs gebrannt werden können. Der Laptop kann dann von dieser CD gestartet und die Updates installiert werden, d.h. die Anforderung Windows entfällt so.
Erstes Problem: Die Links auf die ISO-Images auf den Seiten mit dem „BIOS Update Utility for Windows“ funktionieren nicht. Hier hilft Google jeweils kurzerhand weiter: „X200s BIOS Update Bootable CD“ findet dann den korrekten Link der Seite.
Nachdem man sich von dort die ISOs heruntergeladen hat und sie bspw. (graphisch) mit Etcher (oder auf dem CLI mit dd) unter macOS auf einen USB-Stick schreiben will, ein weiterer Showstopper: Etcher meldet nach dem Transfer, dass der USB-Stick kein gültiges Dateisystem enthält.
Wie sich mit etwas googeln herausstellt verwendet Lenovo für seine Boot-CDs den El Torito-Standard. Deshalb muss man aus dem .iso mit dem Perl-Script geteltorito.pl das eigentliche Image extrahieren. geteltorito.pl findet sich unter Debian GNU/Linux im Paket genisoimage. Aus der Boot-CD des BIOS-Updates für ein Lenovo Thinkpad X201 extrahiert man das eigentliche ISO-Image folgendermassen:
#!/bin/bash /Users/mario/Scripts/cd-dvd/geteltorito.pl -o 6quj19us.img 6quj19us.iso exit 0
Auf der Kommandozeile liest man dann ungefähr Folgendes:
$ extract.sh Booting catalog starts at sector: 20 Manufacturer of CD: NERO BURNING ROM Image architecture: x86 Boot media type is: harddisk El Torito image starts at sector 24 and has 65536 sector(s) of 512 Bytes Image has been written to file "6quj19us.img".
Anschliessend schreibt man das .img folgendermassen auf einen USB-Stick, welcher als /dev/rdisk5 gemountet ist:
#!/bin/bash dd if=6quj19us.img of=/dev/rdisk5 bs=512k exit 0
Auf der Kommandozeile liest man dann ungefähr Folgendes:
# write.sh 32+0 records in 32+0 records out 33554432 bytes transferred in 6.970957 secs (4813461 bytes/sec)
Einige der folgenden Links waren für die Auskundschaftung dieser Alternative essentiell, andere (weiter unten) Sackgassen:
Während einer Stunde habe ich mir dann die Zähne ausgebissen — sowohl mit Etcher als auch mit dd habe ich diverse Images auf einen uralten SanDisk Cruzer USB-Stick mit 512MB geschrieben. Doch jedes Mal, als ich mein Testgerät, ein Lenovo Thinkpad T400, damit booten wollte, erschien die Fehlermeldung „Missing Operating System“.
Erst als ich den USB-Stick auswechselt und einen LaCie itsaKey mit 4GB verwendete, klappte das booten und updaten der Thinkpads reibungslos.
Derzeit bin ich der Meinung, dass dies irgendwie damit zu tun hat, dass der erste USB-Stick mit 512MB kleiner als eine CD mit 640MB ist und dadurch Probleme mit dem Boot-Programm im MBR entstehen. Oder aber dass vom SanDisk-Stick schlicht und einfach nicht gebootet werden kann, weil die Hardware des USB-Sticks das aus mir unerfindlichen Gründen nicht unterstützt.
Zum Schluss noch ein Screenshot, wie die Partition im Disk Utility.app angezeigt wird — mich erstaunt, dass „Bootable“ als „No“ angegeben wird, wobei ich nicht weiss, ob damit gemeint ist, dass Macs gebootet werden können:
Tags: BIOS, Boot, Etcher, Etcher.io, Lenovo, Thinkpad, Update, USB
Labels: IT
Sonntag, 5. November 2017
Als ich letzten Mittwoch meine Debian-Server mit den neuesten stable-Paketen aktualisierte hatte, kam es zu einem Kollateralschaden: Plötzlich wollte cacti die Gesundheitswerte meiner neuen, über USB an die Server angeschlossenen Eaton 3S550IEC resp. Eaton 3S700IEC USVs nicht mehr aufzeichnen.
Nach etwas Debugging dann rasch die Erkenntnis, dass dem Kommandozeilen-Tool zum Auslesen der Parameter der USVs eine bestimmte Datei fehlt:
$ upsc upsc: error while loading shared libraries: libupsclient.so.4: cannot open shared object file: No such file or directory
Dank der Suche nach dieser Shared Library in Paketen über packages.debian.org war dann schnell klar, dass ich folgendes Paket nachinstallieren musste:
apt-get install libupsclient4
Seither funzt die Aufzeichnung wieder:
Schade nur, dass die Eaton USVs nur den Ladestand der Batterie sowie die Auslastung in Prozent ausgeben …
Tags: cacti, Eaton, S3550IEC, S3700IEC, upsc, USB
Labels: Linux
Montag, 23. Oktober 2017
Unsere Wohnung ist (fast) eine DVD/CD-ROM-freie Zone. All unsere Endgeräte verfügen mittlerweile über kein optisches Laufwerk mehr.
Doch was nun, wenn man eine CD erhält, deren Daten man auf die Endgeräte laden möchte?
Man nimmt den herumliegenden Lenovo T400 zur Hilfe, welcher noch über ein CD-ROM-Laufwerk verfügt. Leider fehlt der guten Maschine die Festplatte, weil der auf AliExpress.com gekaufte Festplatten-Käfig sowie die Plasticschienen derzeit gerade aus China unterwegs in die Schweiz sind.
Damit man auf der Kiste also ein Linux zum Laufen kriegt, bootet man von einem USB-Stick, auf welchen die Netinst-Version von Debian 9.0 kopiert wurde. (tftp Netzwerk-Boot wäre noch ein Todo für die langen Winternächte).
Nach ein paar Kapriolen, um das Boot-Laufwerk auf USB umzubiegen, startet der Laptop mit der graphischen Installationsoberfläche. Dort wählt man unter Advanced Options den Rescue Modus ein (ohne graphische Benutzeroberfläche).
Nach viel zu vielen Dialogfenster hat man endlich eine Shell zur Hand. Sobald man die CD eingelegt hat, gibt man folgende Befehl ein:
# mkdir /mnt/cdrom # mount /dev/cdrom /mnt/cdrom
Unter /mnt/cdrom sieht man mit ls -l den Inhalt der CD.
Hat man den zweiten USB-Stick, auf welchen die Daten der CD kopiert werden sollen, bereits bei der Anzeige des Debian-Menus eingestöpselt, könnte man dem Rescue-System in einem Dialog-Fenster sagen, diesen Stick ebenfalls bereits zu mounten.
Hat man dies nicht gemacht, sucht man sich zuerst einen weiteren freien USB-Port am Gerät und steckt den USB-Stick ein.
Anschliessend sucht man sich mit fdisk -l den Devicenamen sowie den Namen der Partition hervor. Gleichzeitig sieht man auch, ob der Stick mit FAT16/32 formatiert ist — ich konnte in meinem Versuch nur solche Sticks mounten.
In unserem Fall trägt die Partition des USB-Sticks den Pfad /dev/sdb1, deshalb mountet man den Stick so:
# mkdir /mnt/usb2 # mount /dev/sdb1 /mnt/usb2
Anschliessend wechselt man auf das CD-Laufwerk und verwendet — leider, da rsync in dieser Umgebung fehlt — folgenden Befehl, um die Daten auf den USB-Stick zu kopieren:
# cd /mnt/cdrom # cp -R . /mnt/usb2
Doch OBACHT — nur weil der Kopierbefehl abgeschlossen ist, heisst das leider noch nicht, dass alle Daten bereits auf den USB-Stick geschrieben wurden:
USB write: delay between when Ubuntu says its done and it actually being done
Bevor man den USB-Stick ausstöpselt, muss man mit folgendem Befehl sicherstellen, dass auch wirklich restlos alle Daten auf den Stick geschrieben wurden:
# sync
Danach werkelt sync, was locker noch einmal ein oder zwei Minuten dauern kann.
Anschliessend kann man den Stick mit folgendem Befehl für die Entfernung bereitmachen:
# umount /mnt/usb2
Sobald dieser Befehl ausgeführt wurde, kann man den Stick aus dem USB-Port entfernen und auf einem Endgerät einstöpseln.
Tags: CD, CD-ROM, Debian, Drive, DVD, DVD-ROM, eject, fdisk, kopieren, Laufwerk, Linux, mount, Rescue, Sync, umount, USB
Labels: Linux
Donnerstag, 7. September 2017
Letzte Woche habe ich in Kalifornien einer Bekannten geholfen, einige Netgear Arlo Pro Überwachungskameras ums Haus herum zu installieren, um einen Obstdieb dingfest zu machen.
Mangels einer ausreichenden Menge an Steckdosen und Original-Ladegeräten wollte ich die Kameras an meinem treuen Reisebegleiter, dem USB-Ladegerät Aukey PA-T15 Quick Charge 3.0 54W mit insgesamt fünf USB A-Ports, aufladen.
Klappt leider nicht. Die LED der Arlo Pro Kamera leuchtete Orange (in der dortigen Landessprache „Amber“) und die Batterie wurde nicht aufgeladen.
Wie sich mit einem nach wenig googlen gefundenem Knowledgebase-Artikel herausstellte, verfügt die Kamera zwar über einen üblichen USB-Anschluss, erwartet aber satte 9V Spannung:
Quick Charge technology only works if you use a compatible Quick Charge power adapter and power adapter cable. A regular 5V Micro USB cable does not have high enough voltage to fully charge your Arlo Pro Wire-Free camera […] You must use the 9V Arlo Pro power adapter and power adapter cable that came with your Arlo Pro system
Quelle: What is Quick Charge and why does my Arlo Pro Wire-Free or Arlo Go camera use it?
Obwohl das Aukey-Ladegerät Quick Charge unterstützt, liefert es leider nur die üblichen 5V:
Quick Charge 3.0 – Charge compatible devices up to 4 times faster than conventional charging
Adaptively charges all 5V USB powered devices including Android and Apple devices at up to 2.4A
Tags: 5V, 9V, Arlo, Arlo Pro, Netgear, Quick Charge, USB
Labels: IT
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |
