7150/Si W500V mit Firmware der 7170 kombinieren

[hedak]

[Posting 1]

@Wotan: Danke für deine schnelle Antwort

Wir haben bzw. Johann hat die Modifizierung (Sinus W500V) im Skript eingestellt.

Kannst du das bitte präzisieren? Oder soll ich Johann deswegen eine PM schicken?

Mit der FRITZ!Fon FW 04.71 läuft die W500V einfach TOP!!!

Wenn das so wäre, würde ich die 4.87 auf dem 500V nicht benötigen. Ich versuche seit Tagen das Mobilteil zu koppeln. Habe auch noch diesen Thread gefunden, aber das brachte auch nix. Es klappt nur mit der TCOM-FW. Kannst du mir vllt deine FW schicken und mir sagen, wann ich wie das Koppeln bewältigen kann?

[....]

Ich möchte mir (noch) keine andere Hardware kaufen, da bei euch das Koppeln ja auch klappt/ihr die 4.87 auf dem Sinus zum Laufen bekommen habt

Habe jetzt die serielle Konsole dran (hat mich den ganzen gestrigen Nachmittag gekostet, Grund: Das Kabel vom Wandler zum Sinus war zu lang und hat sich Störsignale eingefangen... Bis ich das raus hatte...) Falls bei der Lösung meines Problems die serielle Ausgabe hilft, poste ich sie hier.

[Posting 2]

Vllt mach ich ja was falsch beim Koppeln.
Im Moment steht im MT-Display "Bitte anmelden".

Nun sehe ich drei Möglichkeiten (alle ohne Erfolg):

A) MT in Basis zum Laden stecken -> MT beginnt automatisch und ohne Pin-Abfrage mit dem Koppeln und fordert mich auf die Paging-Taste zu drücken. Das tue ich bis die Anzeige der Basis zu blinken beginnt (nach etwa 10 Sekunden)

B) im WEB-IF unter "Erweiterte Einstellungen->Telefonie->Telefoniegeräte->Neues Gerät einrichten", dabei muss ich eine Festnetznummer angeben usw. Dann folge ich den Anweisungen:

"Gehen Sie wie folgt vor:
1. Starten Sie auf dem Schnurlostelefon, das Sie anmelden möchten, den Anmeldevorgang.
Sie werden aufgefordert, die PIN der integrierten DECT-Basisstation (bei Auslieferung: 0000) einzugeben. Wie die Schritte im Einzelnen aussehen, hängt von Ihrem Schnurlostelefon ab. Die Beschreibung dazu finden Sie in der Dokumentation des Schnurlostelefons.
2. Wenn das Schnurlostelefon beginnt sich anzumelden, klicken Sie hier auf "Verbinden".
Die Anmeldung wird jetzt automatisch durchgeführt, es sind keine weiteren Schritte notwendig."

C) im WEB-IF unter "Erweiterte Einstellungen->Telefonie->DECT-Handteile->[Tab]Anmelden->Schnurlostelefone anmelden", es erscheint ein Pop-Up, was mich dazu auffordert das Koppeln am MT zu starten, bevor ich das Pop-UP schließe. Nach dem Schließen des Pop-Ups blinkt die Anzeige der Basis.

Ich habe die drei Schritte jeweils in dieser Reihenfolge abgearbeitet, jedoch unter Fritz/Freetz ohne Erfolg. Am Telefon wähle ich folgende Koppel-Einstellungen: "Basis 1", PIN: 0000 (von mir nicht geändert), MT auswählen: "Automatisch". Vorher mache ich einen Werksreset über das WEB-IF. Versucht habe ich das alles unter 4.32 und 4.71.

Please help!

 

[Wotan-Box]

Dann schreibt doch mal was Du für eine FW-Kombi benutzt, und nicht nur 4.71 oder 4.32 da kann ich nichts mit anfangen.

 

[hedak]

Da ich ja gerade am Versuch des Koppelns bin, habe ich folgende zwei FW getestet:

fw_C_Sinus_500_27.04.27-_Fritz_Box_2MB_38.04.32-_sp2fr-1399-774_OEM_avm_annexB_de.image (also Sinus W500V als Hardware Type und AVM 7150 38.04.32 als AVM firmware for web-interface and features)
und
fw_C_Sinus_500_27.04.27-_Fritz_Box_7150_38.04.71-14616_sp2fr-1399-774_OEM_avm_annexB_de.image (also Sinus W500V als Hardware Type und AVM 7150 38.04.71 als AVM firmware for web-interface and features)

