Problem bei der Zusammenführung von vmdk Containern

[Mr. T]

Hallo,

ich bin unerfahren um Umgang mit VMWare Workstation und bitte um Rat bzgl. des folgenden Problems.

Vor einiger Zeit habe ich mir eine Ubuntu Server Installation eingerichtet. Gestern wollte ich ein paar Updates einspielen und bekam gemeldet, dass nicht genug Platz zur Verfügung stehe. Meine VM ist jedoch mit 20 GB eingerichtet. Eine Prüfung mittels gparted zeigt, dass die Boot-Partition fast voll ist. Allerdings ist es unmöglich mit gparted die große Partition zu skalieren. In der Partitionsübersicht ist diese auch mit einem Schloss markiert.

Mein Verdacht ist nun, dass es daran liegt, dass ich 3 vmdk Container habe - *.vmdk, *0001.vmdk und *0002.vmdk. Letzterer ist in der *.vmx als aktiv markiert. Vor einiger Zeit hatte ich sämtliche Snapshots gelöscht und war davon ausgegangen, dass VMWare alles damit zusammenhängende automatisch selbständig auflöst. Wie mir scheint, ist dem nicht so. Ich habe also im Snapshot-Manager keine Snapshots mehr stehen, aber 3 *.vmdk Container.

Gestern hatte ich mit dem Kommando,

Code: Alles auswählen

vmware-vdiskmanager -r "Ubuntu Server.vmdk" -t 0 "H:\Ubuntu Server merged.vmdk"

erstellt. Dieser Prozess verlief fehlerfrei. Anschließend habe ich die *.nvram, *.vmsd, *.vmx und *.vmxf Dateien zur neu erstellten Platte kopiert und in der *.vmx Datei die Referenz auf die neue Platte korrigiert.
Das System ließ sich booten. Allerdings konnte ich mich anschließend nicht auf dieser neuen VM anmelden und auch meine Prozesse nicht starten, was mich vermuten lässt, dass etwas nicht richtig geklappt hat. Das wiederum verbinde ich mit einer potentiell falschen Anweisung an den vdismanager.

Hier nun meine Fragen:
Ist meine Anweisung korrekt oder muss man die 3 *.vmdk Container nacheinander auflisten, damit alle gemerged werden?
Wie kann ich 100%ig sicher stellen, dass alle 3 *.vmdk Container gemerged wurden? Die Größe der Zielpartition war nicht 1:1 identisch mit der Größe einer der oder aller drei Quellpartitionen zusammen.

[JustMe]

Wenn die *0002.vmdk in der .vmx noch referenziert wurde, dann ist das ein noch aktiver Snapshot.

Von daher waere der Aufruf von

Code: Alles auswählen

vmware-vdiskmanager -r "Ubuntu Server-0002.vmdk" -t 0 "H:\Ubuntu Server merged.vmdk"

wahrscheinlich sinnvoller, um die vorhandenen Snapshots in die neue vmdk zu konsolidieren.

Eine genau Aussage, welche vmdk von der VM verwendet werden, sollte die vmware.log im Verzeichnis der VM liefern.

Falls die nochmalige Konvertierung nicht helfen sollte, kannst Du ja mal die vmware*.log und vmx-Datei, zusammen mit einer Dateiliste des VM-Verzeichnisses posten.
(Nicht als Anhang hier im Forum; dat geit nit)

[Mr. T]

So, das Mergen hat wieder geklappt. Das Booten auch. Und ich kann nun auch meine Prozesse starten.

Allerdings kann ich noch immer nicht mit gparted live CD die Partitionen ändern und habe ein Problem mit der boot partition. Hier ist eine Übersicht von gparted.

Partition | Filesys | Mountpt | Size | Used | Free | Marked
/dev/sda1 | ext2 | - | 243.00 MiB | 238.29 MiB | 4.71 MiB boot
/dev/sda2 | extended | - | 19.76 GiB
/dev/sda5 | lvm2 pv | ubuntu | 19.76 GiB | 19.74 GiB | 20.00 MiB lvm <--- ist mit einem Schloss markiert
nicht zugeteilt | 1.0 MiB

Kann mir jemand sagen, was ich übersehe und wie ich mein Dilemma lösen und der Boot-Partition mehr Platz geben kann?

[JustMe]

OK, das VMware-bezogene Problem scheint damit geloest.

Leider kenne ich mich mit Linux nicht besonders gut aus. Aber wie waere es hiermit?

Es sieht so aus, als waere die Partition gemountet, und laesst sich nicht automatisch von gparted aushaengen. Man muss versuchen, die manuell auszuketten. Ursachen dafuer kann ich selbstverstaendlich nicht angeben, sorry.

[Mr. T]

Alles klar, danke.

[Dayworker]

Du hast zwar die Snapshots eingepflegt, aber die vDISK ist immer noch 20GB groß und daher kannst du dort auch nichts vergrössern.
Unschön an deiner Partitionierung ist natürlich, daß du nur eine vDISK eingerichtest hattest und jetzt nach dem Vergrössern der vDISK erst noch die Partition "sda2" mitsamt der erweiterten LVM-Partition "sda5" verschieben mußt, damit du die Gast-HDD vergrössern kannst. Wer hat eigentlich diese Partitionierung eingerichtet? Hoffentlich nicht der Ubuntu-Installer. Falls doch wärst du besser gefahren, zum einen die Partitionierung manuell vorzunehmen und dadurch auch nutzbare Partitionsgrössen vorzufinden und zum anderen, anstatt dich mit Partitionen rumzuärgern, gleich mehrere vDISKs anzulegen.

Wenn er die VM mit dem gparted-ISO gebootet hat und ihm jetzt noch ein Schloßsymbol angezeigt wird, kann das nur zwei Dinge bdeuten. Entweder hat er den Datenträger über Ubuntu verschlüsselt, was dann vielleicht auch die kleine Boot-Partition erklären könnte oder seine gparted-Version kommt mit dem Partitionsformat bzw Dateisystem nicht klar.

[JustMe]

Hmmm, die /boot-Partition braucht doch eigentlich nicht groesser zu sein. Da kommt doch nur der grub, 1-2 Kernel, und die zugehoerigen initrd's rein...

Wenn man darueber nachdenkt, liesse sich das Problem mit der zu kleinen /boot Partition vielleicht auch dadurch beseitigen, dass die ganzen nicht mehr benotigten Kernel geloescht werden. Ich meine, Ubuntu hatte da mal ein Problem mit dem "Aufraeumen" nach dem Einspielen von Kernel-Patches.

@Mr. T:
Hast Du mal geschaut, was in der /boot so viel Platz belegt? Kann man da vielleicht was entsorgen?

[Mr. T]

@JustMe
Ich habe Angst, mir das System zu zerschießen und weiß ehrlich gesagt nicht, wo und wonach ich suchen müsste. Unten findest du zum Nachvollziehen ein Auszug von der Konsole.

@Dayworker
Ich weiß, dass die folgende Diskussion genau betrachtet offtopic ist, dennoch möchte ich dazu gern Stellung nehmen. Falls das nicht gewünscht ist und ich dazu einen neuen Thread eröffnen soll, bitte ich um einen Hinweis.

Du sprichts von einer Gast-HDD. Welche soll das sein?

Ich hatte bei der Installation von Ubuntu aufgrund meiner geringen Erfahrung im Umgang mit Linux nicht darauf geachtet, die Partitionierung mit Blick auf zukünftige Probleme zu beeinflussen. Eigentlich hatte ich auch nicht im Sinn, überhaupt irgendwelche Partitionen anzulegen, denn ich wollte alles auf einer haben. Ich bin also nahezu sicher, zumindest selbst keine Partitionen angelegt zu haben, denn ich überleg immer an diesem Punkt, soll ich die Vorgabe nutzen oder herumexperimentieren?
Ich wollte lediglich einen einfach zu nutzenden Linux-basierten Server für meine Webentwicklungsarbeit. Daher hatte ich diesem Punkt auch keine weitere Beachtung geschenkt. Lediglich den Ordner /srv hatte ich irgenwie in der Mache - weil ich dort meine Sites hoste, kann aber nicht mehr erinnern, was ich gemacht hatte. Allerdings habe ich heute im Zuge des Versuchs, die Partitionen irgendwie zu skalieren, bemerkt, dass /srv nicht gelistet war und wollte daraufhin unbedingt klären, was denn nun konkret auf sda1 und sda2 bzw. sda5 drauf ist. Folgendes hab ich alles probiert.

1. von gparted.iso gebootet und versucht, sda2, welche eine logische Partition ist, zu shrinken, um den davor frei werdenden Platz an sda1 zu hängen - ohne Erfolg
2. von pmagic.iso gebootet, damit sda2 Partition deaktiviert und den dahinter befindlichen unzugeordneten Platz angehängt. Allerdings lässt sich sda2 und auch nicht seine Partition sda5 shrinken. Danach hab ich sda2 wieder aktiviert
3. von Ubuntu CD gebootet und im "Try" Modus gparted gestartet. Anstelle des Schlosssymbols wurde mir da ein weißes Ausrufungszeichen im roten Kreis angezeigt. Der Tooltip meldetet, dass die Verwaltung von logischen Partitionen (noch) nicht unterstützt würde.
4. von Acronis Disk Director 11 Wiederherstellungsimage gebootet, aber auch das ist nicht in der Lage zu skalieren.
5. die HD der VM gemapt auf ein Windows-Laufwerk, ext2fsd installiert in der Hoffnung das Laufwerk lesen zu können, aber ext2fsd findet es nicht.

Ich hab wie gesagt, wenig Erfahrung mit Linux - und noch viel weniger in der Arbeit mit der Partitionstabelle. Ich weiß nicht mal, wie ich herausfinden kann, welche Daten auf sda5 liegen, denn ich konnte mit keinem der folgenden Versuche etwas klären:

1. ls /dev/sda2
2. ls /dev/sda5
3. mount -t ext2 /dev/sda2 /mnt
4. mount -t ext2 /dev/sda5 /mnt

Ich weiß nicht, was ich machen soll, um der boot Partition mehr Platz zu verschaffen. Ich kann keine Systemupdates mehr vornehmen, weil der Platz für den benötigten Vorgang währenddessen nicht ausreicht. Ich stecke also richtig in der Preduille.

Kann mir denn bitte jemand in Laien-Sprache erklären, was ich tun kann und wie ich vorgehen müsste?

Konsolenauszug:

