Kürzlich habe ich einen gebrauchten und betagten Acer Aspire E774 Laptop als Spende für den Computertruhe e.V. fertiggemacht. Selbstverständlich gehört dazu auch das überschreiben der Festplatten mit zufälligen Daten, sodass sich keine alten Daten mehr rekonstruieren lassen. Denn “gelöscht” ist nicht gleich “sicher gelöscht”. Zum sicheren Löschen habe ich das Tool shred in einer Fedora Live Umgebung genutzt. Mit beliebigen anderen Linux-Distributionen funktioniert das aber genauso gut.
Da ein Ubuntu auf dem Laptop nicht auf Anhieb lauffähig bzw. zumutbar war, weil das Touchpad nicht funktionierte und es beim Boot immer wieder merkwürdige Probleme gab, habe ich mich dazu entschlossen, nach meiner Löschaktion einfach wieder ein Windows 10 zu installieren. Ganz so, wie es zuletzt auf dem Laptop einwandfrei lief.
Wer schon einmal persönliche Sicherheitskopien von DVDs unter Linux angelegt hat, ist sicherlich mit dem Ripping-Tool MakeMKV vertraut. Das Tool kann in seiner Betaversion kostenlos genutzt werden. Der Nachteil: Dazu muss es monatlich neu aus dem Quellcode kompiliert und installiert werden.
Praktischerweise hat jemand ein FlatPak-Paket für MakeMKV angelegt, das es ermöglichst, das Programm sehr bequem auf dem FlatPak Store zu laden, ohne es selbst händisch kompilieren zu müssen. Doch leider wird das FlatPak Paket nicht automatisch aktualisiert. So kann es - wie in meinem Fall - vorkommen, dass das Programm nicht startet, weil die im FlatPak enthaltene Version schon älter als einen Monat ist und deshalb den Start verweigert.
VirtualBox nutze ich wegen der relativ guten Grafikperformance gerne für meine Windows-VM unter Fedora 24. Bei ersten Start schlug mir eine Fehlermeldung entgegen: Das notwendige “vboxdrv”-Kernelmodul sei noch nicht geladen, daher könne die VM nicht gestartet werden. Gut - das lässt sich ja lösen:
sudo modprobe vbxdrv
… doch damit war es nicht getan: Das Modul ließ sich nicht in den Kernel einbinden, weil es für das aktive SecureBoot nicht mit einem passenden MOK (Machine Owner Key) signiert worden war. Andere geladene Kernelmodule sind bereits von Fedora signiert - bei den VirtualBox Modulen war das nicht der Fall. Warum das so ist, konnte ich noch nicht herausfinden. (=>siehe Notiz unten)