Ich habe bei Speed-to-fritz nur diese Einstellungen geändert. Alles andere ist auf default.
Ich hoffe, das sind die Infos, die du brauchtest

 

[Wotan-Box]

Benutze mal die Rev. 1150 bzw. 1200, bin in Urlaub und kann nicht nachsehen.
Also mit Rev. 1200 auschecken.

 

[hedak]

Danke, dass du dich dennoch um mich kümmerst

Ich habe sowohl Revision 1150 als auch 1200 ausgecheckt und damit "fw_C_Sinus_500_27.04.27-_Fritz_Box_DECT_W500V_38.04.71-14616-sp2fr-10.10.27-1036_OEM-avm_annexB_de" und "fw_C_Sinus_500_27.04.27-_Fritz_Box_DECT_W500V_38.04.71-14616-sp2fr-11.02.13-r-1200M-1031_OEM-avm_annexB_de" erstellt.

Die FWs funktionierten zwar, doch konnte ich wieder das MT nicht anmelden. Beim mit Rev. 1150 erstellten Image stand sogar noch der Eintrag "USB-Geräte" unter den erweiterten Einstellungen

Edit:
WLAN habe ich zu Testzwecken nun deaktiviert, ohne Erfolg. Weiterhin habe ich die original TCOM-FW draufgezogen, das MT ließ sich problemlos anmelden. Ich habe dann das MT suaber abgemeldet und die modifizierten FWs noch einmal probiert, ohne Erfolg.

Lösung:
Ich habe diesen Thread gefunden. Daraufhin habe ich Revision 748 ausgecheckt und siehe da... Es koppelt sich.
@Wotan: Hast du spontan eine Idee, (ob) was an den Revisionen am DECT geändert wurde? Ich recherchier orgen mal etwas

 

[Wotan-Box]

Nein, das müsste Johann wissen.
Aber es ist doch jetzt alles i.o. oder???, ob nun mit Rev. 778 o. 11339 ist doch egal.
Hauptsache ist doch das die FW-Kombi 27.04.27/38.04.71 läuft.

 

[hedak]

Kombi 7170/W500V möglich und brauchbar

Soo, ich melde mich wieder zurück.

Nachdem ihr ja das Thema Kombi 7170/W500V als unbrauchbar abgetan habt, habe ich mich ausgiebig damit beschäftigt, Erfolgreich!

Was ich nun habe: Einen SINUS W500V mit FW 29.04.87 der 7170 Fritzbox samt Freetz und funktionierendem DECT. Weiterhin laufen nun die Ipsec-Tools!

Eine Frage an die Experten vorweg: Warum ist die Tool-Reihenfolge Freetz --> Speed-to-Fritz Standard? Ich beschreibe unten kurz, dass ich durch Umkehren der Reihenfolge erheblich mehr Speicher zum Freetzen zur Verfügung hatte.

Ich habe unglaublich viel Zeit damit verschwendet die DECT-Kopplung hinzubekommen bzw. dass die Kopplung nicht durch Neustart/Stromausfall verloren geht Letztendlich hat mir Wotan den Tipp gegeben, eine andere Speed-to-Fritz (SP2FR) Revision zu verwenden. Danke Dafür! Erfolgreich war ich in der Revision 1336.

Auch das Nutzen meines Xperia Neo Smartphones (Android) als Telefon für die Fritzbox funktionierte Doch wollte ich ja die Ipsec-Tools reinbekommen. Also vorher mit Freetz die 7170 FW modifiziert. Freetz-Devel-Version ist 1.1.4 (7570M aus der Datei .lastbuild-version). Dabei musste ich feststellen, dass für das Freetzen mit Ipsec-Tools kein Platz war (Kernel image is 105216 bytes too big) und beim nur Freetzen mit anschließendem SP2FR das DECT nicht mehr funktionierte

Aufgefallen ist mir jedoch, das SP2FR mit entsprechenden Patches die 7170 FW um ca. 200kB verkleinert. Deshalb habe ich die Tool-Reihenfolge geändert, sodass ich mehr Spielraum hatte:

Zunächst die Original 7170 FW mit SP2FR zu W500V gewandelt (wobei dank der Patches alles Unnötige, wie Kids-Menu, rausgenommen wurde). Anschließend habe ich das erzeugte Image gefreetzt. Dazu mussten jedoch einige Freetz-Patches und weitere Änderungen vorgenommen werden. Im Endeffekt hatte ich beim nur-Freetzen mehr als 4 Minuten AB (entspricht glaube ich knapp 800kB). Mit den Ipsec-Tools (benötigen etwa 10 Libs), WOL, AVM-Firewall und netcat hab eich nun immernoch 50kB frei.

DECT hatte zwischendurch immerwieder Probleme gemacht. Auffällig war, dass OFT, wenn die Imagegröße der Grenze nahe kam, das DECT funktionierte. Bei kleinen Images machte es Probleme. Ich habe mal zwei Logs der seriellen Konsole zum Vergleich angehangen (einmal geht DECT, einmal nicht). Dabei fällt auf, dass beim funktionierenden Image mtd6 nicht gemounted werden konnte. Außerdem fiel beim Vergleich der Prozesse auf, dass beim funktionierenden DECT-Image der Prozess "317 root 0 SWN [jffs2_gcd_mtd6]" nicht lief! Experten: kann es daran liegen?! Dessen ungeachtet bewirkt "Replace-Kernel" anscheinend, dass DECT "besser" funktioniert. Kann ich also nur empfehlen.

Falls Jemand irgendwelche Fragen hat oder die conf(ig)-Files möchte, einfach melden

Und vielen, vielen Dank und ein riesen Lob an alle SP2FR- und Freetz-Entwickler, die das möglich gemacht haben, aber vor Allem an Jpascher!

 

[PHanToMiC]

An dieser Stelle ein Fettes Danke an hedak.
Ich war schon dran meine zwei Boxen zu verschrotten, dies werde ich jetzt nicht machen.
Ich hoffe das Dect Problem gehört nun zur Vergangenheit?

 

[Jpascher]

Ich bedanke mich auch!
Leider kann ich zu den Fragen nichts sinnvolles beitragen sonst hätte ich schon früher geantwortet.

Ich hoffe, dass du funktionierende Firmware nach bedarf denen die sich bei dir melden zukommen lässt.
Die Adaptionen werden wohl kaum in das Skript einfließen können.

 

[Ernest015]

Eine Frage an die Experten vorweg: Warum ist die Tool-Reihenfolge Freetz --> Speed-to-Fritz Standard?

Ich verstehe die Frage jetzt nicht ganz. Normalerweise wird zunächst speed-to-fritz gestartet. Die Option mit dem "start-freetz.sh" im Menü sorgt dann dafür, dass zusätzlich Freetz gestartet und die Parameter aus speed-to-fritz (Firmwareauswahl, Box-Modell, zusätzliche Optionen) in den Freetz-Trunk kopiert werden. Nach dem erfolgten Freetz-Durchlauf startet speed-to-fritz noch einmal automatisch. Freetz hat ja (da es sich nicht um eine "Alien-Variante" handelt), ein Image für eine "echte" Fritzbox erzeugt, diese muss dann wieder per speed-to-fritz mit den passenden Hardware-Treibern für das jeweilige Speedport-Modell versehen werden.

Möglicherweise kommt diese "falsche" Reihenfolge durch die Verwendung des Video-Tutorials zustande, in diesem wird leider zu Anfang gesagt, dass auf das "start-freetz.sh"-Icon geklickt werden soll.
Ich habe im VMware-Image versucht, die falsche Reihenfolge mittels kleiner Batch-Dateien abzufangen. Die Icons "download_speed-to-fritz.sh" und "start_freetz.sh" führen nicht die eigentlichen Scripte aus, sondern starten die entsprechenden Batch-Dateien. Das funktioniert aber nur dann, wenn der speed-to-fritz-Ordner noch nicht auf dem Desktop existiert oder noch nicht gestartet wurde.

mfg

 

[nobox]

Freetz hat ja (da es sich nicht um eine "Alien-Variante" handelt), ein Image für eine "echte" Fritzbox erzeugt, diese muss dann wieder per speed-to-fritz mit den passenden Hardware-Treibern für das jeweilige Speedport-Modell versehen werden.

Wenn ich den hedak richtig verstanden habe, ist es effizienter, zuerst mit sp2fr eine Firmware mit angepassten Hardwaretreibern zu bauen, und diese dann zu freetzen.

 

[Ernest015]

