[DE] siduction stürzt in virtualbox ab

[cas]

hallo,
ich habe ein gravierendes problem entdeckt.

siduction stürzt ab, wenn es  in einer virtuellen maschine installiert ist. und zwar dann, wenn ich mehrmals hintereinander "apt-get update" ausführe. das erste mal geht problemlos, das zweite mal vielleicht auch noch. aber beim soundsovielten mal hintereinander wird die gesamte virtuelle maschine abgebrochen.
dies passiert, wenn ich siduction direkt installiert habe, also noch praktisch nichts konfiguriert.

ich habe dies auf zwei rechnern probiert.
auf einer siduction maschine und auf einem debian-testing.

gruß, christian

[Geier0815]

Vielleicht solltest Du uns ein paar Informationen zukommen lassen: Was für eine virtuelle Maschine? VM-Ware oder virtuell-box? Wieviel Speicher hat die VM von wieviel Gesamtspeicher? Wie sieht die Patitionierung und die Bereitstellung der virtuellen Festplatte aus? NAT oder direktes Netzwerk? Irgendwelche Auffälligkeiten in den logs nach dem Abbruch? Passiert dies auch bei anderen Distributionen oder expliziet nur bei siduction?

[captagon]

hallo,
ich habe ein gravierendes problem entdeckt.

siduction stürzt ab, wenn es  in einer virtuellen maschine installiert ist. und zwar dann, wenn ich mehrmals hintereinander "apt-get update" ausführe. das erste mal geht problemlos, das zweite mal vielleicht auch noch. aber beim soundsovielten mal hintereinander wird die gesamte virtuelle maschine abgebrochen.
dies passiert, wenn ich siduction direkt installiert habe, also noch praktisch nichts konfiguriert.

Dein Speicher läuft vermutlich voll- den hast du dann aber für deine virtuelle Maschine meines Erachtens einfach zu klein ausgelegt. Mache zwischendurch ein  

Code: [Select]

apt-get clean oder noch besser-- vergrößere den Speicherbereich.

[devil]

Ein n-ter Run von apt-get update sollte keine neuen Daten erzeugen. Und ein erster Run erzeugt bei täglicher Ausführung rund 500 kb. Am Speicher wirds also nicht liegen, es sei denn, er ist generell zu klein.

greetz
devil

[captagon]

Ein n-ter Run von apt-get update sollte keine neuen Daten erzeugen. Und ein erster Run erzeugt bei täglicher Ausführung rund 500 kb. Am Speicher wirds also nicht liegen, es sei denn, er ist generell zu klein.

Naja, ich vermutete, dass es nicht nur beim update blieb, sondern dass da u.U. ein dist-upgrade dahinter laufengelassen wurde...

[cas]

Naja, ich vermutete, dass es nicht nur beim update blieb, sondern dass da u.U. ein dist-upgrade dahinter laufengelassen wurde...

Nein, ich habe das nochmals mit einer frischen VM reproduzierbar ausprobiert.

HOST: siduction reloaded, DU gestern, frische HW:

Code: [Select]

cas@dino:~$ inxi
CPU~Quad core Intel Core i5-3570K CPU (-MCP-) clocked at 1600.000 Mhz Kernel~3.6-0.towo-siduction-amd64 x86_64 Up~6:19 Mem~1421.5/7886.7MB HDD~2208.5GB(35.8% used) Procs~175 Client~Shell inxi~1.8.15  


GAST: siduction reloaded

das Einrichten geht standardmäßig, fast ohne Änderungen von den Vorgaben folgendermaßen vor sich:

1) VM in VB erstellen
auf 700 MB RAM erhöhen
in VB unter "Ändern":
 Diskette entfernt
 Siduction.iso an IDE-Controller eingebunden

2) VM starten (von angeschlossener ISO aus)

3) in VM
mit gparted
  a) Partitionstabelle erstellen
  b) 2 Partitionen erstellen: 6,5 GB ext4 sda1; 1,5GB swap sda2
 
4) auf so eingerichteter HD sidu-installer laufen lassen

