Buildumgebung: freetz-linux

[ignisquivir]

Hallo Stille Träne,

ich habe gerade Dein freetz-linux von Quellenschmiede kopiert und versucht den VMWare-Player damit zu füttern. Leider Fehlanzeige.

The import failed because C:\Users\ignisquivir\Downloads\freetz-linux-1.2.1.ova did not pass OVF specification conformance or virtual hardware compliance checks.

Click Retry to relax OVF specification and virtual hardware compliance checks and try the import again, or click Cancel to cancel the import. If you retry the import, you might not be able to use the virtual machine in VMware Player.

Auf Weitermachen mit Retry erklärt er

Failed to open virtual machine: Unknown error, please try again. If the problem persists, please contact VMware Technical Support and provide C:\Users\ignisquivir\AppData\Local\Temp\vmware-ignisquivir\ovftool.log.

Was ist zu tun ? (VMWare Player 4.0.1 build-528992)

Im "normalen" Linux (openSUSE 11.4) läuft Freetz 1.4 vom SVN auch nicht, da gibt es

Makefile:421: *** mixed implicit and normal rules. Stop.

Schade eigentlich.

 

[SaschaBr]

Das Image ist für VirtualBox optimiert. Probier es mal damit.

 

[ignisquivir]

Da rührt sich was, Danke!

 

[ignisquivir]

Basierend ist das VMWare-Image auf Ubuntu 9.10 in der Server-Version mit einem Update-Stand vom 01.02.2010
Alternativ zum bunten X sind für die Erreichbarkeit natürlich ein ssh-Server vorhanden (zu erreichen mit einem SSH-Client, unter Windows z.B. Putty), dazu ein FTP-Server und der allseits beliebte Samba-Server ist auch mit an Board, damit ihr den "Rechner" in der Netzwerkumgebung finden könnt.

Vorraussetzungen:
- Ein Rechner, der 512MB (1GB) RAM über hat für die virtuelle Maschine und genügend Leistung, um das Ganze laufen zu lassen und ausreichend Plattenplatz
- aktueller, lauffähigen VMWare-Player (alternativ Server oder Workstation), Network bridged.
(- aktuelle, lauffähige Version von VirtualBox), Network bridged.

Hier dürfte etwas klarer ausgesagt werden on nun VMWare Player oder Virtual Box, spart manchem viel Zeit!

 

[SaschaBr]

Als das freetz-linux entstand, wurde hier noch vorwiegend der VMWare-Player genutzt. Während der Weiterentwicklung bzw. Aktualisierung von freetz-linux wurde dann irgendwann auf VirtualBox umgeschwenkt. Hier im Forum gab es auch mal eine Umfrage, ob VirtualBox oder VMWare.

P.S.: Zwei Posts so kurz hintereinander sind hier im Forum nicht gerne gesehen. Also bitte die Beiträge zusammenfassen.

 

[molfi]

vielleicht gehts ja so (nicht getestet mit Player 4)
http://freetz.org/wiki/FAQ#WiebekommeichFreetzLinuxunterVMWarezumLaufen

 

[Silent-Tears]

Ich habe erklärt, dass und wieso ich _ausschliesslich_ eine VBox-Version released habe. Ich denke, das muss reichen.

 

[Jpascher]

Außerdem gibt es ja alternativen wie:
NEU Ubuntu 10.04 LTS Abbild 648MB aufbereitet für VMwarePlayer und VirtualBox

Und für für alle die 32 Bit Windowsversionen verwenden ist coLinux immer noch eine gute und sehr schnelle Lösung, das übrigens dank user Kniegaex nun auch Ubuntu 10.04 oder 12.04 .

LG Johann

 

[gismotro]

Habt ihr dort auch den Button für direktes starten von Freetz implementiert ?

Ich meine das wurde mal mit Ernest015 diskutiert. Eine VM für beides ......

 

[Jpascher]

Ernest015 sollte dazu selber Stellung nehmen.
An sich gibt es den Link am Desktop zum Starten von freetz, und Anpassungen sind auch erfolgt.

 

[gismotro]

