Schlagwort-Archive: Linux

Embeddable Linux Kernel Subset auf dem NuXT

Veröffentlicht am von
Antworten

Da ich mich schon länger mit zwei PCs der 16 Bit x86 XT-Klasse beschäftige, – über das originale Schätzchen von IBM hatte ich aber bisher noch gar nicht geschrieben – kam ein Kollege vor ein paar Wochen mit dem Link zum ‚Embeddable Linux Kernel Subset‘ (kurz: ELKS) auf mich zu. ELKS ist relativ kurz gesagt in Projekt, das einen frühen Fork des Linux-Betriebssystems für Systeme mit Intel IA16-Architektur (16-Bit-Prozessoren: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 und kompatible) bereitstellt. in Projekt, das einen frühen Fork des Linux-Betriebssystems für Systeme mit Intel IA16-Architektur (16-Bit-Prozessoren: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 und kompatible) bereitstellt. Unterstützt werden Netzwerk, Grafik, ia16-elf-gcc, OpenWatcom C und ein eigener nativer C-Compiler, sowie die Installation auf Festplatten mit den FAT-Dateisystemen MINIX und MSDOS. Die Bitte war, auch auf der historischen Hardware-Klasse neben dem üblichen DOS auch ein für die Zeit der Architektur unüblich ein Linux zu betreiben.
Schnell habe ich mir von der GitHub-Projektseite das heruntergeladene, 1,44 MB große Floppy-Image auf eine Diskette kopiert, um es auf meinem NuXT mit NEC V20 Prozessor und 640 KiB RAM starten zu können. Die Installation auf ein durch eine CompactFlash Karte dargestelltes Festplattenlaufwerk hatte ich nicht mehr hinbekommen. Da auch bereits im Gegensatz zu den 360 und 720 KB Disketten-Images das vollständige Subset auf der 1,44 MB Variante Platz findet und die Diskette erfolgreich gebootet war, war somit die Machbarkeitsstudie mit dem derzeitigen ELKS in Version 0.8.1 erfolgreich abgeschlossen.

Jetzt am Wochenende hatte mich der Ehrgeiz aber erneut gepackt, und ich wollte es nicht unversucht lassen. Direkt bei dem erneuten ersten Versuch hat es geklappt und ich konnte das ELKS von der echten, 1,44 MB großen Diskette auf eine übrige 256 Megabyte große CompactFlash Karte installieren. Allerdings empfand ich zum einen die Formatierung der CF-Karte mit dem Minix-Dateisystem als nicht optimal, zum anderen hielt ich die 256 MB Karte grundlegend für zu groß. Irgendwo hatte ich schließlich noch eine ungenutzte 64 MB Karte, die mir in Bezug auf die Speichergröße für die Rechenleistung der XTs geeigneter erschien. Nur mit dem Versuch, die Installation von Diskette auf CF-Karte in Vernünftig durchzuführen, wurde zum Drama!:
Ich bekam sowohl beim Ausführen der Programme zur Bearbeitung und Formatierung des Zielmediums, als auch beim Kopieren der einzelnen Dateien des Subsets von Quell- auf Zielmedium Lese- und Schreibfehler. Ist die ganze Blockstruktur so empfindlich für Disketten? Ich habe also unterschiedliche 3,5″ HDD Disketten, anderer USB-Diskettenlaufwerke für meinen Internet-fähigen Computer, sowie ein anderes internes Diskettenlaufwerk für den XT ausprobiert, aber ohne Besserung. Auch das Ausprobieren der Images auf FAT32- statt der Minix Dateisystembasis ergab keinen Unterschied. Die Alternative war dann das stupide Kopieren der vorgefertigten Harddisk Images von der Projekt-Download-Seite. Das Problem dabei: sowohl die Images mit MBR, als auch ohne, ließen sich nicht booten, da das Boot-Flag in der Image-Geometrie fehlte. Nach stundenlangem Probieren hatte ich schließlich erst wieder Erfolg, nach dem ich mir unter einem Windows Computer einen USB-Stick für mehrere Floppy-Images erstellt und das entsprechende 1,44 MB Image hineingeladen hatte. Dies bedeutete aber auch, dass ich den NuXT einen Floppy-Emulator nur für diesen Zweck einbauen musste. Nur für den einen Zweck, das ELKS von einer „Diskette“ auf eine CF-Karte zu installieren, bedeutet dies sehr viel Bastelei. Ausführen der Festplattenprogramme und Kopieren der Dateien von USB-Stick verliefen dann ohne nennenswerten Lese- und Schreibfehlern.

