…and Urbans Blog-O-Mat

Zugegeben, TimeMachine Backups über SMB-Mounts werden offiziell nicht von Apple unterstützt. Daher hilft bei auftretenden Problemen alles jammern nicht, Lösungen müssen her. Immer wieder kann es vor allem bei zu kurzem Sicherungs-Intervall bzw. Unterbrechungen bei den Sicherungen zu einer Korruption des Sparsebundles kommen. Der Sicherungs-Intervall lässt sich sehr komfortabel mit der Freeware TimemachineEditor vergrößern, mir persönlich  reicht 1 Backup / Tag.

Sollte die TimeMachine die Sicherung aufgrund eines Fehlers ablehnen, sind Reparaturmaßnahmen erforderlich.

Vor der Aktion mit dem Festplatten-Dienstprogramm weiter unten sollte man das Sparsebundle komprimieren und optimieren. Hierzu kommt der Terminal-Befehl hdiutil compact zum Einsatz. Wichtig dabei: Das Volume innerhalb des Sparsebundles darf nicht gemountet sein, ist also mit “xxxx auswerfen” über den Finder zu entfernen.

Copy/Paste Befehl:

hdiutil compact \
 -batteryallowed \
 -sleepallowed \
 -verbose \
 /Volumes/TimeMachine/xxxxx.sparsebundle

Hat die Optimierung geklappt folgt ein Reparaturversuch mit dem Festplatten-Dienstprogramm. Hierzu ist das Verzeichnis, welches das Sparsebundle enthält, einfach per Finder zu verbinden, sodass das Volume es im Festplatten-Dienstprogramm erscheint. das sparsebundle links in der Liste selektieren und den Button ” Volume reparieren ” anklicken. ” Volume überprüfen ” kann man sich schenken.

• http://www.readynas.com/forum/viewtopic.php?f=71&t=34321

Leider kommt es trotz aller Maßnahmen zu irreparablen Sparsebundles. Daher bin ich nun dazu übergegangen, das sparsebundle via ROBOCOPY mithilfe eines geplanten Tasks auf eine externe USB-Disk zu sichern. Das geht sehr schnell und hat mich mittlerweile auch schon so manches Mal davor bewahrt eine vollständig neue TimeMachine aufzusetzten.

Durch dieses Werk nimmt mein Liebäugeln mit Git weiter Fahrt auf. Für mich war es stets elementar, den geschichtlichen Hintergrund zu kennen, um mich für ein Werkzeug zu begeistern. Und dieses wird auf den ersten Seiten des Buches sehr gut dargestellt.

Siehe auch:

• After controversy, Torvalds begins work on “git”
• http://en.wikipedia.org/wiki/Git_(slang)
• http://de.wikipedia.org/wiki/Git

Als alter Unixer läuft bei mir stets ein Terminal mit “tail -f /var/log/system.log“. Mein AppleScript Projekt …. schreibt zu Kontrollzwecken über den logger Befehl ebenfalls in dieses Logfile. Aufgrund eines Progammfehlers lief das Script nicht mehr, aber in der System.log taucht jedesmal folgende Zeile auf:

...
/System/Library/CoreServices/AppleScript Runner.app/
Contents/MacOS/AppleScript Runner[3844]: CPSGetFrontProcess():
This call is deprecated and should not be called anymore.
...

Selbstverständlich suchte ich die Ursache dafür in meinem Code, konnte aber nichts finden. Und CPSGetFrontProcess() sagte mir nun rein gar nichs. Die Meldung erschien jedesmal, wenn ein Script als Ordneraktion ausgeführt wurde, im AppleScript Editor ausgeführt erschien sie nicht. Also googelte ich um Hilfe und wurde auch an diversen Stellen fündig. Offensichtlich schleift MacOSX diese Meldung schon seit eingien Jahren mit sich herum. Es ist ein Hinweis für die Entwicker des AppleScript Runners, also dem Stück Software, welches die Scripte laufen lässt. Darin wird anscheinend immer noch die Funktion CPSGetFrontProcess() benutzt, obwohl sie nicht mehr verwendet werden sollte. Es ist also eine Meldung, für die man selbst keine Schuld hat, sie aber auch nicht abstellen kann. Das wollte ich testen und habe einfach mal ein paar Orginal-AppleScripte als Ordneraktion angehängt. Und tatsächlich werden auch hiermit diese Meldungen ins system.log geschrieben. Man müsste mal hochrechnen, wie viele Macs weltweit im Einsatz sind und wie viele davon AppleScripte verwenden. Bei jeder Ausführung eines solcher Scripte wird seit Jahren eine solche Zeile ins Logfile eines jeden Rechners geschrieben. Auch eine schöne Variante einen Computer zu beschäftigen.

Mich stört so etwas jedenfalls ungemein, hauptsächlich jedoch, weil man stundenlang durch solche unnötigen Meldungen bei der Fehlersuche von eigenen Programmen fehlgeleitet wird. Na klar, auch bei einer solchen Geisterjagd wird man nicht dümmer, aber es hält einen doch sehr davon ab, sein eigentliches Ziel zu verfolgen.

Wenn man einer Siemens Activy nachträglich eine 1TB Festplatte spendiert, entsteht das Problem, dass der Activy Installer das Embedded XP dort nicht “auf natürlichem Weg” installieren kann. Man muss den Umweg über die vorherige (250GB) Platte machen. Bis man darauf  kommt, können schon mal ein paar Tage Lebenszeit vergehen. Neuerdings hatte ich wieder mal einige Probleme mit dem Gerät und kam nicht umhin, die System Platte zurückzusetzen. Natürlich habe ich mir vorher nicht aufgeschrieben, welche Installations-Jonglage mit einer 1TB Platte erforderlich ist. Daher gab es wieder einige Stunden Probiererei. Damit dieses nicht nochmal passiert, werde ich hier zusammentragen, was bei der Kiste zu beachten ist.

Vorab die technischen Daten der Activy:

• Software-Version: 3.2.419
• APP Version: 3.2.30
• GUI Version: 3.3.1.16
• Number of boards: 3 (2 active)
• DV Hardware: yes
• Frontpanel: Model: 50 PreRealase: 32 Version 1: Release: 0

Die Platte der Activy besitzt 3 Partitionen:

• C: SYSTEM
• D: BACKUP
• E: CONTENT

• Einleiten einer Systemwiederherstellung der Activy (Restore):

Das Gerät ausschalten und wieder einschalten. Möglichst früh die Taste “5″  festhalten. Dadurch erscheint ein Menü, in dem man auswählen kann, ob man einen “Restore 1″ machen möchte, oder eine vollständige Initialsierung des Systems.
Das wäre ja auch alles ganz schön, aber leider (wie eingangs erwähnt) kann der Original-Installer der Activy mit einer Monster 1TB Platte nichts anfangen.

Der für mich gangbare Weg führte über eine kleinere Platte (250GB). Auf dieser wird ein Standard Activy-System aufgesetzt. Anschliessend wird von den 3 Partitionen dieser Platte je ein dd-Image gezogen und diese auf die vorbereite 1TB Platte zurückgeschrieben.

• Partitionen mit “dd” in Images kopieren:

Wie man Festplatten-Partitionen in Images schreibt, ist in dem folgenden Artikel sehr schön zusammengetragen worden.
http://digitalewelt.freenet.de/sicherheit/datenschutz/daten-retten-mit-dd-und-dd-rescue_506278_275536.html

• Uups, eine Fehlermeldung:

Fehlermeldung .NET Framework. Genau diese Fehlermeldung ist hier sehr schön beschrieben worden, dieser Thread hätte von mir sein können. Weiterhin erschienen keine tvtv.de EPG-Listen mehr, die Listen blieben komplett leer. Weiterhin ließ sich über Zugriff DeLuxe kein Windows Explorer oder ähnliches mehr starten. Im Forum wurde in diesem Fall auch empfohlen, einen “Restore 1″ zu machen. Damit ist gemeint, dass man das System (Platte C:)  neu aufsetzt, die Daten und Aufnahmen jedoch erhalten bleiben.

• Endlos-Reboot unterbrechen

In  E:\persist\private\ActivyApplKeys.ini den Wert EnableLcdDisplaySupport=0 setzen.
Ganz WICHTIG: Der Wert kann in der Ini-Datei mehrmals eingetragen sein, doppelte Einträge gleich löschen.

• Weitere Befehlszeilen

In diesem Beispiel werden die Platten via USB-SATA Adapter an den Mac gehängt. Selbstverständlich funzt das ganze auch mit anderen Betriebssystemen.

Prüfen der gemounteten Partitionen und ermitteln der Devices
~ > df
Filesystem    512-blocks      Used Available Capacity  Mounted on
/dev/disk1s5     6345608     50024   6295584     1%    /Volumes/BACKUP
/dev/disk1s2     6345672   4854728   1490944    77%    /Volumes/SYSTEM
/dev/disk1s6   471491584    627456 470864128     1%    /Volumes/CONTENT


Sicherungsverzeichnis für die Images anlegen

~ > mkdir ~aur/Documents/Activy.images
~ > cd ~aur/Documents/Activy.images


Pro Partition je ein Image mit “dd” sichern und sofort mit “bzip2″ komprimieren


~ > dd if=/dev/disk2s2 bs=809200 |\
bzip2 -9 > ~aur/Documents/Activy.images/activy.SYSTEM.bz2
~ > dd if=/dev/disk2s5 bs=809200 |\
bzip2 -9 > ~aur/Documents/Activy.images/activy.BACKUP.bz2
~ > dd if=/dev/disk2s6 bs=809200 |\
bzip2 -9 > ~aur/Documents/Activy.images/activy.CONTENT.bz2


z.B. Zurücksichern der SYSTEM Partition auf der 1TB Platte vom Image der 250GB Platte

~ > umount /Volumes/SYSTEM
~ > bzip2 -cd ~aur/Documents/Activy.images/activy.SYSTEM.bz2 |\
dd of=/dev/disk2s2 bs=809200


Durch CVS bin ich das erste Mal mit einer Versionsverwaltung in Berührung gekommen und seit dieser Zeit “mach ich’s nicht mehr ohne”. SVN habe ich seit den Anfängen verfolgt und konnte kaum das erste stable-release abwarten. Bislang habe ich noch nie einen Datenverlust bzw. -bschädigung erfahren und arbeite mit “Hosenträger UND Gürtel”. Doch dir Welt dreht sich weiter. Über einen Artikel in einer Fachzeitschrift stieß ich auf Mercurial und war sehr interessiert. “Git” hatte ich zwar auch schon gehört, aber nicht wirklich verfolgt.

Doch dann fand ich http://de.whygitisbetterthanx.com/
Über diese Vergleichsseite trat nun wiederum “Git” in meinen vordersten Fokus, vor allem, weil es dafür bereits eine Schildkröte für den Windows-Explorer gibt, als auch mit EGit [zu deutsch:"Igitt"   ] ein Plugin für Eclipse.
Weiterhin ist wichtig, dass die Gemeinde um dieses Tool “lebt” und dass es Mirgrationsmöglichkeiten vom SVN gibt.

Noch habe ich nicht die Muße gefunden, mich tiefer damit zu befassen, kann aber nur noch eine Frage der Zeit sein.

Weiterfühernde Links:

Aufgrund meiner Erfahrung mit Java, verwende ich für meine PHP Entwicklungen analog Eclipse for PHP als IDE. Seitdem ich auf WordPress 3.x umgstiegen bin und diesen Code ebenfalls ins Eclipse geladen habe, bewegte sich alles nur noch wie in dickem Brotteig, regelmäßig wurden mir Fehler um die Ohren gehauen wie:

!ENTRY org.eclipse.core.jobs 4 2 2010-09-25 17:12:57.455
!MESSAGE An internal error occurred during: "Semantic Highlighting Job".
!STACK 0
java.lang.OutOfMemoryError: Java heap space
 at org.eclipse.php.internal.core.ast.scanner.php53.CUP$....

Die Suche nach der Lösung bzw. Linderung führten mich in die gefürchteten Abgründe diverser Developer Mailforen, wo ein Stackdump mit dem nächsten beantwortet wird. Nicht unbedingt förderlich ist dabei meine Plattform (Mac, Snow Leopard). Aber schließlich wurde dann doch fündig

In der Eclipse.app befindet sich die eclipse.ini zur Steuerung der Java-VM.
Hier meine aktuellen Einstellungen, mit denen sowohl mein selbstkompliliertes Subversion-JavaHL sauber erkannt wird, als auch kein Java Heap Space Error mehr auftaucht. Die IDE-Perfomance ist wieder so fix wie früher, ich habe endlich wieder das Gefühl auf meinem lokalen Rechner zu arbeiten und nicht in einer VM, welche ich über min. 3 dazwischengeschaltete Remote-Sessions bediene.

Inhalt von:
/Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini

-startup
../../../plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.0.v20100503
-product
org.eclipse.epp.package.php.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
768m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=768m
-Xms128m
-Xmx1024m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Djava.library.path=/usr/local/subversion/lib