Archive for the 'Virtuelle Welt' Category

Von Vista auf Windows 7

Dieses “Windows-wechsel-dich”-Spielchen habe ich auch mal mitgemacht. Schließlich hatte ich ja mal die Möglichkeit angeboten bekommen Windows 7 zu benutzen und das Vista, dass ich auf einem Laptop hatte, war auch nicht ganz das Gelbe vom Ei.

Da ich ein Haufen Programme nutze – ich kann eine Liste von mindestens 30 Programmen aufzählen – dachte ich mir, ok machst du die Upgrade-Installation. Immerhin waren die Versionen passend zueinander. Nach zirka ein einhalb Stunden ist das dann auch über die Bühne gegangen.

Danach schaute ich erstmal, ob alles an Software läuft, was laufen soll. Virtual Box lief zwar, aber der Virtualisierungssoftware fehlten die Treiber, damit man seinen Gastbetriebssytemen Netzwerk zur Verfügung stellen kann. Mit der Neuinstallation des Programmes war dieses Problem erledigt.

Bei meinem Office 2010 Beta erlebte ich allerdings eine böse Überraschung. Word schmierte kurz nach dem Start ab, Outlook pflegte sich bei Klick auf den Reiter “Datei” in die Versenkung zu begeben. In beiden Fällen war immer eine kernel32.dll im Ordner C:/Windows/System32 beteiligt. Ich versuchte Office zu reparieren,  neu zu installieren und im Kompatibilitätsmodus von Windows XP und Vista laufen zu lassen. Nichts funktionierte. Zum Schluss habe ich mir Windows 7 in eine VM installiert und von dort die kernel32.dll kopiert und dann mittels Ubuntu Live CD über die andere drüber kopiert. Brachte auch nicht den ersehnten Erfolg.

WordFehlermeldung

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: WINWORD.EXE
Anwendungsversion: 14.0.4536.1000
Anwendungszeitstempel: 4af1d344
Fehlermodulname: kernel32.dll
Fehlermodulversion: 6.1.7600.16385
Fehlermodulzeitstempel: 4a5bdaad
Ausnahmecode: c0000005
Ausnahmeoffset: 0004f03d
Betriebsystemversion: 6.1.7600.2.0.0.256.48
Gebietsschema-ID: 1031

Zusatzinformationen zum Problem:
LCID: 1031
skulcid: 1031

Outlook Fehlermeldung

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: OUTLOOK.EXE
Anwendungsversion: 14.0.4536.1000
Anwendungszeitstempel: 4af1d60f
Fehlermodulname: kernel32.dll
Fehlermodulversion: 6.1.7600.16385
Fehlermodulzeitstempel: 4a5bdaad
Ausnahmecode: c0000005
Ausnahmeoffset: 0004f03d
Betriebsystemversion: 6.1.7600.2.0.0.256.48
Gebietsschema-ID: 1031

Zusatzinformationen zum Problem:
LCID: 1031
skulcid: 1031

Eigentlich hätte ich Office ignorieren können, weil zum Schreiben von Text nehme ich auch ganz gerne mein OpenOffice her, allerdings benötige ich zum Arbeiten ein Exchange-fähiges E-Mail Programm. Thunderbird und Co. scheiden da aus. Zusätzlich zu diesem Problem, war der Start von Windows 7 auf meinem Rechner ungewohnt langsam. Nach Eingabe des Passwortes dauerte es mehrere Sekunden, bis ich den Desktop zu sehen bekam.
Jetzt, nach der Neuinstallation, sind bisher keine solche extremen Aussetzer aufgetreten. Zwar ist nach der Installation von Windows 7 das Ganze in einer Installtions-Orgie gemündet, aber dafür habe ich nun aktuelle Software auf dem System.

Kernel kompilieren mit Problemen

So was wie den eigenen Linux Kernel kompilieren kennen die meisten Linuxer mitunter. Ich – ja, ich gebe es zu – habe mich vorher fein säuberlich davor gedrückt. Stattdessen habe ich diesen dann über die Paketverwaltung ( bei SuSE mittels YaST ) installiert.