Quelle: https://frankfurt.social/@sommteck/115091257215484879 (eigner Mastodon Feed)
ELKS Installation mit NuXT Versuchsaufbau

Ich werde mal abwarten, bis eine neuere Version als die aktuelle 0.8.1 zur Verfügung steht. Vielleicht wurden dann die vorgefertigten Harddisk Images mit einem Boot-Flag nachgebessert. Weitere Konfiguration, sowie Optimierungen werde ich mal separat behandeln. Hoffentlich dann mit den Eindrücken des eigenen IBM XT PCs. Hier nur die Kurzanleitung zur Installation von Floppy auf eine 64 Megabyte CompactFlash-Karte.

fdisk /dev/hda
  • n → neue Partition /dev/hda1 über das ganze Speichermedium
  • b → bootable Flag setzen
  • w → schreiben, dann q zum Verlassen
mkfs /dev/hda1 60000     # MINIX v1 erstellen
sys -M /dev/hda1         # ELKS + Bootloader installieren
echo "##" > /bootopts
echo "root=hda1" >> /bootopts
sync; shutdown -r

Links:

Kleine Versuche mit Linux auf dem Desktop

Veröffentlicht am von
Antworten

In meinem ThinkPad T420 hatte ich neben der originalen, klassischen Festplatte vor vier noch den mSATA Slot mit einer entstehenden SSD bestückt für ein zusätzliches Linux, habe sie dann aber bis jetzt nicht gebraucht. Na ja, da hatte mal wieder Leistung auf Vorrat gekauft.
Aus Lust und Laune, sowie genügend Zeit heraus habe ich vor knapp einem Monat es in Angriff genommen und auf die SSD wieder ein aktuelles Debian Linux frisch installiert. Diesmal wollte ich aber die vollständige Linux-Installation mit einem Logical Volume Manager (LVM) und LUKS verschlüsselt haben. Um aber jetzt wie bei einer früheren Debian-Installation zu vermeiden, dass die letzte (physische) Partition – diese war ohne LVM – nicht wieder mit einem unvollständigen Cluster abgeschlossen wird, bei der sich dann das System über ein fehlerhaftes Dateisystem beschwert, habe ich die Partitionierung im geführten Modus, „gesamtes Medium verwenden“, „LVM-verschlüsselt“, im Debian-Installer gewählt. Ich wurde aber während des Partitionierungsvorgang insofern enttäuscht, als ich kein Einfluss auf die Größen sämtlicher Partition hatte. Abgesehen von der unverschlüsselten /boot Partion mit Bootloader, Bootmanager und Kernel, die für mich mit einer Größe von gut 500 Megabyte erst einmal passabel erscheint, wurde die Swap-Partion mit einem Gigabyte, meine separate /home-Partition mit 224 Gigabyte, sowie die Partition für die restliche Dateisystemstruktur ab der Wurzel mit 30 Gigabyte bemessen. Ich persönlich hätte aber für Swap gerne mehrere Gigabyte, im Zweifel bis 8, und auf alle Fälle für die Partition mit der Wurzel zumindest die 50 Gigabyte gehabt. (Die Partition innerhalb des Volume Groups werden richtiger weiße Logical Volumes genannt!) Ich beließ es also erst einmal dabei, weil ich wusste, dass sich die Logical Volumes einem Physical Volume sich auch noch nachträglich bearbeiten lassen.
Bei der Installation des Debians ist mir auch bei der Wahl der grafischen Oberfläche aufgefallen, dass es neben Gnome jetzt auch neu Gnome-Flashback gibt. Als alter Liebhaber von Gnome 2 hätte ich es eigentlich dem Mate-Desktop vorziehen und mal ausprobieren sollen. Aber die Macht der Gewohnheit siegte wieder mit dem Mate-Desktop.