5) reboot (ohne ISO)

6) Wenn ich in dieser jungfäulichen Maschine mehrmals apt-get update laufen lasse (wo ich sonst noch gar nichts getan habe), stürzt sie reproduzierbar ab.
 
In der linke Spalte von VB, steht dann "abgebrochen" (mit Einbahnstrassensymbol) statt "ausgeschaltet" bzw. "wird ausgeführt".

Speicher des Gastes sieht nach Neustart so aus:

Code: [Select]

cas@siductionbox:~$ df -h
Dateisystem                                            Größe Benutzt Verf. Verw% Eingehängt auf
rootfs                                                  6,5G    3,2G  3,1G   51% /
udev                                                     10M       0   10M    0% /dev
tmpfs                                                    69M    388K   69M    1% /run
/dev/disk/by-uuid/371eb172-d7bc-444a-9551-77d7121ab2b7  6,5G    3,2G  3,1G   51% /
tmpfs                                                   5,0M       0  5,0M    0% /run/lock
tmpfs                                                   443M       0  443M    0% /run/shm
cas@siductionbox:~$ free -h
total       used       free     shared    buffers     cached
Mem:          688M       466M       221M         0B        19M       218M
-/+ buffers/cache:       228M       459M
Swap:         1,5G         0B       1,5G

cas@siductionbox:~$ inxi
CPU~Single core Intel Core i5-3570K CPU (-UP-) clocked at 3396.392 Mhz Kernel~3.4-4.towo-siduction-686 i686 Up~11 min Mem~245.5/688.7MB HDD~8.6GB(-) Procs~122 Client~Shell inxi~1.8.5  
cas@siductionbox:~$



Auf meiner Arbeitsstelle brauche ich eine VM. Dort war es mir aufgefallen, weil ich zweimal hintereinander "apt-get update" ausgeführt hatte. Zweimal hintereinander "apt-get update" ausführen, kann ja beim arbeiten durchaus mal vorkommen.
Warum auch immer, ist es bei oben beschriebener jungfräulichen VM nicht ganz so schlimm.
Aber spätestens nach dem sechsten mal hintereinander "apt-get update" stürzt die Maschine ab.
Zwar wird man selten so oft hintereinander "apt-get update" ausführen, dennoch ist das so für mich nicht brauchbar.

Wie gesagt, bei mir ist es reproduzierbar. Wundert mich, dass das bei niemandem anders so ist.

Bei einer frischen VM, in der squeeze installiert wurde, passiert dies nicht.

Bin ratlos.
Viele Grüße, Christian

[cas]

Bei einer 64bit-siduction VM ebenfalls Abbruch.
Der Abbruch ist insofern jeweils abrupt, als bspw. die bash-history nicht mehr geschrieben wird.

Start von der Kommandozeile gibt leider keine Fehlermeldung.

Code: [Select]

cas@dino:~$ VBoxManage startvm sidu64
Waiting for VM "sidu64" to power on...
VM "sidu64" has been successfully started.
cas@dino:~$


In den logs innerhalb von /var/log konnte ich nichts entdecken, was mir relevant erschien. Ich weiß aber auch nicht, nach was ich suchen soll.

Gruß, Christian

[holgerw]

Hallo,

ich habe in vbox 4.2.0 unter OpenSUSE 12.2 64 Bit ein siduction razorqt 64 Bit laufen, die Gasterweiterungen sind installiert. Mein PC hat nun auch 8 GB Ram, so dass ich der VM großzügig 2 GB Ram spendiert habe.

Da stürzt nichts ab und siduction geht ab wie eine Rakete.

Viele Grüße,
  Holger

Edit agaida: http://www.siduction.org/index.php?name=PNphpBB2&file=download&id=191 - dat Bild - kann es sein, dass unser Forum .jpeg nicht mag? Steht jedenfalls so in dem Link über "Filename"

[spacepenguin]

