Yamagi.org
Windows per fsarchiver auf eine andere Festplatte kopieren
Post #8 - yamagi - 10.09.2012 10:47
Ich hatte letztens das Glück eine Windows-Installation auf einer defekten Festplatte sichern zu dürfen. Und zwar in einer solchen Form, dass Windows die ganze Prodedur möglichst unbeschadet übersteht. Früher war für solche Zwecke "Norton Ghost" das Tool der Wahl, in seinen aus gutem Grund noch immer erhältlichen erhältlichen DOS-Versionen ist es grundsätzlich auch heute noch eine Empfehlung wert. Allerdings sollte in diesem speziellen Fall die Sicherung nicht auf ein lokales Gerät ausgeschrieben werden, stattdessen war das Ziel ein NFS-Share. Zudem sind magische, propietäre DOS-Tools nicht unbedingt nach meinem Geschmack. Kurz um, es war die optimale Situation, um endlich einmal "fsarchiver" auszuprobieren.
fsarchiver ist ein Linux-Tool (und wirklich nur für Linux, denn es ist wohl sehr nah gegen den Kernel gestrickt), was in der Tradition des älteren "partimg" steht und versucht Norton Ghost zu ersetzen. Es archiviert ganze Partitionen in einen komprimierten und auf Wunsch verschlüsselten Datenstrom, reichert diesen mit einigen Metadaten zur späteren Wiederherstellung an. Dabei archiviert es nur tatsächliche Dateien, ungenutzte Bereiche des Dateisystems werden ignoriert. Für NTFS-Partitionen kommt "ntfs-3g" zum Einsatz. Mit der "SystemRescueCD" gibt es eine Live-CD, die das ganze Paket in handlicher Form enthält.
An dieser Stelle sei noch der Hinweis gebracht, dass fsarchiver im Zusammenspiel mit NTFS noch noch experimentell ist und es daher Probleme geben kann. In der Praxis bestehen die vor allem daraus, dass das Tool Dateien mit obskuren Eigenschaften nicht archivieren kann. In der kompletten Windows-Installation fand sich davon keine. Des Weiteren werden auf Dateisystemebene komprimierte Dateien unkomprimiert wieder hergestellt. Auch das ist nicht unbedingt ein Beinbruch. Während es mit Windows 7 einwandfrei lief, könnte es mit dem älteren und wesentlich zickigeren Windows XP vielleicht Probleme geben. Es wird nicht gern durch die Gegend geschoben. Aber das ist eine reine Spekulation von mir.
Ich gehe nun davon aus, dass die SystemRescueCD gebrannt wurde und im zu
sicherenden Rechner gestartet. Wer dabei Hilfe benötigt, findet sie in
der Doku. Des Weiteren ist die zu sichernde Festplatte /dev/sda, auf
dieser befindet sich eine typische Windows 7 Installation mit zwei
Partitionen:
- Eine 100MB Bootpartition
- Eine Partition mit dem System
Nach /mnt/nfs ist ein NFS-Share gemounted, auf welchem sich genügend
Platz befindet um das Backup aufnehmen zu können. Natürlich kann hier
auch jedes andere Medium eingesetzt werden. Wir befinden uns in diesem
Verzeichnis.
1. Sichern:
Zum Sichern der Daten beginnt man am besten mit dem Sichern des ersten
Sektor der Festplatte. Dieser enthält den MBR und die Partitionstabelle.
Natürlich ist dieser Schritt nicht zwingen notwendig und bei GPT so auch
gar nicht möglich, jedoch kann man sich durch ein späteres, einfaches
Wiederherstellen des MBR rumhantieren mit der Windows-CD zum Erneuern
der Windows-Bootchain sparen. Selbst wenn die Partitionierung nicht auf
die neue Platte passt, hat man zumindest einen Ausgangspunkt, welcher
Windows genehm ist: "dd if=/dev/sda of=mbr.img bs=512 count=1".
Nun können die Partitionen selbst gesichert werden. Der grundlegende
Syntax hierzu ist: "fsarchiver [options] savefs archiv.fsa /dev/device".
Bei den Optionen ist "-j N" sinnvoll, wobei N der Anzahl der CPU-Kerne
im System entspricht. Er nutzt dann alle Kerne zum Komprimieren. Zudem
lohnt es sich, gerade wenn das sich ergebende Archiv nicht länger
aufbewahrt werden soll, den Kompressionslevel zu senken: "-z 1".
fsarchiver nutzt eine LZMA-Kompression, selbst aus Level 1 ist diese
noch besser als der gute, alte Deflate-Algo von gzip und zugleich
schneller. Level 2 und 3 mögen auch noch okay sein, aber darüber
rechtfertigt der drastisch ansteigende Rechenzeitbedarf die paar
Prozente eingesparten Speicherplatz meist nicht mehr.
"fsarchiver -j 4 -z 1 savefs sda1.fsa /dev/sda1" sichert also unsere
erste Partition und "fsarchiver -j 4 -z 1 savefs sda2.fsa /dev/sda2".
Theoretisch könnten wir auch beide Partitionen in ein Archiv sichern,
jedoch sind mit irgendwie einzelne Archive lieber. Im Zweifel ist dann
nur eines im Eimer. fsarchiver wird die Dateisysteme mit ntfs-3g mounten
und auslesen, je nach Datenmenge dauert es durchaus mal einige Stunden.
Defekte Dateien (da er zum Beispiel die Blöcke nicht mehr lesen kann)
werden übersprungen.
2. Wiederherstellen:
Wiederherstellen hat im Prinzip den gleichen Ablauf. Die neue Festplatte
wird eingebaut und anschließend spielt man den gesicherten ersten Sektor
der alten Platte zurück: "dd if=mbr.img of=/dev/sda" Nun wird dieser mit
einem Partitionseditor wie "cfdisk" so editiert, dass die Partitionen
auf die neue Platte passen. Die erste Partition sollte auch weiterhin
100MB groß sein, die Länge der zweiten Partition ist egal. Jedoch muss
sie natürlich die Daten fassen können. Hierbei ist zu beachten, dass
Windows es mag, wenn die Partitionen auf 4k-Sektoren ausgerichtet sind.
Da fast alle neue Platten 4k-Platten sind, ist das sowieso eine gute
Idee.
Nun können wir die eigentlichen Dateisysteme wiederherstellen. Hierbei
übernimm fsarchiver die Drecksarbeit für uns, er erstellt sie mit den
korrekten Optionen. Wir sagen also zum Wiederherstellen der ersten
Partition: "fsarchiver -j 4 restfs sda1.fsa id=0,dest=/dev/sda1" Der
Wert
"id" gibt an, welche Dateisystem im Archiv wiederhergestellt werden
soll. Da wir nur ein Dateisystem pro Archiv gespeichert haben, ist "0"
immer richtig. "dest" ist die Zielfestplatte. Anschließend wiederholen
wir den Vorgang mit der zweiten Partition: "fsarchiver -j 4 restfs
sda2.fsa id=0,dest=/dev/sda2"
Windows sollte anschließend starten. Tut es dies nicht, muss man von der
Windows-CD booten und einmal die Option zum Reparieren des Systemstarts
wählen. Es ist sehr zu empfehlen, das Laufwerk C: einmal zu überprüfen.
Zudem sollte defragmentiert werden, denn ntfs-3g müllt wirklich extrem
herum.
An dieser Stelle noch einen letzten Hinweis: Es kann sein, dass Windows nach der Operation neu aktiviert werden möchte.
fsarchiver: http://www.fsarchiver.org
SystemRescueCD: http://www.sysresccd.org
24p Playback mit mplayer
Post #7 - yamagi - 03.09.2012 16:42
Inzwischen sind viele Filme - bzw. die meisten Filme in 1080p FullHD-Auflösung - sogenannte 24p-Aufnahmen. Sie haben 23.976 Bilder pro Sekunden, werden also exat so wie auf der Kinoleinwand abgespielt. Der große Vorteil daran ist, dass keine Bilder durch Interpolation eingefügt werden müssen, es ergibt sich also der gleiche Bildeindruck wie im Kino statt des "glibschigen" Video-Eindrucks. Nachdem 24p nun schon länger am Bluray-Player genossen habe, wagte ich nun das Abenteuer 24p-Playback am Computer. Dies ist gar nicht so einfach, weshalb ich kurz mein Setup erläutern möchte.
Voraussetzungen: Man benötigt natürlich erst einmal Display, was 24p nativ wiedergeben kann. Die meisten aktuellen Fernsehen sollten dies können. Des Weiteren ist ein guter Grafikkartentreiber Voraussetzung, unterstützt dieser es nicht, ist Hopfen und Malz verloren. Ich habe den Nvidia-Blob in Version 304.43 verwendet, Google liefert sehr widersprüchliche Aussagen zu anderen Treibern. Da müsste man eventuell selbst recherchieren. Zuletzt muss natürlich eine Datei mit 24p vorhanden sein.
Das Problem besteht darin, dass seit vielen Jahren Computermonitore mit 50 oder 60 Hertz angesprochen werden. Zu CRT-Zeiten waren es meist 85 Hertz. All diese Bildwiederholraten sind jedoch kein Vielfaches von 23.976, weshalb Bilder zwecks Synchronisierung eingefügt oder noch schlimmer weggelassen werden müssen. Die Folge sind Mikroruckler, das berüchtigte 24p-Stottern. Je größer das Display ist, umso schlimmer wird es. 26p Playback war an Computern zudem dadurch benachteiligt, dass kaum eine Software mit einer solch niedrigen Bitrate klarkam. Das hat sich inzwischen jedoch gebessert.
Nun aber zum Thema. Ich nutze Abspielprogramm mplayer. Er gibt auf meine
GeForce GTX 560 TI aus, welche per HDMI mit meinem Sony Bravia
KDL-32W5800 verbunden ist. Das TV unterstützt natürlich 24p. Auch wenn
die GPU mit VDPAU das Dekodieren der populärsten Codecs in Hardware
unterstützt, dekodiere ich in Software. Der Grund dafür ist, dass VDPAU
kein Hi10p-Profil unterstützt, daher viele meiner Dateien nicht
dekodieren kann. Man müsste manuell umschalten, was mit zu viel Aufwand
ist. Im einzelnen mache ich nun:
1. Das TV sollte als einziges Display an der Grafikkarte hängen, d.h.
alle anderen müssen in nvidia-settings oder per xrandr abgemeldet
werden. Sobald zugleich ein Display mit einer anderen Bildwiederholrate
angeschlossen ist, kommt es zu starkem Tearing. Das nervt.
2. Das TV wird auf 1920x1080@24 gestellt. Das bitte manuell im
nvidia-settings oder per xrandr machen, die "Auto"-Einstellung wählt die
höchste unterstützte Bildwiederholrate. Wenn 24 Hertz eingestellt sind,
ist die Maus schwerfällig. 24 Updates pro Sekunde sind einfach zu wenig.
Kann uns aber egal sein.
3. mplayer muss korrekt konfiguriert werden. Im einzelnen bedeutet dies,
dass man ihn auf so viele Threads zwingen sollte, wie die CPU Kerne hat.
Mehr Threads bringen nicht unbedingt was, schaden aber nie! Und gerade
Hi10p ruckelt bei zu wenig Threads auch gern mal. Des Weiteren darf sich
kein Videofilter in der Kette befinden. Jeder Filter kostet CPU-Zeit und
vermurkst das Timing, was mplayer zu Teils heftigen Reaktionen zwingt.
Diese äußern sich dann in "Extremrucklern", wie z.b. eine halbe Sekunde
Stillstand. Am wichtigsten ist allerdings der Videooutput aka "vo".
Normalerweise nutzt mplayer "xv", geht also über XVideo. Nun
unterstützt XVideo aber z.B. keine 10-Bit Planes, weshalb mplayer einen
Teil der Arbeit in Software machen muss. Das kostet CPU-Zyklen, vor
allem aber gibt es zwangsläufig wieder kleinere Probleme mit dem Timing.
Ich nutze daher "gl", was allerdings nur auf Grafikkarten mit guter
OpenGL-Unterstützung eine Option ist. VDPAU-Nutzer sollten hier "vdpau"
wählen.
Ist alles eingerichtet, sollten 24p-Aufnahmen ohne Mikroruckler wiedergegeben werden. Meine mplayer Konfiguration findest dich hier, vielleicht hilft sie dem einen oder anderen Nutzer: Github
Nvidia Driver 304.43
Post #6 - yamagi - 28.08.2012 15:14
Gestern hat Nvidia mit der Version 304.43 das zweite offizielle Release der 3xx-Serie freigegeben. Diese Serie bringt jede Menge tiefgreifender Änderungen, darunter unter anderem endlich vollständig Unterstützung für randr. Mit ist diese ehrlich gesagt völlig egal, aber den Nutzern integrierter Desktops wie Gnome, KDE und co. werden sich sicher sehr freuen. Können sie doch nun die Tools ihrer Desktopumgebung statt nvidia-settings nutzen und kommen in den Genuss der ganzen, auf randr basierenden Automagie. Für mich ist da die FXAA-Unterstützung schon viel interessanter, endlich gibt es auch abseits von Windows diese sehr effiziente, aber dennoch gut aussehende Anti-Aliasing-Technik. Ein weiteres interessantes Feature ist, dass man in nvidia-settings die einzelnen Monitore nun per Drag and Drop anordnen kann. Es spart einige Klicks. Zu guter Letzt ist der VSync in OpenGL-Awendungen nun per Default aktiviert. Sicher werden sich einige Nutzer darüber aufregen, jedoch begrüße ich es als Yamagi Quake II Entwickler sehr. Es sollte die E-Mail Flut hinsichtlich Tearing etwas eindämmen.
Ich scheibe diesen Post erst jetzt, da ich mit der Version 304.37 (dem
ersten Nicht-Beta-Release der 3xx-Serie) einige Probleme hatte. Diese
sind nun aber behoben. Im Einzelnen waren es:
- Beim Wechsel von Spielen vom Vollbild zurück auf dem Desktop, wurden
Fester zum Teil kleiner als Breite 0. Das quittierte Openbox mit einem
Crash. Ich hatte diesen Openbox-Bug schon vor längerer Zeit gemeldet
und im git ist er auch behoben, in ein Release hat er es bisher aber
noch nicht geschafft. Nun ist das Problem auch auf Treiberebene
behoben.
- Die Gamma/Brightness-Einstellung per SDL funktionierte nicht. Das
nervte schon sehr, denn viele Spiele basieren auf SDL.
Grundsätzlich würde ich mir noch wünschen, dass VDPAU Unterstützung für Hi10p bekommt. Allerdings war auf nvnews.net von einem Nvidia-Entwickler die Aussage gemacht worden, dass die Hardware-Dekoder der aktuellen GPUs dies schlicht nicht unterstützen. Es wird daher wohl vorerst ein Traum bleiben.
Zu guter Letzt noch ein kleiner Tipp: Man sollte sich entscheiden. Entweder man nutzt TwinView (nach wie vor vorhanden, unterstützt allerdings nur zwei Monitore) oder randr (unterstützt auf Kepler-Karten mehr GPUs). Beides zu Mischen scheint keine gute Idee zu sein. Ich konnte dabei einige interessante Dinge beobachten, z.B. fehlplatzierte Vollbild-Fenster bei Spielen.
Yamagi Quake II 5.00 kommt bald
Post #5 - yamagi - 23.08.2012 16:15
So, für alle Quake II Fans gibt es gute Nachrichten: Mein Quake II Port
wird voraussichtlich am übernächsten Wochenende in Version 5.00
erscheinen. Tatsächlich ist die auf Github
stehende Version bereits der Code, den ich zum Release machen will,
jedoch möchte ich die aktuelle "Test 3" Vorversion noch für einige
Zeit sickern lassen. Wer weiß, vielleicht findet ja noch jemand Fehler.
Neuerungen in 5.00 sind:
- Unterstützung für Microsoft Windows
- Unterstützung für OpenBSD
- Der Aspect Ratio kann nun im Video-Menü eingestellt werden
- Viele Kleinigkeiten, Bugfixes und so weiter
Die schlechte Nachricht ist, dass Version 5.00 voraussichtlich erst einmal das letzte, große Release sein wird. In der Zukunft werde ich mich auf Bugfixes und Anpassungen auf neue Compiler (da sollte es eigentlich keinen Ärger geben) beschränken. Es gibt zwar Dinge, die noch schön wären - z.B. Unterstützung für OS X - aber ehrlich gesagt fehlt es mir inzwischen an Lust und Zeit mich noch länger mit dieser kaputten Codebasis rumzuärgern. Neue Projekte, zum Beispiel etwas im Bereich Doom 3, warten. Pull-Requests werde ich allerdings mergen, solange der eingereichte Code Sinn und Verstand hat. Wer also etwas vermisst, muss selbst in die Tasten hauen. Für gelangweilte Coder gibt in der Datei CONTRIBUTE zudem einige interessante Projektverschläge. :)
Und wer weiß, frei nach dem Motto "Sag niemals nie!" zieht es mich vielleicht eines Tages zu Quake II zurück.