Letzte Woche habe mich dann nun hingesetzt um zu Versuchen, dass ich das /home-Volume soweit verkleinere, damit ich das Volume für / um 20 Gigabyte und auch das Swap-Volume etwas vergrößern kann. Allerdings habe ich das Vorhaben nach einer Weile wieder abgebrochen, weil während meiner Suche über die im System enthaltene Online-Dokumentation ich keine entsprechenden Programmbefehle finden konnte, die mir die aktuellen Größen der Logical Volumes und freien Speicherplatz der Volume Group anzeigen können, nachdem ich Commandline-Befehle zum Verkleinern des 224 Gigabyte großen /home-Volumes bereits abgesetzt hatte. Im Nachhinein wäre vielleicht der Artikel über Logical Volume Manager im deutschsprachigem Ubuntuusers-Wiki hilfreich gewesen. Stattdessen habe ich dann die Möglichkeit gesehen, bei einer Neuinstallation des Debian-Linux’s die Partitionierung des verschlüsselten LVMs händisch vorzunehmen und als Desktop-Envoirement eben nicht den Mate-Desktop, sondern mal Gnome-Flashback zu Verwenden. – Gesagt, getan!
Ich habe mir schon fast die Hände gerieben gehabt, mit der Vorstellung ein vollständiges Desktop-Envoirement von Gnome 2 nach dem ersten Boot-Vorgang wiederzufinden. Aber auch hier wurde ich wieder enttäuscht! Der Displaymanager mit dem Login-Dialog war der von Gnome 3. Letztendlich ist Gnome-Flashback ein vollständiges Gnome in GTK+ 3, nur mit dem alten GnomePanel von Gnome 2 ohne dynamischen Desktop-Elementen. Klar ist es möglich, das Design der Fensterelemente zusätzlich im Nachhinein so anzupassen, dass es wieder mehr nach Gnome 2 aussieht, aber am Ende bleibt es Gnome 3, welches mehr Ressourcen als der Mate-Desktop für mein altes ThinkPad T420 benötigt und auch aus ein paar mehr Paketen zusammen gebaut ist. – Also alles zum dritten mal wieder neu und mit manuellem LVM-Einrichten zurück zum Mate-Desktop.
Was mir aber bei der manuellen Einrichtung der Logical Volumes aufgefallen ist, dass bei der geführten Partitionierung der Debian-Installer für die unverschlüsselte Boot-Partition das alte ext2-Dateisystem verwendet. Das hatte mich seinerzeit schon gewundert, aber gut! Bei der manuellen Partitionierung quittierte mit der Installer die Auswahl von ext2, dass ich doch bitte ein moderneres Linux-Dateisystem verwenden sollte. Ich habe mich erst einmal mit ext3 begnügt. – Ehrlich gesagt hätte ich aber auch direkt ext4 nehmen sollen.

Abgesehen von den dargestellten Erkenntnissen oben, wurde mir von einer Person das Commandline-Tool tldr wie im Sinn von ‚too long; didn’t read‘ empfohlen, mit welchen es möglich ist, quer durch alle Manual-Pages nach Begriffen suchen zu können, um herauszufinden, welche Dokumente sich mit dem Schlagwort auch befassen. Dieses werde ich auch auf alle Mac’s wie MacPorts mal installieren.

Links:

Ultimate Boot CD

Veröffentlicht am von

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

Veröffentlicht am von

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

Veröffentlicht am von
Antworten

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: