Author: mattias

  • Unser Weihnachtsbaum zwitschert uns was! – Start: Wasserstandssensor

    Von Anja Schlenker und Mattias Schlenker

    Heiligabend, der Weihnachtsbaum steht halbwegs gerade und damit ist die größte Hürde zum harmonischen Fest genommen. Doch nach ein paar Tagen Heizungsluft ist Papa genervt, er muss bäuchlings unter die piksenden Zweige kriechen, ohne dabei Muttis mundgeblasene Glaskugeln herunter zu rammeln, und prüfen, ob noch genügend Wasser im Ständer ist oder es bald heißt: leise rieselt der Baum.

    Schöner, rückenschonender und überhaupt viel cooler ist Horst von Forst, unser twitternder Weihnachtsbaum, der seinen Durst meldet und damit Papa’s Gekrieche auf ein Mindestmaß reduziert. (more…)

  • Heute im Adventskalender: ein 10MΩ-Widerstand

    Mein Adventskalender kommt von Conrad und versprach 24 spannende Experimente. Was sich bislang hinter den Türchen verbirgt, war eher unspektakulär: eine LED, ein Widerstand 6,8kΩ, ein Breadboard, Draht, ein IC mit ganzen vier NAND-Gattern und heute die 10MΩ. Der reine Materialwert des gesamten Kalenders dürfte sich im Bereich von 3€ bewegen – bei knapp 10€ Verkaufspreis. Auf den ersten Blick wenig Ware fürs Geld. Der Clou ist aber das von Franzis für Conrad produzierte Begleitheft, welches jeden Tag mit einem neuen Bauteil eine neue Schaltung aufbaut und erklärt. (more…)

  • Ein neues (Linux-) Projekt…

    Ein neues Projekt wird gerade angegangen: Hausautomatisierung mit Arduino. Als Buch, bei Franzis. Was das Ganze mit Linux zu tun hat? So einiges. Zentrale Schalt- und Waltstelle im Buch wird wohl der Arduino Yún werden. Arduinos Einstieg in die Linux-Welt: Ein Atmega32u4-Microcontroller auf der einen Seite und ein MIPS basierter Linux-Rechner auf der anderen. MIPS kennen wir von DSL-Routern und einigen Smartphones. MIPS und Microcontroller kommunizieren über eine serielle Schnittstelle. Neu ist die enge Integration der beiden: Arduino 1.5.4 bringt eine Bibliothek mit, die es erlaubt, ganz ohne serverseitige Programmierung Arduino-Pins direkt per Webserver anzusteuern.

    Und noch mehr Linux wird seinen Weg ins Buch finden: weil ich davon ausgehe, dass nicht jeder einen Yún kaufen will (weil er/sie bereits einen Raspberry Pi hat) oder kaufen kann (die nächste Lieferung wird Anfang Dezember erwartet und auch zum Buchstart gehe ich davon aus, dass nicht überall Yúns ausliegen werden), wird die alternative Schaltzentrale ein Raspberry Pi, der via I2C mit einem mit ihm verbundenen Arduino Uno oder Mega kommuniziert.

    Das Blog zum Buchprojekt habe ich heute freigeschaltet, auf Wunsch geht es direkt zum heutigen Eintrag, einer Kurzvorstellung des Yún.

  • Yúhú! Der Arduino Yún ist da!

    Mein betreuender Redakteur Markus Stäuble war so nett, zwei Arduino Yún (“Yún” ist chinesisch für “Wolke”, was den Einsatzzweck gut umreisst) zu besorgen, damit ich mit der Arbeit am Buchprojekt endlich richtig loslegen kann. Der Yún ist leider derzeit überall in Deutschland ausverkauft, Franzis listet ihn daher nicht. Wir gehen jedoch davon aus, dass er spätestens in der Vorweihnachtszeit in Stückzahlen verfügbar sein wird. (more…)

  • Raspberry Pi vs. Arduino?

    Mit der breiten und günstigen Verfügbarkeit des Raspberry Pi Modell B kommt bei vielen Bastelwilligen die Frage auf, ob denn nun Arduino oder Raspberry Pi das bessere Tool ist. Die Antwort ist einfach: Beide. Wer wirklich basteln möchte, sollte sich mit beiden Kleinstcomputern vertraut machen: (more…)

  • Los geht’s!

    Ich bastle bereits seit einiger Zeit an kleinen Arduino basierten Projekten – teils um das Leben leichter zu machen, teils aus der Freude daran, Maschinen zu erschaffen, die zwar keinen großen Sinn ergeben, aber Spaß machen und einen Lerneffekt mit sich bringen. Nun wurde ich von einem Redakteur des Franzis-Verlages angesprochen, der meine Kontaktdaten von einem Kollegen beim PC Magazin (dort schreibe ich immer wieder zu Linux und PC-Technik allgemein) hatte:

    Ob ich nicht Lust hätte, ein Buch zur Heimautomatisierung mittels Arduino zu schreiben?

    (more…)

  • Caps Lock auf Shift umbelegen – Linux und Windows

    Wozu dient bitte Caps Lock? Seit rund zwanzig Jahren fällt mir kein Grund mehr ein, diese Taste zu benutzen. Also belegen wir sie um.

    Windows

    Unter Windows verwendet man die Registry, um Caps Lock umzubelegen, der folgende Eintrag mach Shift draus:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
    "Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,2a,00,3a,00,00,00,00,00

    Einfacher: Hier die Registry-Datei herunterladen und per Doppelklick aufnehmen: http://cdprojekte.mattiasschlenker.de/Public/Windows_misc/disablecapslock.reg

    Linux

    Ich verwende eine ~/.xinitrc und darin die Zwei Zeilen:

    xmodmap -e 'remove Lock = Caps_Lock'
    xmodmap -e 'keysym Caps_Lock = Shift_L'

    Wer möchte, kann auch eine ~/.Xmodmap anlegen, die folgendes enthält:

    remove Lock = Caps_Lock
    keysym Caps_Lock = Shift_L

    und beim Start des Windowmanagers oder der Desktopumgebung sicherstellen, dass xmodmap gestartet wird und die ~/.Xmodmap verwendet wird.

  • VMware – UEFI-Boot simulieren

    Mit weiteren Verbreitung von UEFI steigt die Relevanz, in Live-Distributionen den UEFI-Bootloader zu konfigurieren und zu testen und – als Autor – mit Screenshots Artikel zum Thema garnieren zu können. Bei mir betrifft das konkret das eigene Live-System LessLinux, derzeit primär ein Notfall- und Rettungssystem und die Multiboot-Linux-CDs, die ich für Verlage wie WEKA, Data-Becker, Heise erstelle oder miterstelle. Einen Teil der notwendigen Screenshots muss ich auf echter Hardware mit einer Capture Card erstellen (BIOS, UEFI-Setup). Für viele andere taugt die virtuelle Maschine.

    Als Virtualisierungssoftware setze ich beim Desktop noch auf VMware, konkret den Player. Der ist nicht mehr kostenlos, aber dank Fusion-Lizenz ist er bei mir immerhin lizenziert (Unternehmen, die bislang den kostenlos nutzbaren Player einsetzten, müssen nach meiner Lesart der Lizenz pro Standort wohl rund 80€ investieren). Dass ich mittelfristig plane, auf VirtualBox zu wechsel, ist eine andere Geschichte.

    Nun habe ich mich gewundert, dass ich weder in Fusion, noch im VMware Player irgenwo ein Option finde, BIOS/MBR oder UEFI/GPT als Firmware-Modell zu wählen. Es ist ganz einfach. Die .vmx-Datei, in der die Konfiguration gespeichert ist, lässt sich als einfache Textdatei an beliebiger Stelle um die Zeile

    firmware = "efi"

    ergänzen. Danach verhält sich VMware wie ein UEFI-Rechner, der vom Betrieb im CSM in den UEFI-Modus umgeschaltet wurde. Beim Neuaufsetzen virtueller Maschinen, bedeutet das, dass man zunächst zwar die Maschine konfigurieren, aber unbedingt “I will install the Operating System later” wählen sollte. Anschließend fügt man die EFI-Zeile in die VMX-Datei ein und startet dann die Installation im UEFI-Modus.

  • MokList gesemmelt, Boot unmöglich – MokList corruptet, boot impossible

    Please scroll down for an English version!

    In den letzten Monaten habe ich viele Experimente mit UEFI Secure Boot durchgeführt, mit so ziemlich allen Bootloadern und mit den gewonnenen Erfahrungen so einige Secure Boot kompatible Boot-Medien aufgebaut: Heise Desinfect, PC Magazin Superpremium 7/2013, Data Becker Linux Extra 5 und natürlich diverse LessLinux-Builds. Seit gestern ließen sich irgendwie nur originale Ubuntu- und Windows-Systeme booten, was für meine Zwecke natürlich ziemlich bescheuert ist. Der Grund: Die MokList im UEFI NVRAM, in der Shim und PreLoader.efi (respektive deren Schlüsselverwaltungstools) vom Nutzer freigegebene Schlüssel speichern, war irgendwie beschädigt oder einfach zu groß. Alle Schlüssel per UEFI Setup auf Werkseinstellungen zurückzusetzen, hatte keinen Effekt und KeyTool.efi hängte sich sofort auf. Wie weiter und die MokList löschen?

    Ich habe herausgefunden, dass der einfachste Weg ist, entweder rEFInds flash drive image oder das demo image “sb-usb.img” der LinuxFoundation herunterzuladen und auf einen USB-Stick (per “dd”) zu ziehen. Damit bootet man bei deaktiviertem Secure Boot in die EFI Shell und gibt folgendes Kommando ein:

    dmpstore -d MokList

    Beim nächsten Start geht es mit einer leeren MokList weiter…

    …and in English

    The last months I did lots of experiments with UEFI secure boot and created some boot media that was secure boot compatible: Heise Desinfect, PC Magazin Superpremium 7/2013, Data Becker Linux Extra 5, various build of LessLinux with various bootloaders. Yesterday my MokList got corrupted or just too large – the MokList (or Machine Owners Key list is a database stored in the UEFI NVRAM that contains the keys and hashes that the owner of a machine added, for example when booting with Shim or PreLoader). Secure boot just worked with loaders that dit not access the MokList, which is not very useful for my purpose. Resetting all Keys via UEFI setup did not work. And KeyTool.efi just hung when editing the MokList. So how do I clear it?

    I found out that the easiest way is to download either rEFInds flash drive image or the demo image “sb-usb.img” from the LinuxFoundation. Dd either of those to an USB thumb drive, disable secure boot in the UEFI setup and boot into the EFI shell. there you can simply delete the MokList with the command:

    dmpstore -d MokList

    Next time you boot, the MokList is empty/noexistent…

  • Bootfähigen USB-Stick für UEFI Secure Boot erstellen – 1. PreLoader der Linux-Foundation plus Gummiboot

    Disclaimer: Dieses kleine Tutorial richtet sich an all jene, die entweder einen Admin-Stick mit verschiedenen Installern und Notfallsystemen erstellen wollen oder einfach eine Fingerübung suchen, um den Bootvorgang von UEFI Secure Boot besser nachvollziehen zu können. Die anfängliche Installation von LessLinux Search and Rescue kann nach und nach um weitere Linuxe erweitert werden. Als Bootloader verwende ich zunächst den unkomplizierten PreLoader.efi der Linux-Foundation in Kombination mit Gummiboot, möglicherweise folgt demnächst eine auf Shim (mit MOK) angepasste Anleitung. Auf den EFI-Boot von 32-Bit-Systemen möchte ich nicht eingehen, weil praktisch nur ältere Apple iBooks und MacMinis (CoreDuo, nicht Core2Duo) mit einem 32-Bit-EFI ausgeliefert wurden. Die paar Netbooks von Asus, die ebenfalls 32-Bit-EFI an Bord haben, sind in der Regel auf das CSM eingestellt (Compatibility Support Module = BIOS-Emulation zum Boot von MBR-Medien).

    Hinweis: Auf dieses Tutorial folgt ein weiteres, das die hier gezeigte Konfiguration um GRUB erweitert (um 32-Bit-Systeme booten zu können) und eines, das erklärt, wie schließlich ein hybrider Stick entsteht, der auf MBR- und UEFI-Systemen startet. Wer aus dem dritten Tutorial das Optimum herausholen möchte, sollte eine dritte, 100 bis 200MB große, leere FAT32-Partition einplanen.

    Wie bootet UEFI sicher vom Stick?

    Der Vorgang von USB ist etwas einfacher als von Festplatte, zumindest wenn es sich um einen GPT partitionierten Stick mit einer einzigen FAT32-Partition handelt. In diesem Fall genügt es, eine Ordnerstruktur “BOOT/EFI” anzulegen, die den Bootloader “BOOTX64.EFI” enthält. Hintergrund dieser Vereinfachung ist wohl, dass es ermöglicht werden soll, alleine durch das Entpacken eines Zips mit den Bootdateien einen Stick bootfähig zu machen – aber das ist Spekulation, weder habe ich nachgeprüft welche UEFI-Implementierungen den einfachen Start unterstützen, noch habe ich getestet, ob in nennenswerten Stückzahlen USB-Sticks am Markt sind, die sowohl GPT als auch BIOS-MBR aufweisen. (more…)