Mattias Schlenker

Blog

  • 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…)

  • Das Gespenst UEFI Secure Boot

    In den letzten Tagen hatte ich etwas Gelegenheit, mich mit UEFI Secure Boot näher zu beschäftigen: Ich erstelle bekanntlich die Notfall-CDs für einige Computerzeitschriften oder arbeite intensiv daran mit (von Computer Bild bis desinfec’t gibt es einige). Ziel war, alle aktuellen, von Microsoft signierten EFI-Loader unter die Lupe zu nehmen und auf ihre Praktikabilität abzuklopfen. Die gute Nachricht vorweg: Wer Ubuntu oder Fedora verwendet und keine Kernel selbst kompiliert, muss sich nicht mit dem Schlüsselmanagement herumärgern. Beide Distributionen verwenden einen von Microsoft signierten Loader (auf Basis von Shim), der wenigstens sicherstellt, dass GRUB2 und der anschließend geladene Kernel “vertrauenswürdig” ist. Zu Funktionsweise, Unterschieden und Restriktionen der verwendeten gepatchten GRUB2-Varianten hat sich Thorsten Leemhuis in der c’t 5/2013 zur Genüge ausgelassen. Wirklich spannend ist die Thematik aber für den Start selbst kompilierter Kernel, für kleine Distributionen, die verteilt und schnell entwickelt werden und für Administratoren, die Linux basierte Deployment- und Notfall-Systeme per Netz oder vom Wechseldatenträger starten wollen.

    In diesem Beitrag möchte ich die eher theoretischen Hintergründe erläutern und Entscheidungshilfen geben, demnächst folgen dann Beiträge zur praktischen Umsetzung von Secure Boot eigener Kernel auf USB-Sticks, optischen Datenträgern und via Netzwerk. (more…)

  • DVD nach MKV rippen

    Dieser Blogpost soll in erster Linie eine Notiz für mich selbst sein, wie man eine DVD in eine MKV mit H.264-Video, Untertiteln und mehreren Audiospuren umwandelt. Ich verwende Stereo-Audio im MP3 kodiert – einfach weil an keinem unserer Abspielgeräte 5.1 Audio angeschlossen ist. Wer 5.1 haben möchte, kann gerne die rohen AC3-Spuren übernehmen. Die Beispiele legen alle Dateien im aktuellen Arbeitsverzeichnis ab. Daher empfehle ich, einen neuen Ordner anzulegen, der nach dem Merge von Audio- und Videospuren gelöscht werden kann.

    DVD kopieren

    Als allererstes kopiere ich die DVD mittels dvdbackup. Damit das mit CSS verschlüsselten DVDs funktioniert, muss eine entsprechende Version der libdvdcss installiert sein. Irgendwo unterhalb von /usr/share/doc gibt es ein Shell-Script, welches dies erledigt:

    find /usr/share/doc -name '*css*.sh'

    Üblicherweise kopiere ich die ganze DVD und nicht nur das Main-Feature. Das erledigt der Schalter “-M” wie “Mirror”, daneben sind Eingabegerät und Zielordner notwendig: (more…)

  • Ubuntu 12.10 und VMware Workstation 9 oder Player 5

    Die Kernelmodule von VMware greifen reicht stark in die Speicherverwaltung ein, beziehungsweise sind allergisch auf Änderungen an den APIs der Netzwerktreiber. Kommt ein Kernel nach Fertigstellung von VMwares Treiberpaket auf den Markt, gibt es lange Gesichter: VMware-Module lassen sich nicht kompilieren oder kompilieren und nicht laden oder VMware – und schlimmstenfalls der Kernel – stürzen ab. Für Nutzer von VMware Workstation 9 oder Player 5 gibt es hier Abhilfe:

    http://communities.vmware.com/servlet/JiveServlet/download/2103172-94260/vmware9_kernel35_patch.tar.bz2

    Um den Patch anzuwenden, gegebenenfalls zunächst auf Ubuntu 12.10 aktualisieren, dann die VMware-Dienste stoppen:

    service vmware stop

    Anschließend den Patch entpacken und das enthaltene Script anwenden:

    tar xvjf vmware9_kernel35_patch.tar.bz2
cd vmware9_kernel3.5_patch
bash patch-modules_3.5.0.sh

    Jetzt noch die Dienste neu starten, dann klappt es wieder mit dem VMware Player…

    service vmware restart