Processing triggers for man-db ...
Processing triggers for ufw ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up linux-image-3.5.0-37-generic (3.5.0-37.58~precise1) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
The link /initrd.img is a dangling linkto /boot/initrd.img-3.5.0-37-generic
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
update-initramfs: Generating /boot/initrd.img-3.5.0-37-generic
gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.5.0-37-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.5.0-37-generic.postinst line 1010.
dpkg: error processing linux-image-3.5.0-37-generic (--configure):
subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of linux-image-generic-lts-quantal:
linux-image-generic-lts-quantal depends on linux-image-3.5.0-37-generic; however:
Package linux-image-3.5.0-37-generic is not configured yet.
dpkg: error processing linux-image-generic-lts-quantal (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-generic-lts-quantal:
linux-generic-lts-quantal depends on linux-image-generic-lts-quantal; however:
Package linux-image-generic-lts-quantal is not configured yet.
dpkg: error processing linux-generic-lts-quantal (--configure):
dependency problems - leaving unconfigured
Setting up libedit2 (2.11-20080614-6~precise+1) ...
No apport report written because the error message indicates its a followup error from a previous failure.

[JustMe]

Und wieder hilft da die Suchmaschine des Vertrauens:

Einfach mal nach "ubuntu remove old kernels" suchen lassen.

Da gibt es eine Vielzahl von Treffern. Sorry, aber bei solchen eher tiefgreifenden Aufgaben, noch dazu im Linux-Umfeld, gibt es offenbar keine "Kochrezepte for Dummies"; da muss man sich etwas reinarbeiten. Ansonsten bleibt immer noch eine Neuinstallation.

Zuerst solltest Du aber schauen (mit ls -lh /boot auf der Eingabeaufforderung) ob denn die Vermutung der vielen Kernel wirklich richtig ist. Wenn da viele Dateien vmlinuz* und initrd* zu finden sind, dann ist das in der Tat die Ursache.

Um das Ubuntu zu booten, braucht man da jeweils nur 1 von; meist die neueste, bzw. die mit der hoechsten Version. Zur Sicherheit kann man noch die jeweilige Vorgaengerversion leben lassen; alle anderen koennen i.A. geloescht werden, da die restlichen installierten Pakete u.U. mit diesen Altlasten sowieso nicht mehr laufen koennen.

[Dayworker]

Wir können ruhig abdriften...
Mit Gast-HDD meine ich die vDISK von der Gastseite. VMware sieht ja nur die VMDK, wie diese nachher vom Gast-OS aufgeteilt/benutzt wird, sieht VMware nicht mehr.
Ich hab bei mir grad nochmal nachgesehen, mein Boot-Verzeichnis ist gerade mal 52MB groß. Allerdings habe ich meine Lubuntu-Inst (sprich Ubuntu mit LXDE-Desktop) bis auf SWAP komplett in eine VMDK installiert und für SWAP einfach eine weitere VMDK angelegt, damit mir diese beim Erweitern nicht wieder im Weg ist.

Hast du Ubuntu mit grafischer Oberfläche installiert oder robbst du auf der Console rum?

[Mr. T]

@Dayworker
Ich hab Unbuntu Server installiert, den ich komplett per Terminal warte. Wenn schon, denn schon! Hab ja nicht damit gerechnet, dass mal so etwas kommen würde.

Allerdings habe ich meine Lubuntu-Inst (sprich Ubuntu mit LXDE-Desktop) bis auf SWAP komplett in eine VMDK installiert und für SWAP einfach eine weitere VMDK angelegt

Also wie gesagt, ich habe während der Einrichtung der VM nicht partitioniert. Als Swap-Partition nutze ich eine FAT-Partition auf meiner echten Windows-Festplatte, welche im Ubuntu-Gast gemounted wird. Und ich könnte schwören, während der Unbutu-Installation die Standardeinstellung bzgl. der Platteninitialisierung übernommen zu haben. Aber 100%ig sicher bin ich mir nicht, denn ich hatte immer überlegt, ob und welche Aufteilung sinnvoll wäre, um Fall eines Supergaus des OS nicht meine Webserver-Dateien zu verlieren.

@JustMe

Und wieder hilft da die Suchmaschine des Vertrauens:

Du bist gut, ich mache schon den ganzen Tag nichts anderes, als zu suchen und zu probieren. Jedoch, wenn man nicht weiß, wonach man suchen soll, ist es gar nicht so einfach. Und wie gesagt, kenne ich mich sehr wenig mit diesen Linux-Systemdingen aus und käme überhaupt nicht auf die Idee "old kernels" entfernen zu wollen.

Ansonsten bleibt immer noch eine Neuinstallation.

Oh gott. Ich war froh, dass alles läuft. Welche Fehler soll ich denn im Falle dass ich mich dazu entschließe, vermeiden - bzw. was soll ich bzgl. der HD-Einrichtung anders machen?

Um das Ubuntu zu booten, braucht man da jeweils nur 1 von; meist die neueste, bzw. die mit der hoechsten Version.

Ich halte mich erstmal an 12.04, da es ein LTS release ist.

Zuerst solltest Du aber schauen (mit ls -lh /boot auf der Eingabeaufforderung) ob denn die Vermutung der vielen Kernel wirklich richtig ist. Wenn da viele Dateien vmlinuz* und initrd* zu finden sind, dann ist das in der Tat die Ursache.

Ok, hier die Rückmeldung dazu:

root@ubuntu:/boot# ls -lh
total 222M
-rw-r--r-- 1 root root 837K Jan 25 2013 abi-3.5.0-23-generic
-rw-r--r-- 1 root root 839K Feb 26 01:33 abi-3.5.0-25-generic
-rw-r--r-- 1 root root 839K Mar 11 23:41 abi-3.5.0-26-generic
-rw-r--r-- 1 root root 841K Mar 26 20:58 abi-3.5.0-27-generic
-rw-r--r-- 1 root root 841K Apr 25 00:08 abi-3.5.0-28-generic
-rw-r--r-- 1 root root 841K May 15 11:12 abi-3.5.0-30-generic
-rw-r--r-- 1 root root 841K May 17 17:52 abi-3.5.0-31-generic
-rw-r--r-- 1 root root 841K May 29 22:57 abi-3.5.0-32-generic
-rw-r--r-- 1 root root 841K Jun 7 18:53 abi-3.5.0-34-generic
-rw-r--r-- 1 root root 842K Jul 10 20:13 abi-3.5.0-37-generic
-rw-r--r-- 1 root root 151K Jan 25 2013 config-3.5.0-23-generic
-rw-r--r-- 1 root root 151K Feb 26 01:33 config-3.5.0-25-generic
-rw-r--r-- 1 root root 151K Mar 11 23:41 config-3.5.0-26-generic
-rw-r--r-- 1 root root 152K Mar 26 20:58 config-3.5.0-27-generic
-rw-r--r-- 1 root root 152K Apr 25 00:08 config-3.5.0-28-generic
-rw-r--r-- 1 root root 152K May 15 11:12 config-3.5.0-30-generic
-rw-r--r-- 1 root root 152K May 17 17:52 config-3.5.0-31-generic
-rw-r--r-- 1 root root 152K May 29 22:57 config-3.5.0-32-generic
-rw-r--r-- 1 root root 152K Jun 7 18:53 config-3.5.0-34-generic
-rw-r--r-- 1 root root 152K Jul 10 20:13 config-3.5.0-37-generic
drwxr-xr-x 3 root root 5.0K Jun 18 06:52 grub
-rw-r--r-- 1 root root 16M Mar 2 19:13 initrd.img-3.5.0-23-generic
-rw-r--r-- 1 root root 16M Mar 2 22:14 initrd.img-3.5.0-25-generic
-rw-r--r-- 1 root root 16M Apr 6 14:36 initrd.img-3.5.0-26-generic
-rw-r--r-- 1 root root 16M Apr 7 06:56 initrd.img-3.5.0-27-generic
-rw-r--r-- 1 root root 16M Apr 28 06:51 initrd.img-3.5.0-28-generic
-rw-r--r-- 1 root root 16M May 17 06:30 initrd.img-3.5.0-30-generic
-rw-r--r-- 1 root root 16M May 29 17:00 initrd.img-3.5.0-31-generic
-rw-r--r-- 1 root root 16M May 30 06:31 initrd.img-3.5.0-32-generic
-rw-r--r-- 1 root root 16M Jun 18 06:52 initrd.img-3.5.0-34-generic
drwxr-xr-x 2 root root 12K Mar 2 18:19 lost+found
-rw-r--r-- 1 root root 173K Nov 27 2011 memtest86+.bin
-rw-r--r-- 1 root root 175K Nov 27 2011 memtest86+_multiboot.bin
-rw------- 1 root root 2.4M Jan 25 2013 System.map-3.5.0-23-generic
-rw------- 1 root root 2.4M Feb 26 01:33 System.map-3.5.0-25-generic
-rw------- 1 root root 2.4M Mar 11 23:41 System.map-3.5.0-26-generic
-rw------- 1 root root 2.4M Mar 26 20:58 System.map-3.5.0-27-generic
-rw------- 1 root root 2.4M Apr 25 00:08 System.map-3.5.0-28-generic
-rw------- 1 root root 2.4M May 15 11:12 System.map-3.5.0-30-generic
-rw------- 1 root root 2.4M May 17 17:52 System.map-3.5.0-31-generic
-rw------- 1 root root 2.4M May 29 22:57 System.map-3.5.0-32-generic
-rw------- 1 root root 2.4M Jun 7 18:53 System.map-3.5.0-34-generic
-rw------- 1 root root 2.4M Jul 10 20:13 System.map-3.5.0-37-generic
-rw------- 1 root root 5.0M Jan 25 2013 vmlinuz-3.5.0-23-generic
-rw------- 1 root root 5.0M Feb 26 01:33 vmlinuz-3.5.0-25-generic
-rw------- 1 root root 5.0M Mar 11 23:41 vmlinuz-3.5.0-26-generic
-rw------- 1 root root 5.0M Mar 26 20:58 vmlinuz-3.5.0-27-generic
-rw------- 1 root root 5.0M Apr 25 00:08 vmlinuz-3.5.0-28-generic
-rw------- 1 root root 5.0M May 15 11:12 vmlinuz-3.5.0-30-generic
-rw------- 1 root root 5.0M May 17 17:52 vmlinuz-3.5.0-31-generic
-rw------- 1 root root 5.0M May 29 22:57 vmlinuz-3.5.0-32-generic
-rw------- 1 root root 5.0M Jun 7 18:53 vmlinuz-3.5.0-34-generic
-rw------- 1 root root 5.0M Jul 10 20:13 vmlinuz-3.5.0-37-generic
root@ubuntu:/boot#

Ich käme nie auf den Gedanken, dass davon etwas überflüssig wäre, denn ich halte Linux für "intelligent", weil es immer alle dependencies checkt und denke in der Folge, dass es seinen Grund hat, das Linux diese Dateien aufhebt. Falls was davon weg kann, dann was denn?

[Dayworker]

Terminal und dann nicht viel Durchblick bei Linux ist eine etwas unglückliche Kombination. Du solltest da schnell mal nachsteuern und dich einlesen.
Meine wöchentlich Ubuntu-Orgie läßt folgendes durchlaufen:

Code: Alles auswählen

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get autoremove
sudo apt-get clean

"update" holt die neuesten Updates vom Server, "upgrade" installiert diese ohne Kernelveränderungen, "dist-upgrade" installiert genau diese, "autoremove" beseitigt alle unnötigen Kerneleinträge & SW-Pakete und "clean" räumt das Verzeichnis mit den jetzt installierten Updates auf.

Ich würde dir daher erstmal empfehlen, folgendes durchlaufen zu lassen:

Code: Alles auswählen

sudo apt-get autoremove

Damit wirst du alle alten Pakete und Kerneleinträge los und solltest wieder etwas mehr Platz haben.

[JustMe]

Du bist gut, ich mache schon den ganzen Tag nichts anderes, als zu suchen und zu probieren.

Das ist leider das gruendsaetzliche Problem: Es handelt sich um Suchmaschinen, und nicht um Findemaschinen.

Aber ich habe die (hoffentlich) hilfreichen Suchbegriffe doch erwaehnt.

Ich denke mal, dass ALLE Kernel, die Du in /boot findest, zu 12.04 gehoeren. Das Problem mit Linux (und Ubuntu wohl im besonderen) ist, dass da anscheinend mit jedem Patch so 1-2x pro Woche eine neuer zusaetzlicher Kernel gebaut wird. Oder ist das vielleicht ein Linux, das vor Urzeiten mal als 7.04 (oder so) installiert wurde, und ohne Aufraeumarbeiten dann immer nur aktualisiert wurde?

PS:
Du darfst AUF KEINEN FALL einfach alle vmlinuz* und initrd* loeschen!
Nur die "alten" duerfen weg. Ggfs. muss auch noch die /boot/grub/menu.lst angepasst werden. Das sollten aber die Links bei Tante G**gle deutlicher ausfuehren.

Ansonsten:
Keine Angst vor der Einarbeitung in diese Themen. Mit der Muttermilch hat das keiner eingesogen; da mussten alle durch. Es braucht halt alles seine Zeit. Und mit einer VM hast Du, genuegend Plattenplatz vorausgesetzt, ja alle Moeglichkeiten, auch mal einen Fehler wieder rueckgaengig zu machen.

[Dayworker]

Code: Alles auswählen

root@ubuntu:/boot# ls -lh

Irgendwas ist bei dir komisch. Warum bist du im Terminal als "root" eingeloggt?
"root" ist bei Ubuntu normalerweise deaktiviert und man nutzt "sudo" als Ersatz.

[Mr. T]

Irgendwas ist bei dir komisch. Warum bist du im Terminal als "root" eingeloggt?
"root" ist bei Ubuntu normalerweise deaktiviert und man nutzt "sudo" als Ersatz.

Weil ich mich zum root mache, wenn ich Operationen mit Adminrechten durchführe.

Terminal und dann nicht viel Durchblick bei Linux ist eine etwas unglückliche Kombination. Du solltest da schnell mal nachsteuern und dich einlesen.

Hehe ... nein, so dramatisch ist es nicht. Ich habe ja bewusst die Terminalvariante gewählt, um es zu lernen und arbeite schon gut ein Jahr so. Ich weiß, wie man eine Webdev-Umgebung einrichtet, den SSH-Server absichert, einen Mailserver einrichtet und das System verwaltet. Nur solche tiefgreifenden Sachen wie Kernel und Partitionierung oder Löschen überflüssiger Systemdateien sind mir total neu, weil das nicht mein daily business ist. Die von dir aufgezählten Kommandos habe ich auch auf dem weekly schedule - es gibt sogar bash_aliase dafür.

Allerdings trat der oben gelistete Konsoleoutput auf apt-get autoclean und apt-get autoremove auf. Zuvor hatte ich versucht, den ntpd zu installieren, weil meine Gast-Systemuhr immerzu so weit von der Host-Systemuhr abdriftet trotz konfigurierter Synchronisation damit. Und dabei kamen dann die Fehlermeldungen. Ich hab es jetzt dennoch nochmal aufgerufen und den kompletten output geloggt. Hier ist, was auf der Shell angezeigt wurde:

root@ubuntu:/boot# clear && apt-get autoremove>/tmp/autoremove.log
No apport report written because the error message indicates its a followup error from a previous failure.
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@ubuntu:/boot#

Und hier ist, was mitgeloggt wurde:

Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-3.5.0-37-generic (3.5.0-37.58~precise1) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
The link /initrd.img is a dangling linkto /boot/initrd.img-3.5.0-37-generic
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
update-initramfs: Generating /boot/initrd.img-3.5.0-37-generic
gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.5.0-37-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.5.0-37-generic.postinst line 1010.
dpkg: error processing linux-image-3.5.0-37-generic (--configure):
subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of linux-image-generic-lts-quantal:
linux-image-generic-lts-quantal depends on linux-image-3.5.0-37-generic; however:
Package linux-image-3.5.0-37-generic is not configured yet.
dpkg: error processing linux-image-generic-lts-quantal (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-generic-lts-quantal:
linux-generic-lts-quantal depends on linux-image-generic-lts-quantal; however:
Package linux-image-generic-lts-quantal is not configured yet.
dpkg: error processing linux-generic-lts-quantal (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-image-3.5.0-37-generic
linux-image-generic-lts-quantal
linux-generic-lts-quantal

Ich kann folglich nichts autoremoven weil der Platz dazu fehlt.

Wäre es denn safe, alle Dateien mit releasenumber < 3.5.0-34 manuell zu entfernen?

ist das vielleicht ein Linux, das vor Urzeiten mal als 7.04 (oder so) installiert wurde, und ohne Aufraeumarbeiten dann immer nur aktualisiert wurde?

Nein, das ist eine saubere Installation eines 12.04 Server releases.

[JustMe]

Wie Du siehst, kennt sich Dayworker sicher besser mit Linux aus als ich.

Aber ich denke, Du kannst erst einmal alles, was *3.5.0-2* heisst, in /boot loeschen. Danach sollten die apt-get Kommandos wieder gehen.

[Dayworker]

Teminalvariante hin oder her, sowohl der Root-Account als auch deine Webdaten-Ablage unter "/srv" anstatt das Ubuntu-Normal "/var/www/" sind für mich schon merkwürdig. Um am System zu arbeiten, reicht "sudo" aus und ein aktivierter Root-Account ist ein Sicherheitsproblem. Dein aktiver Root-Account und /srv klingt nach früherem OpenSUSE-Nutzer...

Das dir nichts mehr angezeigt wird bzw mit Fehlermeldung endet, liegt am geringen freien Platz. Du hast dich also jetzt in eine Lage gebracht, wo du weder vor noch zurück kannst.
Da müßte ich mir entweder erstmal was überlegen oder selber nachlesen...

Einfach so löschen, würde ich aber nichts. Ansonsten mußt du das sicher nachher alles von Hand machen, wo doch alles auch automatisiert ablaufen kann.





[add]
Lass mal bitte folgendes durchlaufen:

Code: Alles auswählen

sudo apt-get remove --purge linux-image-3.5.0-23-generic
sudo apt-get remove --purge linux-image-3.5.0-25-generic
sudo apt-get remove --purge linux-image-3.5.0-26-generic
sudo apt-get remove --purge linux-image-3.5.0-27-generic
sudo apt-get remove --purge linux-image-3.5.0-28-generic
sudo apt-get remove --purge linux-image-3.5.0-30-generic
sudo apt-get remove --purge linux-image-3.5.0-31-generic
sudo apt-get remove --purge linux-image-3.5.0-32-generic
sudo apt-get remove --purge linux-image-3.5.0-34-generic

[Mr. T]

Teminalvariante hin oder her, sowohl der Root-Account als auch deine Webdaten-Ablage unter "/srv" anstatt das Ubuntu-Normal "/var/www/" sind für mich schon merkwürdig. Aktiver Root-Account und /srv klingt eher nach früherem OpenSUSE-Nutzer...

Nop, kein Suse-Nutzer. Ich habe den root-Account und nutze ihn nur für Admin-Rechte-erfordernde Aktionen. Allerdings kann sich root nicht einloggen. Überhaupt kann sich kein User einloggen sondern nur per SSH mit key authen. Soweit hab ich das System schon abgesichert. Ich hätte natürlich auch meinen User-Account mit sudo nutzen können.

Ok, die alten Kerneldateien sind entfernt und das System nun auf 3.5.0-37 geupdated. Alles verlief fehlerfrei.

Jetzt steht also nur noch das Problem mit der Skalierung der Platte auf der Liste. Was kann ich tun, um die 20GB Platte skalierbar zu machen. Ich wollte sie gern auf 10GB shrinken.

[Dayworker]

Ich geh jetzt mal davon aus, daß mein letzter Code-Block sämtliche alten Kerneleinträge bereinigt hat.
Wenn dem so ist, laß mal noch folgendes durchlaufen, damit auch sonstiges, veralteten SW-Pakete bereinigt werden:

Code: Alles auswählen

sudo apt-get autoremove

Wie bereits gesagt, brauchst du für Adminrechte-erfordernde-Aktionen keinen Root-Account.


Kommen wir zu deinem Skalierungsproblem, unter dem ich mir jetzt nichts vorstellen kann.
Was willst du denn machen? Weil Verkleinern einer VMDK-Datei geht im Nachhinein nur umständlich per Hand oder du mußt die VM erst langwierig durch den Converter schleichen sehen...

[Mr. T]

Ich geh jetzt mal davon aus, daß mein letzter Code-Block sämtliche alten Kerneleinträge bereinigt hat.
Wenn dem so ist, laß mal noch folgendes durchlaufen, damit auch sonstiges, veralteten SW-Pakete bereinigt werden:

Code: Alles auswählen

sudo apt-get autoremove

LOG

user@ubuntu:~$ sudo apt-get remove --purge linux-image-3.5.0-23-generic
[sudo] password for user:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
linux-image-3.5.0-23-generic*
0 upgraded, 0 newly installed, 1 to remove and 26 not upgraded.
3 not fully installed or removed.
After this operation, 118 MB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 156025 files and directories currently installed.)
Removing linux-image-3.5.0-23-generic ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.5.0-23-generic /boot/vmlinuz-3.5.0-23-generic
update-initramfs: Deleting /boot/initrd.img-3.5.0-23-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.5.0-23-generic /boot/vmlinuz-3.5.0-23-generic
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.5.0-37-generic
Found linux image: /boot/vmlinuz-3.5.0-34-generic
Found initrd image: /boot/initrd.img-3.5.0-34-generic
Found linux image: /boot/vmlinuz-3.5.0-32-generic
Found initrd image: /boot/initrd.img-3.5.0-32-generic
Found linux image: /boot/vmlinuz-3.5.0-31-generic
Found initrd image: /boot/initrd.img-3.5.0-31-generic
Found linux image: /boot/vmlinuz-3.5.0-30-generic
Found initrd image: /boot/initrd.img-3.5.0-30-generic
Found linux image: /boot/vmlinuz-3.5.0-28-generic
Found initrd image: /boot/initrd.img-3.5.0-28-generic
Found linux image: /boot/vmlinuz-3.5.0-27-generic
Found initrd image: /boot/initrd.img-3.5.0-27-generic
Found linux image: /boot/vmlinuz-3.5.0-26-generic
Found initrd image: /boot/initrd.img-3.5.0-26-generic
Found linux image: /boot/vmlinuz-3.5.0-25-generic
Found initrd image: /boot/initrd.img-3.5.0-25-generic
Found memtest86+ image: /memtest86+.bin
done
The link /initrd.img is a damaged link
Removing symbolic link initrd.img
you may need to re-run your boot loader[grub]
The link /initrd.img.old is a damaged link
Removing symbolic link initrd.img.old
you may need to re-run your boot loader[grub]
Purging configuration files for linux-image-3.5.0-23-generic ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.5.0-23-generic /boot/vmlinuz-3.5.0-23-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.5.0-23-generic /boot/vmlinuz-3.5.0-23-generic
Setting up linux-image-3.5.0-37-generic (3.5.0-37.58~precise1) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
update-initramfs: Generating /boot/initrd.img-3.5.0-37-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.5.0-37-generic /boot/vmlinuz-3.5.0-37-generic
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.5.0-37-generic
Found initrd image: /boot/initrd.img-3.5.0-37-generic
Found linux image: /boot/vmlinuz-3.5.0-34-generic
Found initrd image: /boot/initrd.img-3.5.0-34-generic
Found linux image: /boot/vmlinuz-3.5.0-32-generic
Found initrd image: /boot/initrd.img-3.5.0-32-generic
Found linux image: /boot/vmlinuz-3.5.0-31-generic
Found initrd image: /boot/initrd.img-3.5.0-31-generic
Found linux image: /boot/vmlinuz-3.5.0-30-generic
Found initrd image: /boot/initrd.img-3.5.0-30-generic
Found linux image: /boot/vmlinuz-3.5.0-28-generic
Found initrd image: /boot/initrd.img-3.5.0-28-generic
Found linux image: /boot/vmlinuz-3.5.0-27-generic
Found initrd image: /boot/initrd.img-3.5.0-27-generic
Found linux image: /boot/vmlinuz-3.5.0-26-generic
Found initrd image: /boot/initrd.img-3.5.0-26-generic
Found linux image: /boot/vmlinuz-3.5.0-25-generic
Found initrd image: /boot/initrd.img-3.5.0-25-generic
Found memtest86+ image: /memtest86+.bin
done
Setting up linux-image-generic-lts-quantal (3.5.0.37.43) ...
Setting up linux-generic-lts-quantal (3.5.0.37.43) ...
user@ubuntu:~$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
user@ubuntu:~$

[Mr. T]

Was willst du denn machen? Weil Verkleinern einer VMDK-Datei geht im Nachhinein nur umständlich per Hand oder du mußt die VM erst langwierig durch den Converter schleichen sehen...

Ich will die veranschlagten 20 GB für den vmdk auf 10 halbieren, weil ich die 20 nie ausreizen werde und gut 10 GB mehr Platz auf der echten HDD gebrauchen kann. Es laufen ja nur der Webserver und die Datenbank auf dem System.

[Dayworker]

Okeydokey, laß mal bitte noch den anderen Codeblock durchlaufen, damit die anderen alten Kernel auch entfernt werden:

Code: Alles auswählen

sudo apt-get remove --purge linux-image-3.5.0-25-generic
sudo apt-get remove --purge linux-image-3.5.0-26-generic
sudo apt-get remove --purge linux-image-3.5.0-27-generic
sudo apt-get remove --purge linux-image-3.5.0-28-generic
sudo apt-get remove --purge linux-image-3.5.0-30-generic
sudo apt-get remove --purge linux-image-3.5.0-31-generic
sudo apt-get remove --purge linux-image-3.5.0-32-generic
sudo apt-get remove --purge linux-image-3.5.0-34-generic

Danach sollte dann durchlaufen:

Code: Alles auswählen

sudo apt-get autoremove

Abschließend würde ich dann meinen 5-Satz durchlaufen lassen, damit keine Meldungen der Art "0 upgraded, 0 newly installed, 1 to remove and 26 not upgraded. 3 not fully installed or removed." mehr erscheinen:

Code: Alles auswählen

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get autoremove
sudo apt-get clean

Da sich 12.04LTS im Gegensatz zu 12.10 anscheinend etwas zickig benimmt, kannst du mal nachsehen, ob wieder ein älterer Kernel Platz wegnimmt:

Code: Alles auswählen

sudo dpkg -l | grep linux-image

Als Ausgabe sollten dir alle installierten Kernel angezeigt werden, die du dann ggf wieder an folgende Befehle übergibst:

Code: Alles auswählen

sudo apt-get remove --purge linux-image-3.5.0-XY-generic
sudo apt-get autoremove

Beachten mußt du dabei nur, weder den neuesten Kernel noch "linux-image-generic" einzusetzen oder du stehst vor einem nicht bootendem System.



Kommen wir zu deinem Platzproblem. VMs legt man immer nur so groß wie nötig und keinesfalls wie möglich an. Das gilt sowohl für CPU, RAM als auch VMDK.
Du hast jetzt wie gesagt zwei Möglichkeiten, wobei ich mir grad mit dem Converter nicht sicher bin, ob dieser das überhaupt mit der Workstation als Ziel kann. Bleibt also nur übrig, entweder die VMDK auf das die Gast-Schreibperformance stark verringernde Sparse-Format umzustellen und die VMDK dann in der Hoffnung, daß kein Prozess extrem viele Schreib-IOs produziert und dadurch die VMDK wieder auf die volle Grösse aufbläst, regelmäßig zu "shrinken" oder die VM komplett umzubauen.
Ich würd trotz meiner Nullerfahrung mit LVM zu einem Umbau tendieren. Denn bei der Gelegenheit köntest du auch gleich den Blödsinn mit der SWAP-Datei von Linux auf ein Windows-Laufwerk bereinigen. Falls die SWAP-Datei aus welchem Grund auch immer mal nicht greifbar ist, fährt dir Linux mit ziemlicher Sicherheit gegen die Wand.

[Mr. T]

Ok, den ersten Block habe ich komplett abgearbeitet und alles verlief fehlerfrei. Es sind nur die beiden Kerneldateien zur Version 3.5.0-37 übrig geblieben.

Ich würd trotz meiner Nullerfahrung mit LVM zu einem Umbau tendieren.

Wie muss ich mir den vorstellen? Das System komplett neu aufsetzen?
Was wären denn deiner Meinung nach gut geeignete Größen-Werte für die wichtigsten Partitionen?

[JustMe]

Schau' doch mal bitte mit

Code: Alles auswählen

df -h

nach, welchen Spielraum Du ueberhaupt fuer eine Groessenaenderung hast...

So ganz am Anfang des Threads in der Uebersicht von gparted waren zwar auf sda1 (/boot) nur 4.71MiB frei, aber auf sda5 (/lvm) sah es mit 20MiB auch nicht viel besser aus. Das kann natuerlich auch gparted geschuldet sein, das das Filesystem eventuell nicht korrekt erkannt hatte. Deswegen die Kontrolle mit df im laufenden System. Wenn dann die Arbeitspartition auch vollgelaufen ist, wird da leider nichts zu shrinken sein.

Sollte df tatsaechlich viel freien Platz auf sda5 anzeigen, kannst Du diesen freien Platz mal per dd mit Nullen fuellen (Nuller-Datei hinterher loeschen nicht vergessen!), und dann die vmdk erneut durch vmware-diskmanager mit -t 0 jagen. Danach sollte die vmdk entsprechend kleiner sein. Type 0 steht bereits fuer "single growable"; damit koennte die vmdk zwar spaeter wieder bis auf max 20GB wachsen, aber dann koenntest Du einfach erneut ausnullen und mit vmware-diskmanager konvertieren.
Diesen Vorgang sollen zwar auch die vmware-tools beherrschen, aber die von mir so gern zitierte Tante G**gle meint, dass das oft genug schiefgeht bei Verwendung der Tools.

[Dayworker]

Neu aufsetzen wäre auch eine Möglichkeit und unter Umständen auch schneller. Da ich aber den Zeitaufwand für die Personalisierung höher einschätze, würde ich einfach auf eine Migration setzen.
Das mit LVM im laufenden Betrieb mögliche Verkleinern von Volumes/Partitionen hilft dir hier nicht weiter, da dadurch die darunterliegende und für die VM unsichtbare VMDK nicht wieder kleiner wird.

Vom Arbeitsaufwand her schau dir mal http://wiki.ubuntuusers.de/Ubuntu_umziehen an und schlaf auch ne Nacht drüber. Ob du nachher noch LVM nutzen willst oder den als "boot" markierten Mountpunkt der Einfachheit halber in eine normale Partition integrierst und stattdessen dem Linux eine SWAP-VMDK gönnst, kannst du dann immer noch entscheiden.
Was geeignete Partitions- oder Plattengrössen sind, kann ich dir nicht sagen. Das hängt von deinen Daten ab. Für meine Lubuntu-VM mit Tiny Tiny RSS habe ich eine 8GB Platte (VMDK) fürs System und eine zweite VMDK von 512MB als SWAP eingerichtet, wobei von der Systemplatte immer noch 5.5GB frei sind und die SWAP-Platte im Sparse/Thin-Format gerade mal 25MB auf der Host-Platte belegt. Wie groß die SWAP-Partition oder Platte werden muß oder sein sollte, kannst du in meinen Augen aber vom vRAM der VM abhängig machen. Da es performancetechnisch wenig Sinn hat, einer VM unter VMwares Desktop-Produkten mehr als 1024MB bzw je nach Version maximal 1536MB vRAM zu geben, würde ich auch nur eine SWAP-Platte in dieser in Betracht ziehen. VMware markiert bei allen Desktop-Produkten ab einer gewissen vRAM-Grösse den größten Teil bekanntlich als auslagerungsfähig (welchem das Host-OS zz nachkommt und dann im virtuellen Arbeitsspeicher des Hosts sprich Auslagerungsdatei von Windows rumliegt) und behält nur noch ~500MB des vRAMs im pRAM. Ob dein Webserver mit nur 512MB hinkommt, hängt wieder mal von deinen Anforderungen ab. Grosse Performance kann man von der Datenbank nicht erwarten, aber zum Testen als Einzelbenutzer oder mit dem Hinweis auf die kleine VM bzw den kleinen Webserver läßt sich damit auch als Mehrbenutzer umgehen:

Code: Alles auswählen

ttrss@ttrss:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       7.9G  2.0G  5.5G  27% /
udev            241M  4.0K  241M   1% /dev
tmpfs           100M  284K  100M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            249M     0  249M   0% /run/shm
none            100M   16K  100M   1% /run/user


Die Partitionierung sind folgendermaßen aus, wobei "fdisk" von Ubuntu anscheinend immer noch Probleme mit der korrekten Grössenanzeige hat. Also nicht verwirren lassen:

Code: Alles auswählen

ttrss@ttrss:~$ sudo fdisk -l
[sudo] password for ttrss:

Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000e0f72

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    16775167     8386560   83  Linux

Disk /dev/sdb: 536 MB, 536870912 bytes
37 heads, 35 sectors/track, 809 cylinders, total 1048576 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002b2d6

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     1046527      522240   82  Linux swap / Solaris


Wenn ich den freien Platz im Gast und dessen geringe monatliche Änderung sehe, wäre ich vermutlich auch mit einer 4GB VMDK ausgekommen. Aber so ganz läßt sich der Platzbedarf bei RSS nicht vorhersagen. Dazu laufen sowohl die Gesamtzahl der eingeschriebenen RSS-Threads, vor allem deren Aufbewahrungszeit als auch die Häufigkeit von RSS-Änderungen mit in die Gleichung rein. Ansonsten habe ich in der VM nur die TTRSS-Voraussetzungen Apache + PHP + MySQL erfüllt und nur davon abhängige Komponenten sowie den LXDE-Desktop mitinstalliert.





[add]
Falls JustMe richtig liegen und du wirklich nur 20MiB frei haben solltest, kannst du das Verkleinern der VMDK sowieso vergessen und müßtest eher ans Vergrössern oder mal ans Extrem-Klar-Schiff-Machen denken. Manchmal ist es schon erstaunlich, wieviel Platz unbenötigte DB-Einträge wegnehmen können.
Das Shrinken unter Linux würde ich von Hand machen. Dazu nehme ich immer das gparted-ISO. Die grundlegenden Schritte zu "gparted" habe ich im Thread HowTo - Nachträgliches Alignment auf Sektor 2048 beschrieben. Hier nur die Kurzform und im Anschluß dann mit dem VMware-vdiskmanager die Luft aus der VMDK lassen:

1. sudo mount /dev/sda1 /media (mountet die erste Partition nach /media)
2. cd /media (springt in Media-Verzeichnis und somit in die dort vorher eingehängt erste Partition)
3. sudo dd if=/dev/zero of=0bits bs=20971520 (beschreibt die unter "/media" eingehängte Partition mit 20MiB-Blöcken komplett voll)
4. sudo rm 0bits (löscht die Datei "0bits" wieder)
5. VM beenden (Rechtsklick in den Desktop und "Exit" wählen)