Danke, hab es schon lange nicht mehr benutzt. Bis dato läuft Freetz-Linux (in VirtualBox) sehr stabil wenn man es nach Wiki betreibt.

 

[Jpascher]

Von dem bin ich auch überzeugt!
Die Downloadstatistik zeigt auch, dass derzeit die freetz-linux VMWare Version
mit 724 Downloads pro Woche am häufigsten heruntergeladen wird (502MB)
http://sourceforge.net/projects/freetz-linux/files/stats/timeline

Gefolgt von der GUI Version die Ernest05 bereitstellt mit 343 Downlaos pro Woche (680 MB)
http://sourceforge.net/projects/ubuntu-910-vm/files/stats/timeline

Schlusslicht ist mein speedlinux mit 215 Downloads pro Woche. (95 MB oder mit GUI 360 MB)
http://sourceforge.net/projects/speedlinux/files/stats/timeline
-------------------------------------------------------------------------------------------

Es geht hier sowieso nicht um die Frage was sicher funktioniert.
Ubuntu läuft sicher in allen Varianten für unserer Bedürfnisses sehr stabil, wenn die Hardware mitspielt.
Es gibt leider bestimmte Hardware die die ein oder andere Konfiguration nicht ermöglicht.
VMWare und coLinux läuft zum Beispiel auf einen DELL inspiron 1721 und Windows Vista 32 Bit mit allen Updates problemlos,
hingegen kann man diese Hardware auch mit Bios update nicht dazu bewegen sich mit VirtualBox anzufragenden.

 

[Silent-Tears]

Egal, wer wie was wo vertreibt Leute, hier geht es um was? Bitte schiebt diese Diskussion in die Foren und Theras, wo es hingehört, danke.

 

[Accuvue]

Papierkorb leeren

Bitte zerreist mich nicht gleich wieder in der Luft, nur weil mir Einiges an Linux-Know-How fehlt...

Ich habe einige Zeit mit der Build-Umgebung von Silent Tears rumexperimentiert. Dadurch sind die .vdmk-Files sehr groß geworden (2 und 9 GB). Ich denke, da hat sich viel Müll angesammelt...

Ich habe mich in den Weiten der Wikipedias belesen und weiß, das

sudo rm -rf ~/.local/share/Trash

hier nicht die Lösung ist, den Papierkorb zu entsorgen.

Verratet mir bitte wie es funktioniert...

 

[sf3978]

Ich habe mich in den Weiten der Wikipedias belesen und weiß, das

sudo rm -rf ~/.local/share/[COLOR=red]Trash[/COLOR]

hier nicht die Lösung ist, den Papierkorb zu entsorgen.

Gibt es bei dir, im Verzeichnis "Trash" auch das Unterverzeichnis "files"?

 

[Silent-Tears]

Das wird so nichts bringen. Die Files sind zwar dynamisch _wachsend_, aber sie reduzieren ihre große nicht wieder. Impliziert,dass du entweder neue virtuelle Platten anlegst in einer bestimmten Größe, die Daten rüberkopierst und dann auch entsprechende Mountoptionen änderst, du eine neue Version lädst und dort von vorn beginnst, oder du es einfach dabei belässt.

 

[sf3978]

... die Lösung ist, den Papierkorb zu entsorgen.

In den Weiten des Internets findet man u. a. auch folgende Lösungen, den Inhalt des richtig konfigurierten(trash-cli) Papierkorbes, mit Hilfe der (d. h. über die) Konsole zu löschen:

shred -fuv ~/.local/share/Trash/files/*

oder

rm -rf ~/.local/share/Trash/files/*
rm -rf ~/.local/share/Trash/info/*

Ob diese Vorgehensweisen bei deinem Linux verwendet werden dürfen/können, weiß ich nicht. Bitte nur anwenden, wenn zulässig bzw. wenn Du weißt was Du tust.

 

[Jpascher]

Nur als Anmerkung ich entferne bei meinen Ubuntu wesntlich radikaler Teile die unnötigen Speicherplatz belegen.
Bitte nur ausprobieren, wenn vorher eine Sicheung erstellt wurde.
Ob damit alles entfernt wird was man entfernen kann bezweifle ich, aber das ist halt mein momentaner Wissensstand.
Weitere Anregungen und Verbesserungen sind erwünscht!
(Das schrumpfen des Images ist damit aber nicht erledigt.)

#!/bin/bash
echo "- Clean"
rm -vrf /home/*/.cache/*
rm -vrf /home/*/.local/share/Trash/files/*
rm -vrf /home/*/.local/share/Trash/info/*
rm -vrf /root/.cache/*
rm -vrf /root/.local/share/Trash/files/*
rm -vrf /root/.local/share/Trash/info/*
DIRS="$(ls -d */ | grep -v 'mnt')"
#echo "Directorys: $DIRS"
find $DIRS -name \*.log -type f -print
echo "---------------------"
DIRI="$(find $DIRS -name \*.log -type f -print)"
for FILE in $DIRI; do
echo "" > $FILE
echo "${FILE}"
done
echo "---------------------"
DIRI="$(find /home /root \( -name \*history\* -o -name \*messages\* \) -type f -print)"
for FILE in $DIRI; do
echo "" > $FILE
echo "${FILE}"
done
echo "---------------------"
DIRI="$(ls /var/log/ )"
for FILE in $DIRI; do
[ -f /var/log/$FILE ] && echo "" > /var/log/$FILE && echo "${FILE}"
done
echo "---------------------"
rm -vf /var/log/*.gz.*
rm -vf /*.log
rm -vf /var/run/*.pid
rm -vf /var/log/wtmp
rm -vfr /tmp/*
rm -vf /src/var/state/apt/lists/ayo.freshrpms.*
rm -vf /src/var/cache/apt/*.bin
rm -vf /var/cache/apt/archives/*.deb
mkdir -p /var/cache/apt/archives/partial
sudo apt-get autoremove -y
sudo apt-get autoclean -y
sudo apt-get clean -y
echo "zero space - be patient ..."
dd if=/dev/zero of=file.z
rm -v file.z

 

[Silent-Tears]

Und was sollen die ganzen unglaublich interessanten Tipps, wenn man damit die Größe der vhd-Files nicht ändert wie ich sagte? Ja, so wird Platz _im_ Image freigegeben, aber die Imagegröße ändert sich, wie gesagt, nicht.
Aber hei, klar löscht man mal ".Trahs"-Ordner, die ja ausschliesslich ein KDE/Gnome/X-Whatever anlegt. Macht sich toll auf einem System, dass die nicht hat...
@jpascher: Weso zum Geier legst du ein File bis zur Maximalgröße der virtuellen Platte an, was du danach löschst, bzw. was nicht gelöscht wird, weil das "dd" mit einem Error abbricht und das Script vorzeitig beendet? Und wozu eine virtuelle Festplatte "Nullen"? Ist sicher irgendwo rauskopiert das Ganze, oder?

 

[Jpascher]

Weso zum Geier legst du ein File bis zur Maximalgröße der virtuellen Platte an, was du danach löschst, bzw. was nicht gelöscht wird, weil das "dd" mit einem Error abbricht und das Script vorzeitig beendet? Und wozu eine virtuelle Festplatte "Nullen"? Ist sicher irgendwo rauskopiert das Ganze, oder?

Probiere es aus, und glaube es mir das braucht man wenn man wirklich Platz einsparen will. Es ist nicht offensichtlich aber erklärbar. Die Idee stammt auch nicht von mir und kann im ubuntuwiki nachgelesen werden. Bei mir bricht das auch nicht ab, wenn dd mit Fehler endet, aber das ist ja eigentlich Nebensache da das Skript auch nicht als "perfekt" zu betrachten ist. Ansonsten hast du Recht, dass das Image damit noch nicht geschrumpft ist, dazu bracht es noch mehr, aber das hab ich ja erwähnt. Urheber dieser geposten Zeilen bin natürlich ich auch wenn die Zeile "dd if=/dev/zero of=file.z" so ähnlich in einigen wikis zu finden ist, aber so wichtig ist das wieder auch nicht, wenn es das Skript in dieser Form zum Herunterladen gäbe hätte ich den Link gepostet.