vmplayer

  • Ubuntu 12.10 und VMware Workstation 9 oder Player 5

    Die Kernelmodule von VMware greifen reicht stark in die Speicherverwaltung ein, beziehungsweise sind allergisch auf Änderungen an den APIs der Netzwerktreiber. Kommt ein Kernel nach Fertigstellung von VMwares Treiberpaket auf den Markt, gibt es lange Gesichter: VMware-Module lassen sich nicht kompilieren oder kompilieren und nicht laden oder VMware – und schlimmstenfalls der Kernel – stürzen ab. Für Nutzer von VMware Workstation 9 oder Player 5 gibt es hier Abhilfe:

    http://communities.vmware.com/servlet/JiveServlet/download/2103172-94260/vmware9_kernel35_patch.tar.bz2

    Um den Patch anzuwenden, gegebenenfalls zunächst auf Ubuntu 12.10 aktualisieren, dann die VMware-Dienste stoppen:

    service vmware stop

    Anschließend den Patch entpacken und das enthaltene Script anwenden:

    tar xvjf vmware9_kernel35_patch.tar.bz2
cd vmware9_kernel3.5_patch
bash patch-modules_3.5.0.sh

    Jetzt noch die Dienste neu starten, dann klappt es wieder mit dem VMware Player…

    service vmware restart
vmplayer

  • Ubuntu 12.04 auf GPT “debootstrappen”

    Ein neuer Hetzner-Server – der wieder dank Xen fast 30 Linux-Instanzen aufnehmen wird – machte es erstmalig erforderlich, ein Linux remote auf einer großen Platte (größer als 2TB) zu installieren. Statt dem im Büronetz eingesetzten PXE-Netinstaller musste hier “debootstrap” zum Einsatz kommen – und es klappte fast auf Anhieb. Grund für die Neuinstallation war – mal wieder – der Wunsch, ein eigenes Partitionslayout vergeben zu können, eine Flexbilität, die Hetzner natürlich für das Standardimage nicht bieten kann. Ich entschied mich daher dafür, den Server mit aktiviertem Rettungssystem zu übernehmen. Das ist bei Hetzner Debian basiert, so dass “debootstrap” in Ubuntus Version mit wenigen Handgriffen installiert werden kann. Der einzige Haken: Festplatten über zwei Terabyte erfordern entweder eine GUID Partition Table (“GPT”) oder eben, dass man damit lebt, dass rund ein Drittel der Plattenkapazität nicht erhältlich ist. Ich entschied mich für ersteres. (more…)

  • USB-Geräte im Netz durchreichen

    Für einen Kunden arbeite ich gerade an einem Thin-Client-Netzwerk: Dünne, unter Linux laufende Clients sollen per RDP-Client auf Windows-7-Pro-Instanzen zugreifen, die gesammelt auf einem Xen-Host ausgeführt werden. Für die Nicht-Verwendung von Windows Server 2008 mit Terminaldiensten gibt es den simplen Grund, dass einige der eingesetzten Anwendungen nicht in Terminalserverumgebungen lauffähig sind. Der Haken an der Geschichte: Es muss ein komfortabler Zugriff auf lokale USB-Geräte – Speichersticks, Chipkartenleser und ähnliches – möglich sein.

    Wir haben daher zunächst mit USB-Servern fürs Netz experimentiert, derartige Geräte gibt es für netto 30 Euro (Ein-Port-Versionen mit unbekanntem chinesischen Hersteller, z.B. bei Conrad) bis 300 Euro (zwei oder vier Ports, Hutschienenmontage, Industriequalität, PoE, z.B. bei WuT). Mir gefiel aber nicht, neben dem Thinclient ein weiteres Gerät mit eigenem Netzteil (günstige Geräte können kein PoE) am Arbeitsplatz zu haben und habe daher nach Softwarelösungen für Linux gesucht. Gestoßen bin ich zunächst auf die kommerzielle Software USB Redirector, die jedoch für unser Szenario mit 75 oder 89US$ je Arbeitsplatz zu Buche schlagen würde. Gelandet bin ich schließlich beim freien Projekt USBIP, das jedoch nicht ganz trivial zur Zusammenarbeit zu bewegen ist. Geschafft habe ich es dennoch, Testsystem ist ein Ubuntu 12.04, die im nachfolgenden Text beschriebenen Schritte dürften so auch auf andere Systeme mit Kernel 3.1 oder höher anzuwenden sein. Als Client habe ich bislang nur Windows probiert über meine Erfahrungen mit Linux werde ich ggf. später berichten.
    (more…)

  • Windows 7 oder Server 2008 als Xen domU (HVM)

    Mit der besseren Integration von Xen in die aktuelle LTS Version von Ubuntu bietet es sich an, als Virtualisierungslösung auf den freien Xen zu setzen, wenn es darum geht, einen Windows TS (Terminal Services) oder RDS (Remote Desktop Services) Server im kleinen SOHO Netzwerk zu virtualisieren. Dieser Workshop setzt einen funktionierenden Xen-Host voraus, d.h. eine paravirtualisierte domU konnte bereits erfolgreich gestartet werden. (more…)