Ultimate Boot CD

Ich möchte dieses Mal die ‚Ultimate Boot CD‘ empfehlen. Die Ultimate Boot CD (UBCD) ist eine zu einem ISO-Image für beschreibbare CD- beziehungsweise DVD-ROMs zusammengefasste Software-Sammlung, die allerlei Programme und Tools zur Analyse, Konfiguration und Benchmarking für die PC-Hardware-Komponenten enthält. Jedes dieser Programme ist zwar auch für sich als Freeware oder Open-Source-Programm aus dem Internet zu beziehen, wird aber durch die UBCD als eine umfassende Sammlung für einen einzigen Datenträger zusammen gestellt. Je nachdem, ob eines dieser Werkzeuge für eine Linux- oder DOS-Umgebung entwickelt wurde, wird bei Bedarf von dem Live-Medium ein kleines Linux oder FreeDOS gestartet.
Die Ultimate Boot CD beinhaltet neben Programmen für einen Stresstest des Prozessors, Diagnose-Programmen für das vollständige PC-System oder einzelner Komponenten wie Peripherie oder Arbeitsspeicher, auch jede Menge Werkzeuge, um bei Festplatten (oder anderen Speichermedien) den Bootmanager zu bearbeiten, Daten wieder herzustellen, Partitionen zu verwalten oder die Datenträger schlichtweg sicher zu löschen.

Allerdings ist die Zusammenstellung inzwischen so weit gewachsen, dass das ISO-Image mit 850 Megabyte fast schon nicht mehr auf einen CD-Rohling passt und man schon auf einen DVD-Rohling ausweichen muss. Dies muss aber dennoch nicht sein, da die Ultimate Boot CD so aufgebaut ist, dass es möglich, Programme oder Werkzeuge zu entfernen oder andere hinzuzufügen. Kurz: es ist möglich, sich den Umfang der Programme und Werkzeuge selbst individuell zusammen zustellen. Da aber immer mehr Standard-PCs inzwischen ohne optische Laufwerke ausgeliefert werden, bietet die Ultimate Boot CD auch die Möglichkeit, das ISO-Image auf einen USB-Stick zu übertragen.

Screenshot Ultimate Boot CD Version 5.3.9

Hintergrund, dass ich mich mit der Ultimate Boot CD beschäftigt habe, ist der, dass ich auf einem meiner Computer bei einer bestimmten Operation immer wieder einen ‚Segmentation Fault‘ Fehler (zu Deutsch Schutzverletzung) zurückerhalte. Die Gründe, warum auf einem Computer diese Schutzverletzungen entstehen, können aber sehr vielfältig sein. Ein Grund könnte sein, dass der Arbeitsspeicher fehlerhaft arbeitet, was wiederum auf einen Defekt des RAMs hinweisen könnte. Um nun zu prüfen, ob der RAM fehlerfrei arbeitet, wurde mir das Programm Memtest86 empfohlen. Sowohl Memtest86, als auch die als Open Source weiterentwickelte Variante Memtest86+, lassen sich von einem bootfähigen Wechseldatenträger wie USB-Stick oder CD-ROM an einem PC ausführen, bei dem der Arbeitsspeicher dann einem Stresstest unterzogen wird.
Da aber mein Computer mit der Schutzverletzung nicht über ein optisches Laufwerk verfügt, musste ich die ISO-Images von Memtest86(+) auf einen USB-Stick übertragen. Nur leider habe ich es nicht hinbekommen gehabt, die Images so auf den USB-Stick zu übertragen, sodass der Computer danach von diesem auch tatsächlich bootete. Und so ruhte dann das Vorhaben, diesen Computer einem RAM-Stresstest zu unterziehen, um herauszufinden, ob der Arbeitsspeicher nicht vielleicht die Ursache ist.
Nach einigen Wochen bin ich aber nun zufällig auf einen YouTube-Kanal gestoßen, in dessen Videos der Protagonist sich regelmäßig mit („älterer“) PC-Hardware auseinandersetzt. Dabei verwendet er durchwegs die Ultimate Boot CD, die er auf seiner Hardware für Fehlerüberprüfungen der Komponenten einsetzt. – Und eben auch das Programm Memtest86+ um den Arbeitsspeicher zu überprüfen. Also unternahm ich einen erneuten Versuch, meinen Computer mit der Schutzverletzung einem Stresstest für den Arbeitsspeicher unterziehen zu wollen.