Nun, mit einem virtuellen Slackware sowie dem aktuell stabilen 2.6.32.8 Linux Kernel von kernel.org bewaffnet, habe ich mich mal an das Thema gewagt. Für das nötige Wissen mussten drei Tutorials herhalten (http://www.selflinux.org/selflinux/html/kernel02.html ; http://www.teamunix.de/howto/linuxkernelhowto.php ; http://www.pro-linux.de/NB3/artikel/2/860/kernel-kompilierung.html )

Um es mal ab zu kürzen: Mein erster Kernel ließ sich ohne Probleme kompilieren (max. 1 – 2 Warnings), nur als ich dann den Bootloader soweit hatte und das System eben mit diesem Kernel starten wollte, endete das ganze Unternehmen in einer Kernel Panic. Der zweite Anlauf verlief auch nicht gerade besser. Immerhin hatte ich da dann eine Initiale Ramdisk angelegt, so dass kein Kernel Panic Fehler mehr kam. Dafür wollte dann die Root-Partition partout nicht gefunden werden. Irgendwann, nach der vielen Bastelei habe ich das System soweit geschrottet, das kurzum nichts mehr normal lief. Also nochmal alles neu installiert, um wieder eine saubere Grundlage zu haben.

Mittlerweile bin ich beim dritten Versuch gelandet. Die Root-Partition bleibt auf weiteres für den neuen Kernel verschollen, doch mittlerweile bekomme ich wenigstens die Möglichkeit auf eine Shell im Single User Mode (Runlevel 1 bzw. S) zu operieren.

Allerdings habe ich mittlerweile eine Vermutung, woran das liegen könnte. Bei Slackware ist es üblich z.B. die erste Festplatte eines Systems mit /dev/hda zu bezeichnen. Bei anderen Distris heißt die dann meistens /dev/sda. Wenn dem so ist, darf ich dann die fstab unter /etc umschreiben und hoffen, dass es dann läuft.

UPDATE:

Nachdem ich die fstab und die mtab Datei geändert habe – nämlich von /dev/hd* auf /dev/sd* – kam das System ohne Meckern mit dem neuen Kernel hoch. Boah, nach drei Anläufen geht es endlich!

Sendmail? Postfix? – Was denn nun?

Da liegt es vor mir, wie ein großer weißer Fleck auf einer Landkarte: Das Thema Mailserver unter Linux. In dieses Thema hineingerutscht bin ich dadurch, dass ich auf einer Ubuntu-Kiste eine Software namens Munin installiert habe, die z.B. die Festplattennutzung oder die CPU-Auslastung von Rechnern innerhalb eines Netzwerkes überwachen kann. Munin hat auch die Möglichkeit Mails zu verschicken, wenn nun eine Festplatte droht voll zu laufen. Nur braucht man dazu eben einen Mail Transfer Agent (MTA) wie sendmail bzw. postfix.

Jo, und ich hab noch nie sowas eingerichtet bzw. noch nie einen Mailserver zusammengebastelt. Ich weiß gar nicht so recht wo ich bei diesem Thema anfangen soll. Vielleicht erst mal mit dem Begrifflichkeiten. Und dann wäre noch die Frage, welche MTA nehme ich zum Anfang? Zu beiden habe ich sehr unterschiedliche Meinungen gehört. Postfix wäre extrem mächtig und zu sendmail habe ich diesen passenden Satz gelesen: “sendmail ist der Alptraum jedes Administrators.”
“Oh, Gott!”, war da mein gedanklicher Ausspruch dazu. So nach dem Schema, welches ist denn wohl das geringere der beiden Übeln. Bisher bin ich auch noch nicht viel weiter mit diesem Thema. Ein passendes Anfänger-Tutorial suche ich noch.

Mein PHP-Skript: Läuft auf einem Linux-XAMPP aber nicht auf der Windows Version

Ich hänge momentan an einem ziemlich – aus meiner Sicht – absurden Problem. Ich habe ein PHP-Skript erstellt, das zu einem Datenbankfrontent gehört. An sich funktioniert dieses Skript auch – es gibt keine Syntaxfehler oder sowas.
Es lief auch alles ganz fein bis ich das ganze mal auf einem Rechner mit Windows Vista Business und XAMPP 1.7.2 ausprobierte. Dann funktioniert in einer einzigen Datei (namens command.php) der Aufruf von header(“Location: index.php”) überhaupt nicht mehr, während dieser Aufruf allerdings in meinen anderen PHP-Dateien einwandfrei ausgeführt wird. Vorher lief das Ganze auf einem Linux System. Da ich das ganze nocheinmal nachkontrollieren wollte, habe ich schnell meinen virtuellen Ubuntu-Server hergenommen und genau die selbe Version (nur für Linux eben) installiert und es läuft ALLES!

Bei Windows währenddessen geht alles bis jener Aufruf in der command.php. Ich weiß nicht, was da falsch sein soll. Mittlerweile habe ich den Inhalt dieser Datei auf diesen einzigen Aufruf reduziert, nur um alle anderen Fehlerquellen durch anderen Code in dieser Datei auszuschließen. Ergebnis ist das selbe: es geht nicht!

Langsam bin ich am verzweifeln, weil ich nicht mehr weiter weiß und mir das Ganze mittlerweile aus dem Hals heraushängt.
Den selben Test habe ich noch einmal auch auf einem Windows XP Professional durchgeturnt mit genau dem selben Effekt wie bei Vista. Ähnlichen Effekt lässt sich auch auf Linux erzielen, wenn man statts den XAMPP sich das Apache-Packet z.B. von Ubuntu installiert, was zum Beispiel automatisch bei der Server Variante geschieht, wenn man die Option LAMP-Server wählt. Da läuft dieses Skript auch nicht.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/**
	@file form-chooser.php :
	Weiterleitungen auf andere Formulare
	Dieses Script leitet vom Formular @file add-device.php
	auf nachfolgende Formulare um, je nach Geraetetyp
*/
	switch ($_POST['devtype'] ) {
		case "phone": {
			header("301 Moved Permanently");
			header("Location: index.php?action=phone-form");
			break;
		}
		case "computer" :  {
			header("301 Moved Permanently");
			header("Location: index.php?action=computer-form");
			break;
		}
		case "printer": {
			header("301 Moved Permanently");
			header("Location: index.php?action=printer-form");
			break;
		}
		default: {
			header("301 Moved Permanently");
			header("Location: index.php?action=error");
			break;
		}
	}

Dieser gezeigte Code geht, wenn man ihn über den Klick auf einen Button eines vorhergehenden Formulars aktiviert.
Der Code in der command.php hat eine ähnliche Struktur bzw. er befindet sich ebenfalls in einem switch-case-Konstrukt. Zu Test Zwecken habe ich den Code in der command.php auf folgendes reduziert:

header("Location: index.php);

Auch die Angabe des vollen Pfades bringt hier nichts.
Und genau dieser Umstand lässt das Ganze so absurd erscheinen. Ich persönlich weiß nicht, woran es noch liegen könnte. Ich habe schon folgende Punkte ausgeschlossen:

  • Berechtigungen unter Vista: Kann nicht sein unter XP läufts ja ebenfalls nicht.
  • Fehlende PHP-Bibliothek: Kann nicht sein, da header() praktisch zum Standard-Umfang gehört. Und zweitens funktioniert der Aufruf in anderen meiner Skripte auch.
  • Falsche Einstellungen am XAMPP vorgenommen: Ich fasse bei XAMPP keine Config-Files an.
  • Unterschiede in den XAMPP-Versionen: Ich habe auf allen Testsystemen ein und die selbe Version 1.7.2 installiert.

Virtualisierung

… ist eine feine Sache, wie ich finde. Da kann man mal was ausprobieren, ohne ein Produktivsystem zun zerschießen. Ich nehme für diesen Zweck das freie Sun VirtualBox her, um entsprechend virtuelle Maschinen anzulegen und diese zu testen. Und diese virtuellen Maschinen sind bei mir im Moment bevorzugt Serversysteme. Schließlich soll der kleine Admin (bzw. ich) damit umgehen lernen.

Inzwischen läuft auch schon ein kleiner Ubuntu 9.10 Server (sprich die Ubuntu-Varinte, die von Haus aus keine grafische Benutzeroberfläche mitbringt). Ein Windows 2003 Server fehlt da ebenfalls nicht in meiner kleinen Sammlung – immer bereit, um daran herum zu spielen. Nur fehlen mir manchmal nur die entsprechenden Übungen, die ich an den Systemen ausführen könnte. Bei Linux werde ich mich da an die Lehrpläne zu den LPIC Leveln halten. Bei Windows weiß ich nicht so genau, was da ein “guter Admin” können soll.

Pakete, die Inkscape unter Slackware braucht

Gelegentlich, wenn ich mal eine Inspiration habe, nehme ich ganz gerne Inkscape (Paketname: inkscape-0.45-i486-1arf.tgz) für Vektorgrafiken.
Unter meinem alten Suse war die Installation ziemlich easy, denn Yast schaute automatisch nach den Paketabhängigkeiten.
Jetzt, unter Slackware, gestaltete sich die Installation nicht ganz so einfach. Zwar gibt’s auf linuxpackages.net ein Paket namens Inkscape, aber da Bibliotheken wie gtkmm und noch etliche andere fehlen, muss man sich diese erst zusammensuchen.

Mein erster Ansatz war die Bibliotheken von den jeweiligen Projektseiten herunterzuladen, um sich anschließend selbst zu compilieren. Allerdings stellte sich das Compilieren des Source als ziemlich nervenaufreibender Vorgang heraus. Mal fehlte diese oder jene Bibliothek, hier und da waren die Abhängigkeiten nicht erfüllt oder es endete alles mit einem make Fehler.
Anschließend habe ich dann mein Glück wieder auf linuxpackages.net versucht und mir die passenden Pakete zusammengesucht. Und das waren übrigens diese:

  • gtkmm-2.12.8-i486-1mfb.tgz
  • glibmm-2.16.4-i486-1mfb.tgz
  • libsigc++-2.2.3-i486-2mfb.tgz
  • gc-7.1-i486-2mfb.tgz
  • cairomm-1.6.4-i486-1mfb.tgz

Netbeans in der Endlosschleife

Bevor ich anfange mich über dieses merkwürdige Verhalten von Netbeans 6.7.1 für C/C++ auszulassen, kurz eine Einleitung.

Momentan experimentiere ich mit Qt in der aktuellen Fassung 4.5. Damit ich das GUI-Framework mal richtig kennen lerne, programmiere ich mir die GUI von Hand zusammen, anstatt sie mir von QtCreator erstellen zu lassen. Ich hatte auch einen Quelltext auf das Nötigste reduziert, nur bekam ich beim Compilieren und anschließenden Linken immer den Fehler “undefined reference to vtable BLABLA“. Entweder wollte er da den Constructor oder den Destructor nicht annehmen. Irgendwann bin ich auf die Idee gekommen, dass es am Makefile liegt. Daher schnell ein neues, auf vorhandenem Code basierendes Projekt erstellt.

Ich habe Netbeans schön brav einen neuen Ordner, wo ich den C++ Quelltext hineinkopiert hatte, genannt und die automatische Konfiguration angeworfen. Netbeans fängt an zu rattern, die CPU-Auslastung geht nach oben und die Mausbewegungen werden immer träger. Irgendwie kommt mir das äußerst seltsam vor. Ich greife hilfesuchend zur Konsole, tippe ein

ps -A

, um mir die laufenden Prozesse anzuzeigen, die gerade auf meinem Rechner laufen.

Und da staunte ich nicht schlecht, als ich mehrere gmake- im Wechsel mit sh-Instanzen sah. Ein getipptes

killall gmake

konnte diesen Zirkus auch nicht so einfach beenden. Dafür waren es wohl schon zu viele gmake-Prozesse. Ergo, Zwangsneustart! Dann habe ich das ganze Spiel noch einmal von neuem probiert, nur um mal sicherzustellen, ob sich dieses Verhalten reproduzieren lässt. Und das tat es. Ich habe bei meinen Versuchen herausgefunden, dass ich beim kopieren der Quelltextdateien aus Versehen das Makefile des alten Projekts mit kopiert hatte.

Hier mal ein Screenshot, wie ein normales Projektverzeichnis unter Netbeans aussieht:

netbeansverz

Das Makefile enthält einige Standarddefinitionen und Verweise auf Makefiles, die sich im nbproject-Ordner befinden.

netbeansverz1

Der Ordner build beinhaltet die sogenannten Objektdateien (also die mit der Endung .o) und dist das compilierte Programm. In meinem Projekt-Verzeichnis fehlten die Ordner build, dist und nbproject.  Jedoch braucht das Makefile den Ordner nbproject unbedingt, wegen den Verweisen auf die weiteren Makefiles. Da dieser samt Dateien fehlte, hing Netbeans durch die ständigen sh und gmake Aufrufe in einer Endlosschleife fest.

Da hilft dann nur schnell killall gmake auf der Konsole oder – wenn es schon zu viele Prozesse sind bzw. der Rechner einfach nicht mehr reagiert – Resettaste drücken. Scheint wohl einer Art Bug zu sein.

Slackware auf meinem Acer TravelMate 2490

Knapp vier Tage (12.08.2009) sind es her, seit dem ich meine bisherige OpenSuSE 10.3 von der Laptop Festplatte gefegt und anschließend Slackware Linux in der Version 12.2 installiert habe.

Bevor ich mich allerdings dazu entschlossen habe die Installtion durchzuführen, habe ich mich etwas in das Betriebsystem mittels einer Testinstalltion eingearbeitet. Als Linuxerin mit Erfahrung hatte ich mit dem textkonsolenbasierten Installieren und Einrichten des Systems nicht allzu viele Probleme. Man muss zunächst Patritionen für Linux auf seiner Festplatte anlegen, die bei mir schon bestanden. Allerdings habe ich Veränderungen in der Größe meiner drei Linux-Patritionen (/,/home und der Swap-Patrition) vorgenommen. Slackware bietet hier einem z.B. das Konsolenprogramm fdisk. Die angenehmere Variante zu diesem Programm stellt cfdisk dar, das ein an den nano-Editor erinnerndes Menu anbietet. Hat man seine Patritionen beisammen, kann man per Eingabe von setup mit der Installtion beginnen.

Hat man die nötigen Konfigurationen für setup vorgenommen, sodass man mit der eigentlichen Installation der Software anfangen kann, wählt man der Bequemlichkeit halber die Full Installtion. Slackware installiert dann alle Packete der insgesamt drei Installtions-CDs. Ich habe mich bei meiner Installtion ebenfalls dafür entschieden und als Standard-Window-Manager KDE gewählt. Ist alles installiert, geht’s an’s Booten und Starten des Systems.

Als richtiges Old School Linux startet diese normaler Weise im vollen Mehrbenutzerbetrieb auf der Konsole (auch Runlevel 3 genannt). Anmelden tut man sich zunächst als root, da man noch keine weiteren Benutzer erstellt hat. Nachdem Anmeldevorgang wird’s Zeit für ein bisschen grafische Oberfläche – man darf jetzt startx tippten und die Desktopumgebung wird geladen. Was mir gleich beim Blick auf den Desktop aufgefallen war, war die etwas ärmliche Auflösung von 1024 x 768. Auch wirkten die Schriften nicht ganz so klar, wie ich es vorher von SuSE gewohnt war. Das war der Auftakt zum Basteln. Bevor ich mich dem Grafiktreiber zugewenedet habe, sorgte ich erst einmal dafür, dass ich per WLAN ins Netz kann. Im Laptop ist ein Broadcom Teil verbaut. Die Eingabe von lspci nennt mir das:

root@HAL-9000:/# lspci
....
06:01.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
06:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
...

Slackware erkennt zwar das Gerät und ordnet ihm auch einen Treiber zu, allerdings funktioniert dieser bei mir WLAN-technisch gesehen nicht. Ich kann zwar per

iwconfig wlan0 essid DEIN_NETZ

den Namen des Netzwerkes setzen, nur kann man dann nicht den passenden Accesspoint (Router) setzen, was bekanntlich über

iwconfig wlan0 ap IP_DES_ACCESSPOINTS

funktioniert.
Daher greife ich zum Ndiswrapper und verwende folgende namentlich genannte Windows-Treiberdatei: bcmwl5a.inf. Mit dieser habe ich auch schon unter SuSE gute Erfahrungen gemacht.

Als das WLAN lief, wollte ich mich gleich an das Problem der mauen Auflösung machen. Mir fielen da auch gleich zwei Anlaufstellen ein, die ich gleich bearbeiten konnte:

  1. Die Konfiguration des XServers (xorg.conf)
  2. Wahl eines anderen Treibers

Ok, den Installationsprozess des Treibers wollte ich mir zunächst nicht antun, daher unternahm ich ein paar Experimente mit der xorg.conf. Und an dieser Stelle geb ich es auch gerne zu: das war die erste Begegnung mit dieser Datei mit mir. In dieser Datei gibt es mehrere Bereiche z.B. für das Gerät (Device) oder den Bildschirm (Screen).

# **********************************************************************
# Screen sections
# **********************************************************************</code>
 
# Any number of screen sections may be present.  Each describes
# the configuration of a single screen.  A single specific screen section
# may be specified from the X server command line with the "-screen"
# option.
Section "Screen"
Identifier  "Screen 1"
Device      "VESA Framebuffer"
Monitor     "My Monitor"
 
# If your card can handle it, a higher default color depth (like 24 or 32)
# is highly recommended.
 
#   DefaultDepth 8
#   DefaultDepth 16
DefaultDepth 24
#   DefaultDepth 32
 
# "1024x768" is also a conservative usable default resolution.  If you
# have a better monitor, feel free to try resolutions such as
# "1152x864", "1280x1024", "1600x1200", and "1800x1400" (or whatever your
# card/monitor can produce)
 
Subsection "Display"
Depth       8
Modes "1024x768" "800x600" "640x480"
EndSubsection
Subsection "Display"
Depth       16
Modes "1024x768" "800x600" "640x480"
EndSubsection
Subsection "Display"
Depth       24
Modes "1024x768" "800x600" "640x480"
EndSubsection
Subsection "Display"
Depth       32
Modes "1024x768" "800x600" "640x480"
EndSubsection
 
EndSection

Ok, so dachte ich mir, änderst du mal was unter dem Modus-Feld. Nachdem ich die Änderungen in die Datei eingetragen hatte, musste ich mich zunächst wieder in den Runlevel 3 begeben, um im Textkonsolen den XServer mittels startx erneut zu starten. Angezeigt wurde mir allerdings immer noch eine Auflösung in 1024 x 768. Diese ließ sich auch nicht im entsprechenden KDE Modul ändern.
Da ich mit dem XServer nicht weiter kam, musste ich mir wohl oder übel einen neuen Treiber suchen für meinen Intel Grafikchip: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03). Fündig bin ich dann auf der Seite von Intel geworden. Compilieren des Treibers war auch so eine nette Angelegenheit: das Teil wollte unbedingt das, dass sich im Verzeichnis des XServers die Header zur Mesa 3D Bibliothek befinden. Da ich mir nicht den XServer zerschießen wollte, habe ich dann den Treiber ohne die Mesa-Anbindung compiliert und installiert. Anschließend per XOrg -configure mir eine neue Konfigurationsdatei anlegen lassen und es funzte. Jetzt benutze ich eine wesentlich angenehmere Auflösung von 1280 x 800 mit klarem Bild auf dem Bildschirm. Eine Wohltat für die Augen!

Zum Abschluss meiner Installation habe ich noch benötigte Software wie OpenOffice und Netbeans draufgeschmissen. Bisher bin ich mit meinem System soweit zufrieden. An anderen Stellen muss ich dann wohl noch basteln z.B. beim automatischen Mounten von USB Sticks mit normalen Userrechten. Das muss ich bisher noch auf der Konsole als root erledigen.

Arrgh! Diese Anleitung ist für die Tonne

…oder wie ich versuchte einen Mac in eine Windows Domäne mit Active Directory zu integrieren. Da ich von Macs herzlich wenig Ahnung habe, brauchte ich erst einmal eine Anleitung, wie ich eben den Rechner in eine Windows Domäne bringe.

Vor allem konnte ich mit dem Punkt “Active Directory-Gesamtstruktur” nichts anfangen. Ich saß da und zerbrach mir den Kopf darüber, was ich da reinschreiben sollte in dieses Feld.

Dann stieß ich auf eine Anleitung, von der ich mir erhoffte, dass sie mir weiter hilft. Doch als ich anfing folgenden Abschnitt (rot markiert) durchzulesen, verstand ich so gut wie gar nichts mehr.

macanleitung

Ich saß da und sagte: “Toll, wie schön das ich nichts davon verstanden habe!”

Auf solche Anleitungen kann man getrost verzichten, da man damit nicht wirklich weiter kommt.

USB Stick mount-Probleme 2

Ich hatte einmal in einem vorangegangenen Artikel “USB Stick mount-Probleme” das Problem mit einem nicht einhängbaren (sofern man nicht als root agiert) USB Stick geschildert.

Jetzt bin ich auf die Ursache des Problems gestoßen: ich habe irgendwann im Laufe des Tages den Stick an einem Mac-Rechner stecken gehabt und Dateien darauf abgelegt. Da ich heute zum dritten Male an einem solchen Apfel-Computer (in einem Tweet hab ich die Kisten mal als unixähnliches Nicht-Linux bezeichnet) sitzen durfte, ist mir das dann direkt aufgefallen. Wahrscheinlich setzt der Mac andere Berechtigungen für den USB Stick, so dass ihn nur der root einbinden kann.

Ich habe dazu zunächst vom Mac angelegte Dateien (.Trash/ und eine Datei mit dem Namen .DS_Storage) gelöscht, Stick rausgezogen und erneut angesteckt. Kam jedoch wieder diese Fehlermeldung. Erst ein Neustart mit eingestecktem Stick brachte da Abhilfe.