...zuerst mit sp2fr eine Firmware mit angepassten Hardwaretreibern zu bauen,...

Teilweise richtig. Es geht zunächst nicht um die Hardware-Treiber, sondern darum, dass bei speed-to-fritz bereits "überflüssige" Features wie Kindersicherung, USB-Unterstützung (die beispielsweise ein Speedport W701v nicht hat) o.ä. ausgebaut werden. Damit ist schon mal Platz gespart, da diese bereits verkleinerte Firmware an Freetz übergeben wird.

Freetz baut das Image dann jedoch für eine "echte" Fritzbox, damit sind in dieser Firmware die falschen Hardware-Treiber (weil keine "Alien-Variante"). Erst beim zweiten speed-to-fritz-Durchlauf, der nach Freetz automatisch startet, werden dann die passenden Treiber in die von Freetz erzeugte Firmware eingebaut.

Effektiver im Bezug auf den Platzgewinn kann es allerdings sein, die Firmware direkt (ohne speed-to-fritz) direkt von Freetz als "Alien-Variante" zu bauen. Diese Möglichkeit existiert aber nicht für alle Box-Modelle. Der Aufruf (in der VM oder im Ubuntu als Installation auf einer Platte) sähe dann so aus:

Terminal-Fenster öffnen

cd Desktop [Enter]

Nun wird die aktuelle Freetz-Version 1.1.4 mit dem folgenden Befehl heruntergeladen:

svn co http://svn.freetz.org/tags/freetz-1.1.4 freetz-1.1.4 [Enter]

Auf dem Desktop befindet sich dann ein Ordner mit der Bezeichnung freetz-1.1.4

In diesen wechseln mit:

cd freetz-1.1.4 [Enter]

und den Befehl:

make menuconfig [Enter]

eingeben. Es erscheint dann ein Menü wie dieses:


Wird nun unter " Hardware type" beispielsweise die Firmware einer Fritzbox 7170 (Fon WLAN 7170), ausgewählt, erscheint eine zusätzliche Option: Compile image for "alien" hardware


Diese Option bewirkt, dass die Firmware direkt für die nun unter "Alien hardware type" auswählbaren Speedport-Modelle W701v bzw. W900v erstellt wird.

Ich bin jetzt nicht jedes Box-Modell durchgegangen, hier muss einfach mal nachgeschaut werden, ob es die Möglichkeit gibt, die Alien-Firmware direkt zu erstellen.

Nach Auswahl der Pakete und dem Abspeichern der Konfiguration wird das Freetz durch Eingabe von:

make [Enter]

gestartet.

Um auf das eigentliche Thema des Threads (7150/Si W500V mit Firmware der 7170 kombinieren) zurückzukommen: die "Alien-Variante" für diese Box-Modelle ist nicht vorgesehen, wie schon gesagt, lassen sich mit der 7170-Firmware nur Speedport W701v und W900v auswählen. Aber vielleicht hilft dieser kleine Exkurs ja den Besitzern der entsprechenden Boxen. Und noch ein Problem: Das von Freetz gewünschte Firmware-Image FRITZ.Box_Fon_WLAN_7170.29.04.80.image existiert nicht mehr, das müsste für den reibunglosen Ablauf in Freetz geändert werden.

Ergänzung dazu: Ich habe es noch nicht ausprobiert, aber dem Ticket nach, welches ich bei Freetz wegen des nicht mehr vorhandenen 29.04.80-Images aufgemacht habe, wurde als Lösung auf eine Freetz-Vorab-Version (1.2-Previev) verwiesen. Der Aufruf zum Herunterladen sähe dann so aus:

svn co http://svn.freetz.org/branches/freetz-stable-1.2 freetz-1.2-preview [Enter]

Dann so weiter wie beschrieben, natürlich jetzt in den Ordner freetz-1.2-preview wechseln.

mfg

 

[Jpascher]

Wenn ich den hedak richtig verstanden habe, ist es effizienter, zuerst mit sp2fr eine Firmware mit angepassten Hardwaretreibern zu bauen, und diese dann zu freetzen.