Im Prinzip gibt es zwei Varianten, wie man die Ultimate Boot CD auf einen USB-Stick überträgt. Die eine ist ein Batch-Script, mit welchem ein USB-Stick formatiert und die Programmdaten von dem Ultimate Boot CD-Image übertragen werden. Trotz der gegebenen Voraussetzung, dass dieses auf einem Computer mit Windows 7 von mir ausgeführt wird, hat dies trotz mehrmaliger Versuche leider nicht funktioniert.
Die zweite Variante ist das Formatieren und Übertragen der Image-Dateien unter Hilfenahme des Programms ‚Bootable USB drive preparation tool‘ (kurz RMPrepUSB). Mit diesem kleinen Programm konnte ich dann die Ultimate Boot CD auf einen USB-Stick übertragen, meinen Computer mit der Schutzverletzung von diesem booten lassen und endlich den Arbeitsspeicher dem Stresstest von Memtest86+ unterziehen.

Links:

Backup-Shellscript für diesen Webserver

Vor einem Monat fiel diese Seite ja einem WordPress Redirect Hack zum Opfer. Ein verwendbares Backup war gut zwei Jahre alt, was insofern für mich gut war, dass ich der Manipulation des Blogs nachgegangen bin und selber wieder korrigieren konnte. Hätte ich ein aktuelles Backup gehabt, dann hätte ich vermutlich recht schnell den Restore durchgeführt und wäre dann wieder auch wieder in dasselbe Problem gerannt. Aber, es ist trotzdem wichtig, dass man regelmäßig Backups erstellt. Da durch die Piwigo-Fotogalerie die ich als Unterverzeichnis vom Blog angelegt habe, das gesamte Verzeichnis nun sehr viel Speicherplatz benötigt, komme ich mit der kostenlos-Variante vom WordPress-Plugin Duplicator nicht mehr weiter. – Mal ganz davon abgesehen, dass ich den Einsatz von Plugins doch von Anfang an etwas kritisch gesehen habe und mit dem Hack diese Haltung eher noch verstärkt hat.

Da ich mir für dieses Blog bei meinem Hoster nun keinen reinen Webspace, sondern eine virtuelle Computerinstanz mit einem Linux gebucht habe, stehen mir dadurch auch alle üblichen Kommandozeilenwerkzeuge und Programme zur Verfügung, mit denen ich mir mein eigenes Backup-Programm in Form eines kleinen Shellscripts basteln kann. Das ist dann spätestens jetzt die Gelegenheit sie auch mal zu nutzen. Und so habe ich inzwischen einen ersten funktionierten Entwurf im chaos.expert GitLab veröffentlicht, in der Hoffnung, dass ich es schaffe, mit der Zeit etwas auszubauen und zu optimieren. – Auf jedem Fall wird dieses Shellscript mittels einen Cron-Jobs einmal wöchentlich aufgerufen und es sollen immer die letzten vier Archive für einen Restore auf der Instance lokal gespeichert bleiben. Sprich: Kommt ein neues Archiv hinzu – es muss dann schon wenigstens das „Fünfte“ sein, wird dann das älteste Archiv wieder gelöscht.

Für den Fall dass die komplette virtuelle Linux-Server-Instanz ohne Ersatz offline geht und bei meinem Hoster gekündigt wird, muss ich mir noch ein Konzept für die dezentrale Speicherung der Archive überlegen, falls ich zu einem späteren Zeitpunkt den Webserver mit den alten Inhalten wieder online bringen möchte. Es soll also spannend bleiben!

Links:

Kobo Hacking Teil 3 – Der fertige, digitale Bilderrahmen