Offtopic: Warum ist denn jetzt das Bild schon wieder "Forbidden You don't have permission to access /modules/PNphpBB2/files/bildschirmfoto1_149.jpeg on this server"? Sowohl mit siduction.org als auch mit www davor.

[reddark]

ich kann es nicht mal anklicken ... kein link ??

[holgerw]

Hallo Susan, hallo @reddark,

ich habe auch keinen klickbaren Link mehr.

Viele Grüße,
  Holger

[cas]

Hallo,

ich habe in vbox 4.2.0 unter OpenSUSE 12.2 64 Bit ein siduction razorqt 64 Bit laufen, die Gasterweiterungen sind installiert. Mein PC hat nun auch 8 GB Ram, so dass ich der VM großzügig 2 GB Ram spendiert habe.

Da stürzt nichts ab und siduction geht ab wie eine Rakete.

bezieht sich das auf das allgemeine verhalten? ich habe das problem ja bei einem ganz bestimmten vorgang.

ich verwende vbox 4.1.18.

spasseshalber habe ich noch eine maschine mit siduction razor-qt32 erstellt. wiederum, das gleiche problem.
um mir zu beweisen, dass ich nicht doof bin, habe ich einige weitere maschinen mit debian-ähnlichen OS installiert.

Ubuntu 12.04-32_mini.iso
ubuntu-12.10-beta2-server-i386.iso
linuxmint-13-cinnamon-dvd-32bit.iso

ich habe mir jeweils gleich nach der installation eine for-schleife geschrieben. da kann ich hundertmal apt-get update ausführen. das klappt auch, wie es normalerweise zu erwarten wäre.

irgendwie komisch, weil diese OS ja recht ähnlich sind und sich vermutlich auf dieser Ebene (apt-get) kaum unterscheiden dürften.
Aber so ist meine Erfahrung.

Gruß, Christian

[cas]

moin,
bin der sache jetzt ein ganzes stück näher gekommen.
http://ftp://ftp.spline.de scheint der übeltäter zu sein.

im original steht in /etc/apt/sources.list.d/siduction.list  

deb ftp://ftp.spline.de/pub/siduction/siduction unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/siduction unstable main
deb ftp://ftp.spline.de/pub/siduction/fixes unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/fixes unstable main

ändern auf

deb ftp://ftp.spline.de/pub/siduction/base unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/base unstable main
deb ftp://ftp.spline.de/pub/siduction/extra unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/extra unstable main
deb ftp://ftp.spline.de/pub/siduction/fixes unstable main
#deb-src ftp://ftp.spline.de/pub/siduction/fixes unstable main

gemäß siduction-homepage bringt nichts.
jedoch gibt

deb ftp://ftp.uni-stuttgart.de/siduction/base unstable main
#deb-src ftp://ftp.uni-stuttgart.de/siduction/base unstable main
deb ftp://ftp.uni-stuttgart.de/siduction/extra unstable main
#deb-src ftp://ftp.uni-stuttgart.de/siduction/extra unstable main
deb ftp://ftp.uni-stuttgart.de/siduction/fixes unstable main
#deb-src ftp://ftp.uni-stuttgart.de/siduction/fixes unstable main

die lösung. kein absturz mehr.
Soweit ich das bis jetzt überblicke, ist das problem für mich gelöst. das andere hlabe dutzend test-VMs werde ich auch nochmal testen, jetzt habe keine zeit und lust mehr dazu.

Gruß, C

[agaida]

Offtopic: Warum ist denn jetzt das Bild schon wieder "Forbidden You don't have permission to access /modules/PNphpBB2/files/bildschirmfoto1_149.jpeg on this server"? Sowohl mit siduction.org als auch mit www davor.

Siehe die Erläuterung im Ursprungspost.

[cas]

Hallo,
was sagt eigentlich die Geschäftsleitung zu dem von mir beschriebenen Phänomen?
Das ist schließlich nicht normal und auch nicht ok.
Aus irgendeinem Grund verhält sich der spline-Server anders als bspw. der Stuttgarter Server.
(das Beschriebene ist bei mir nach wie vor reproduzierbar.)

Grüße, Christian