Ich habe es so verstanden, dass zuerst eine Firmware mit Speed-to-fritz abgemagert und angepasst wird, diese wird dann als "Benutzerfirmware" bei freetz eingetragen und die zusätzlichen Pakette und der neue Kernel dazu gepackt.
Diese Möglichkeit ist auch im den FAQs erwähnt und wurde von mir zu Beginn auch verwendet.
Das setzt aber voraus, dass man sich mit Linux und der Skript-Programmierung gut auskennt, da Freetz in Folge relativ viel Anpassung braucht um die Fehlermeldungen zu beseitigen, da die Firmware ja nun von der normalen 7170 Firmware abweicht.'Außerdem muss eine älter Freetz revision verwendet werden um annähernd den Firmwarestand zu repesentien die pepätcht wird.

 

[hedak]

Wow hier ist ja richtig was los

Also ich habe es so gemacht, wie nobox und Jpascher es verstanden haben.
Interessant ist, was Ernest015 sagt:

Freetz baut das Image dann jedoch für eine "echte" Fritzbox, damit sind in dieser Firmware die falschen Hardware-Treiber (weil keine "Alien-Variante"). Erst beim zweiten speed-to-fritz-Durchlauf, der nach Freetz automatisch startet, werden dann die passenden Treiber in die von Freetz erzeugte Firmware eingebaut.

Denn ich habe zuerst Speed-to-Fritz und danach Freetz auf die Original-W500-FW angesetzt. Also nicht nochmal Speed-to-Fritz hinerher. Und es läuft wirklich alles. Naja... Die Ipsec-Tools musste ich wieder rausnehmen. Die Module konnten geladen werden, die Tools selber verursachten einen Segmentation error. Auch das statische Linken der Bibliotheken und das Ersetzen der AVM-SSL-Libs und der libavmhmac brachten nichts Aber egal, der AVM VPN-Server tut seinen Dienst mit meinem gerooteten (wegen der Einbindung von tun.ko für VPNC) Android nun auch.

Wie Jpascher sagt

Das setzt aber voraus, dass man sich mit Linux und der Skript-Programmierung gut auskennt, da Freetz in Folge relativ viel Anpassung braucht um die Fehlermeldungen zu beseitigen, da die Firmware ja nun von der normalen 7170 Firmware abweicht

musste ich einiges anpassen. Wichtig war es die Patches aus Patches/7170/de zu deaktivieren und den Webmenu-Patch anzupassen. Ich hatte allerdings weder viel Ahnung von Linux noch von der Shell. Doch als Fachinformatiker, der bisher nur mit Windows-Programmierung zu tun hatte, fuchst man sich da auch mit der Zeit rein Und dann hilft auch noch trial and error

Außerdem muss eine älter Freetz revision verwendet werden um annähernd den Firmwarestand zu repesentien die pepätcht wird

Ich habe die aktuelle Freetz Revision verwendet. Vllt Glück?!

Danke für euer Feedback!

 

[Jpascher]

Ich habe die aktuelle Freetz Revision verwendet. Vllt Glück?!

Wenn es geklappt hat, dann hab ich mich geirrt. ich bin auch nicht unfehlbar.

Hebe deine Firmware gut auf die wollen sicher einige haben.

 

[hedak]

War keine Anspielung von mir

Hatte bereits vier Anfragen. Und sie ist gut gesichert:

Habe im VMware Player der Fritz-Ubuntu-VM eine zweite 2GB-Festplatte verpasst und diese dann unter Ubuntu mit NTFS formatiert (oder partitioniert?!) und dorthin die fertige Umgebung kopiert (da die Standard-VM-Fetplatte bereits 15GB groß war...).

Der Clou an der Sache: Bei ausgeschalteter VM kann man in den Eigenschaften einer VM die Festplatte unter Windows als Laufwerk mappen. Man kann dann also sogar unter Windows schnell darauf zugreifen, da sie ja als NTFS formatiert ist. Klar, man kann nichts kompilieren oder ausführen, aber um mal eben eine Datei zu lesen ist es mehr als praktisch! Vllt hilft ja Jemandem der Tipp!

 

[Ernest015]

Interessant ist, was Ernest015 sagt:

Ich habe mich da wohl leider falsch ausgedrückt, auch der DSL-Treiber wird schon beim ersten speed-to-fritz-Durchlauf zusammen mit den herausgepatchten Optionen übernommen. Der zweite Start am Ende des Freetz-Durchlaufs dient dann hauptsächlich dazu, aus dem Freetz-Image ein funktionsfähiges Speedport-Image zu machen. Das beinhaltet auch ein Image, welches sich als "normales" Firmware-Update über die Weboberfläche hochladen liess (das File mit fw_C_speedport....image im Firmware.new-Ordner), diese Möglichkeit funktioniert aber nicht mehr korrekt. Vermutlich liegt es daran, dass ein Firmware-Update, welches über die Weboberfläche hochgeladen wird, zunächst in das RAM der Box geladen wird. War das erfolgreich, wird die Betriebssystempartion mtd1 gelöscht und die neue Firmware in den eigentlichen Flashspeicher übernommen. Die aktuellen Firmware-Versionen sind aber anscheinend so gross, dass sie nicht vollständig in das RAM passen (die Box braucht davon ja auch noch selber etwas für den Eigenbedarf). Es sieht also optisch so aus, als ob die Firmware hochgeladen wird, tatsächlich wird aber nichts geflasht, so dass nach einem Neustart immer noch die alte Firmware auf der Box ist.

Ein Hochladen per FTP, bei der das kernel.image direkt nach mtd1 geladen wird, umgeht das Problem, hier ist das RAM nicht mit im Spiel. Auch ein entsprechend modifiziertes Recover funktioniert auf diese Art und Weise.

mfg

 

[hedak]

Sehr interessant! Danke für die Infos.

Da ich immer über FTP geupdated habe, hatte ich das Web-Update-Problem glücklicherweise nicht - wie du schon sagtest

 

[Ernest015]

...(da die Standard-VM-Fetplatte bereits 15GB groß war...).

Ich weiss jetzt nicht, ob die Möglichkeiten bekannt sind, die die VMWare-Tools da bieten, sie müssen bei einem selbsterstellten VMWare-Image jedoch noch zusätzlich installiert werden.

In einem Terminal-Fenster den Befehl:

sudo vmware-toolbox [Enter]

eingeben. Nach der Passwort-Abfrage erscheint ein Fenster, bei dem auf der vorletzten Registerkarte (Shrink) die virtuellen Partitionen zum Verkleinern angewählt werden können. Hier nun alle vorhandenen Partitionen wählen (mit gedrückter Shift-Taste anklicken) und unten auf Shrink klicken.

Dieses Feature dient folgendem Zweck: die virtuellen Plattenpartitionen der VMWare sind in einer normalen Datei (Ubuntu_10.04_32-Bit.vmdk beim VMWare-Image von hier), die dann unter Windows im entsprechenden Ordner abgelegt wird. Im Laufe der Zeit wird diese immer grösser, da einmal genutzter Platz in der Datei nicht automatisch wieder freigegeben wird. Diese Freigabe erledigt das "Shrink", es können so durchaus mehrere GByte gewonnen werden.

Zu beachten wäre nur, dass der freie Plattenplatz unter Windows mindestens so gross ist, wie das Image, das verkleinert werden soll. Ist die Platte wie im Beitrag also 15 GB gross geworden, sollten unter Windows auch noch 15 GB Platz zur Verfügung stehen.

Und noch ein Hinweis: es ist oft von Vorteil, sich den kompletten Ubuntu-Ordner vorher zu sichern, also evtl. auf eine andere Windows-Partition kopieren. Wenn die Operation mit dem Shrink aus irgendwelchen Gründen fehlschlagen sollte, wäre es ein Riesenaufwand, daraus wieder etwas funktionsfähiges zu machen (wenn überhaupt möglich).

Wer auch noch das letzte an freiem Platz gewinnen möchte, kann (muss nicht) die Befehle:

sudo apt-get autoremove [Enter]

und

sudo apt-get clean [Enter]

vor dem Aufruf der VMWare-Tools eingeben. Der erste Befehl bewirkt das Löschen veralteter Pakete (z.B. alte Kernel-Versionen), der zweite das Löschen des Caches, in dem die zur Neuinstallation vorgesehenen Pakete zwischengespeichert werden.

mfg

 

[hedak]

So viele gute Infos heute, Danke

Ich hatte unter den Festplatten-Eigenschaften im VMware-Player das Komprimieren versucht, hatte damit jedoch keinen Erfolg. Ich werde die Befehle morgen mal testen und Feedback geben.

PS: Aber ich bin etwas enttäuscht, dass weder Ubuntu noch die VMware-Tools den in der VM freigegebenen Speicher in der vmdk freigeben... Warum schreibt Ubuntu nicht in wiederfreigegebene Bereiche seiner (virtuellen) Festplatte?! Ich weiß allerdings nicht, ob Windows das tut...