Neulich habe ich mal durch meine alten Blog-Beiträge durchgeblättert um zu schauen, worüber ich alles so bisher geschrieben habe. Dabei bin ich im Konkreten wieder auf zwei Artikel gestoßen, in denen ich beschreiben habe, wie sich der eBook-Reader Kobo Mini Touch „hacken“ ließ, um Zugang zum Linux unter der Kobo-Software zu bekommen. Damit bot sich dann die Möglichkeit, den kleinen eBook-Reader mit seinem e-Ink Touch-Display für die eigenen Basteleien zu missbrauchen.
In meinem ersten Blogartikel vom 26. Oktober 2014 bin darauf eingegangen, wie man den nötigen Telnet-Zugang auf den Kobo erlangt und die WiFi-Einstellungen auf die eigenen umbiegt. Im zweiten Artikel – erst neun Monate später am 19. Juli 2015 verfasst und veröffentlicht – habe ich geschildert, wie die Verfahrensweise ist, um beliebige Bilder oder Fotos als Bitmap-Grafikdatei in Dateien so umzuwandeln, dass der kleine Kobo mit seinem beschränkten schwarz-weiß Display diese wieder darstellen kann. Soweit hatte ich alles beschrieben, damit der Kobo Mini auch als digitaler Bilderrahmen funktioniert. Woran ich aber vor sechs Jahren nicht mehr gedacht habe, ist, dass ich Bilder mit den Ergebnissen mit in den Blogartikel einzubinden, sodass ein Leser den Wandlungsprozess der von mir verwendeten Fotos nachvollziehen kann. Dabei habe ich damals im Sommer 2015 sogar extra für die Fotostrecke des Bilderrahmens ein paar Fotos im Regenstaufer Lindenpark mit meiner Kamera geschossen. Das hole ich mit diesem Artikel nun doch mal nach.

Original JPEG-Fotos:

Portätmodus
Landschaftsmodus

Link: Vollständiges Fotoalbum „Campus Eckert und Sonnenuntergang“

Mit GIMP erstellte PNG-Bilder (800×600 px, 4 Bit Graustufen):

Porträtmodus
Landschaftsmodus

Link: Campus Eckert und Sonnenuntergang (schwarz/weiß)

Darstellung mit dem Kobo Mini Touch:

Digitaler Bilderrahmen - vertikal
Gehackter Kobo Mini Touch als digitaler Bilderrahmen umfunktioniert
Digitaler Bilderrahmen - horizontal
Gehackter Kobo Mini Touch als digitaler Bilderrahmen umfunktioniert

Allerdings muss ich aber auch dazu sagen, dass der kleine Kobo Mini kein Gyroskop wie Smartphones und Tablet-Computer hat. Um wirklich ungetrübte Freude beim Betrachten der Bilder zu haben, ist es dazu leider nötig, sich beim Zusammenstellen der Bilderstrecke gleich zu entscheiden, ob sie vertikal in einem Porträtmodus oder horizontal dargestellt werden sollen. Er kann nun mal nicht ein Bild automatisch neu ausrichten.

Links:

Commandlinefu

Als ich im vergangenen Herbst nach einer Lösung im Internet recherchiert habe, um eine Audio-Datei (wav, mp3, etc.) aus der Tonspur einer DVD zu erzeugen, bin ich in meinen Suchergebnissen über Beispiele für Kommandozeilen-Befehle auf der Website www.commandlinefu.com aufmerksam geworden. Bei Commandlinefu kann jeder nach der Registrierung einen kleinen Beitrag einstellen für einen Kommandozeilen-Befehl den er oder sie als erwähnenswert erachtet. Dabei wurden – und werden Befehle präsentiert, die entweder etwas Praktisches, etwas Nützliches, etwas Interessantes oder einfach nur etwas Witziges ausführen.
So gab es bis vor etwa zehn Jahren alternative Beispiele, wie sich ein öffentlicher SSH-Schlüssel auf einem Ziel-Host in die Datei ~/.ssh/authorized_keys einfügen lässt. Hintergrund war, dass Apple zwar die vollständige SSH-Suite seit Beginn von Mac OS X als festes Bestandteil integriert hat, aber über etliche Versionen hat das Programm ssh-copy-id gefehlt. So wurden alternative Wege erarbeitet, die mit Hilfe der Standard-Unix-Tools den Schlüssel über ein einziges Shell-Kommando auf den Ziel-Host brachten.xx
Ich habe mal angefangen, ein wenig in der mittlerweile über fast 12 Jahre alten Sammlung zu stöbern und eine wirklich kleine Auswahl in meinem Wiki gesammelt. Aber es steckt noch viel Potenzial in der Sammlung weitere Befehls-Schätze zu entdecken. Es braucht nur etwas Internet und vielleicht einen halben oder ganzen Tag, an dem sich nichts sinnvolleres mit der vorhandenen Freizeit anstellen lässt.
Es gibt im übrigen auch einen Twitter-Account zu Commandlinefu, der einem über einen neuen Beitrag informiert.

Links:

Emulation einer VAX mit SIMH: Die Hardware

Der Host – Der Computer auf dem SIMH ausgeführt wird

Nachdem ich meine ersten Gehversuche in der Emulation der (Micro-) VAX unter SIMH unternommen habe um in DEC’s Betriebssysteme ULTRIX und OpenVMS hineinschnuppern zu können, sowie auch bereits der Gedanke in mir aufkeimte, gleich eine Artikel-Serie daraus zu stricken, hatte ich die Möglichkeit für lau einen Laptop zu übernehmen. Dabei handelt es sich um einen Acer Aspire 7530, welcher vermutlich im Mai 2008 auf den Markt gebracht wurde. Ausgestattet ist das Gerät mit einem AMD Athlon X2 Dual Core QL-60, welcher mit 1,9 GHz getaktet wird und der zwei mal 64 KB Level 1 Cache, sowie 512 KB Level 2 Cache für jeden der beiden Kerne besitzt. Damit ist die CPU-Leistung für diesen dicken, schweren 17″-Laptop (von den Maßen und der Tastatur eigentlich schon eine Mobile-Workstation) laut der damaligen Fachpresse recht mager. Zur sonstigen Ausstattung gehörten 3 GB DDR2 RAM, von dem bis zu 256 MB Video-RAM für die auch eher seinerzeit schwache nVidea GeForce 9400M abgezweigt werden können, und eine 320 GB Festplatte. Die weiteren technischen Merkmale habe ich in meinem Wiki in der Auflistung meiner PC-Familie aufgelistet, waren aber seinerseits bei Marktstart des Gerätes alle marktüblich, spielen dennoch aber für meinen Einsatzzweck keine Rolle.

Nach Erhalt des Gerätes bin ich erst einmal hingegangen und habe für etwas mehr als 20,- Euro noch ein 2 GB Speichermodul gekauft und eingebaut, weil ich der Überzeugung bin, dass ein Computer Arbeitsspeicher nicht genug haben kann. So hat das Gerät nun 4 Gigabyte statt der ursprünglichen etwas krummen 3 Gigabyte. Beim Betrieb dann mit Linux unter Verwendung von LXDE als Window-Manager hat sich dann deutlich heraus gestellt, dass die CPU-Leistung der deutlich limitierender Leistungsfaktor ist, und weniger die Menge des Arbeitsspeichers. Da ich auf meinen Apple-Macs leider die Treiber für TUN/TAP und vde2 nicht korrekt installieren konnte, bin ich doch froh einen separaten Computer zu haben, den ich in erster Linie nur für das Ausführen von SIMH nutzen kann. Von daher ist es erstmal nicht so schlimm, dass modernere Betriebssystem wie ein aktuelles NetBSD unter einer emulierten Digital VAX auf dem Acer-Laptop recht träge gegenüber meinen leistungsfähigeren Macs laufen. Auf dem Acer-Laptop habe ich Debian-Linux als Host-Betriebssystem installiert, wo der TUN/TAP-Treiber vernünftig läuft und die Programm-Pakete auch besser aufeinander abgestimmt sind.

Links:

Die MicroVAX 3900 von DEC als emulierte Computer

Die VAX im allgemeinen (kurz für Virtual Address eXtension) ist eine von der Digital Equipment Corporation entwickelte 32 Bit Rechnerarchitektur. Die 32 Bit VAX-Prozessoren besitzen einen CISC-Befehlssatz. Für die VAX-Reihe hatte DEC auch passend zu der Architektur das Betriebssystem VMS (kurz Virtual Memory System, später OpenVMS) mitentwickelt und auf den Markt gebracht. – Inzwischen wurde und wird auch das Betriebssystem OpenVMS durch die Firma Hewlett Packard Enterprise zu einem 64 Bit System weiter entwickelt. – Auch lässt sich inzwischen auf den Computern der VAX-Reihe NetBSD und Linux betreiben. Es wurde von OpenBSD auch eine Portierung für die VAX-Computer entwickelt, aber diese wurde in ihrer Weiterentwicklung mit OpenBSD 5.9 im Jahr 2016 wieder eingestellt. Ich bin mir aber auch nicht sicher, ob inzwischen die Weiterentwicklung der Portierung von Linux auf die VAX-Architektur wieder bereits eingestellt wurde.

In der stabilen SIMH-Version 3.x wurde die von Digital Equipment Corporation als ersten Computer der VAX-Reihe auf dem Markt eingeführte VAX 11/780 aus dem Jahr 1977 und das im Jahr 1989 wesentlich kleinere Model, die MicroVAX 3900 implementiert. Da die VAX 11/780 das erste Modell der VAX-Familie war, hat Digitial im Laufe der Jahre einen eigenen Benchmark für die hinzugekommenen Modell (-Reihen) geschaffen.: den VUP. VUP steht für VAX Unit of Performance, bei dem das Urmodel als Referenz definiert ist. Der bei den nachfolgenden Modellen angegebenen VUP gibt also den Faktor der Leistung zum Urmodell an. So hat die bereits erwähnte MicroVAX 3900 einen VUP von 3,8 oder die im Jahr 1991 eingeführte VAXStation 4000 M60 einen VUP von 12.

Im vorherigen Beitrag habe ich bereits dargestellt, dass die aktuelle Beta-Version von SIMH gegenüber den stabilen, prekompilierten Versionen in den Linux- sowie BSD-Distributionen für mich die bessere Wahl ist. Ein wesentlicher Punkt von der Beta-Version ist, dass neben den bereits in der stabilen SIMH-Version 3.x verfügbaren VAX 11/780 und der MicroVAX 3900 weitere Computer der VAX-Reihe emuliert werden können. In einer Tabelle in meinem Wiki habe ich mal die neu hinzugekommenen Modelle tabellarisch aufgeführt, die einen sichtlichen Leistungszuwachs gegenüber die MicroVAX 3900 vorweisen können – sofern der Host-Computer für die Verarbeitungsgeschwindigkeit entsprechend leistungsfähig ist. So hatte ich zum Beispiel mal den Versuch unternommen gehabt, auf einem Raspberry Pi Model 1 B mit einem mit 700 MHz getakteten 1-Kern ARM11-Prozessor und NetBSD 7 als Host-Betriebssystem, die MicroVAX 3900 zu emulieren. Als Betriebssystem kam die VAX-Portierung von NetBSD 7 wieder zum Einsatz. Die Verarbeitungsgeschwindigkeit des Raspberry Pi war dabei so langsam, dass auf dem emulierten System der Login-Prozess während diesem bereits wieder Timeouts geworfen hatte. Aber ohne Login ist natürlich auch nur im Ansatz kein Arbeiten mit dem System möglich. Andere User hatten zu dem Zeitpunkt sich mit dem Raspberry Pi der ersten Generation bereits erfolgreich OpenVMS-Cluster gebaut gehabt.

Bei meinen Experimenten, eine der hinzugefügten VAX-Modelle in der Beta-Version zu emulieren, bin ich auf zahlreiche Fehler gestoßen und ich konnte bisher nicht die passenden Geräte-Komponenten (Harddisk-Controller, Festplatten- und CD-ROM Modell) für einen Betrieb zusammenstellen. Andere User haben beim Emulationsversuch – beispielsweise einer VAXStation – nicht die Netzwerkschnittstelle aktivieren können. Es kann natürlich auch sein, dass im Code für die in der aktuellen Beta-4 neu hinzugekommen VAX-Modelle noch Fehler sind. Deswegen beschränke ich mich momentan auf die bereits in stabilen Version vorhandene MicroVAX 3900.

Quelle: The NetBSD Foundation, VAX Hardware Reference (www.netbsd.org)

Noch ein paar Fakten und Informationen zu der Hardware der MicroVAX 3900 selber.:

Der Computer wurde durch DEC mit dem Codenamen Mayfair III im April 1989 im Markt eingeführt. Sie war High-End-Modell der MicroVAX-Familie, welche die MicroVAX 3600 ersetzte, und sollte mit der AS/400-Serie von IBM konkurrieren. Bei der Einführung betrug der Startpreis der MicroVAX 3900 120.000,- US-Dollar. Dieses System verwendete das KA655-CPU-Modul, das einen CVAX-Chipsatz mit 16,67 MHz (60 ns Zykluszeit) enthielt.

RangeServer
IntroducedApril 1989
CPUKA655, CVAX+ Chip
Taktfrequenz16,67 MHz
FPUCFPA
Cycle in ns60
Level 1 Cache1 KiB
Level 2 Cache64 KiB mit von 120 ns Cycle
Arbeitsspeicher16 – 64 MiB ECC
BUS Storage1 x QBUS und 1 x DSSI
Bandbreite3,3 MB/s
HDD Kapazitätmax. 9,7 GB
GehäuseH9642 (19″ breit)
VUP3,8
Einführungspreis in $120.000,-
Supportet OSVMS, ULTRIX, VAXELN
FPU DatentypenF, D, G, H
Netzwerkmax. 2 Ethernet-Ports

Links: