Testing - Virtualbox Extrem Langsames Entpacken / installieren

[willy4711]

Es ist zum Mäuse-Melken
Kann nicht mehr genau sagen, seit wann, aber ich meine, seitdem ich wg. Abhängigkeiten der originalen Virtualbox auf die Debian-Version
geschwenkt bin.
Wollte gestern Abend ein Dist-Upgrade Stable ---> Testing machen. Hab es dann aufgegeben zu warten, und bin schlafen gegangen.

Nur mal ein Beispiel: das Entpacken der Kernel Headers also der drei Pakete
linux-headers-4.18.0-1-amd64 linux-headers-4.18.0-1-common linux-headers-amd64 dauert im Minimum 30 Minuten.
Vorhin hab ich eine Net-Inst Minimal-Installation gemacht: Nach der Auswahl der Komponenten (Nur Debian- Standard Werkzeuge)
durfte ich fast 60 Minuten warten. Das ging früher in noch nicht mal 10 Minuten.

haveged habe ich im Nachhinein immer als Erstes installiert.
In Protokollen ist nichts zu finden.
Die Auslastung der CPU (im Host mit top) ist dabei (entpacken) bei unter 1%
Das sich überhaupt noch was tut, ist lediglich am zeitweiligen Flackern des Festplatten- Icons in Tray des VM-Fensters zu sehen.

Installiert sind im Host und in der VM die jeweiligen Pakete der Virtualbox 5.2.18-dfsg
Ich geb der VM immer 4 GB RAM und 2 CPU Kerne.
Das Ändern der Chip-Sätze hab ich versucht (PIIX -->ICH9)---> Nix
Paravirtualisierung ist auf Standard --> KVM
Ansonsten belasse ich alles wie Vorgegeben.
Die VM selbst verhält sich normal flott.

Hat jemand das auch schon beobachtet?
Habt ihr einen Idee woran das Liegen könnte, oder wie man der Sache nachspüren könnte?

[rendegast]

In Protokollen ist nichts zu finden.

Auch 'dmesg'?

Code: Alles auswählen

swapon -s

Code: Alles auswählen

hdparm -tT /dev/sdX

?

[willy4711]

Hallo rendegast ,
Erst mal vielen Dank für die Antwort.
zu deinen Fragen: Eine Swap- Partition gibt es nicht.

Aus der VM:

Code: Alles auswählen

root@willy-pc:~# hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   7268 MB in  2.00 seconds = 3636.76 MB/sec
 Timing buffered disk reads: 456 MB in  3.02 seconds = 151.09 MB/sec

Zum Vergleich, der Host:

Code: Alles auswählen

~# hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads:   8380 MB in  2.00 seconds = 4193.68 MB/sec
 Timing buffered disk reads: 1626 MB in  3.00 seconds = 541.44 MB/sec

Die Daten der VM: 40451
dmesg der ganzen Session (update ab Zeile ca 497)40449
journalctl -f während des Updates: 40450

Vielleicht kann ja irgend jemand was damit anfangen.
Wie gesagt nach dem Download waren es dann 1,5 h

[habakug]

Hallo,

da ist wohl doch ein Swap in der virtuellen Maschine:

Code: Alles auswählen

Okt 03 21:30:14 sidflux os-prober[30822]: debug: /dev/sda2: is active swap

Was noch auffällt:

Code: Alles auswählen

VRAM size:       128MB
3D Acceleration: on
2D Video Acceleration: off
Video mode:      2008x1276x32 at 0,0 enabled
Configured memory balloon size:      0 MB

Sowas mittendrin

Code: Alles auswählen

Okt 03 20:33:03 sidflux systemd-journald[266]: Received SIGTERM from PID 1 (systemd).

hat meist seinen Grund.

Gruss, habakug

[willy4711]

da ist wohl doch ein Swap in der virtuellen Maschine:

Code: Alles auswählen

Okt 03 21:30:14 sidflux os-prober[30822]: debug: /dev/sda2: is active swap

Oh sorry Hatte Siduction Xfce auf --> die hat kein Swap
Ich dreh langsam durch mit den vielen VM's und dem ewigen Warten

Code: Alles auswählen

root@sidflux:~# blkid
/dev/sda1: UUID="1acc24d7-b334-4199-8058-dbd215972f28" TYPE="ext4" PARTUUID="a04c60d2-01"
/dev/sda2: UUID="4229a21b-8eda-4813-ab14-6f6305763184" TYPE="swap" PARTUUID="a04c60d2-02"

hat meist seinen Grund.

Tja das wäre dann ja bei allen Maschinen so, weil die alle in trauter Eintracht während des Updates dahin bummeln
Kanns nicht auch am Kernel - Update liegen ? Hab noch nie das Journal während eines Updates überprüft.

Hier nochmal top, das zeigt dass Swap nicht benutzt wird

[rendegast]

Nur nochmal nachgefragt,
das Problem mit dem langsamen Upgrade-Prozeß betrifft (nur) die VM?

Okt 03 20:33:01 sidflux systemd[1]: Stopping Virtualbox guest utils...
Okt 03 20:33:01 sidflux systemd[1]: Stopping Network Time Synchronization...
Okt 03 20:33:01 sidflux systemd[1]: Stopped Network Time Synchronization.
Okt 03 20:33:01 sidflux systemd[1]: Starting Network Time Synchronization...
Okt 03 20:33:01 sidflux virtualbox-guest-utils[31299]: Stopping VirtualBox Additions.
Okt 03 20:33:01 sidflux kernel: 00:26:25.843332 control Guest control service stopped
Okt 03 20:33:01 sidflux kernel: 00:26:25.843416 control Guest control worker returned with rc=VINF_SUCCESS
Okt 03 20:33:01 sidflux systemd[1]: Stopped Virtualbox guest utils.
Okt 03 20:33:01 sidflux kernel: 00:26:25.844950 main Session 0 is about to close ...
Okt 03 20:33:01 sidflux kernel: 00:26:25.844991 main Stopping all guest processes ...
Okt 03 20:33:01 sidflux kernel: 00:26:25.845008 main Closing all guest files ...

virtualbox-guest wird gestoppt, finde keine Nachricht über einen anschließenden restart.

Okt 03 21:28:37 sidflux systemd[1]: getty.target: Wants dependency dropin /etc/systemd/system/getty.target.wants/getty@tty1.service target /lib/systemd/system/autovt@.service has different name

Die Nachricht taucht mehrmals auf (wohl einfach einigen 'systemctl daemon-reload' im Zuge der Upgrades geschuldet),
könnte für das Problem unbedeutend sein.
autovt@ ist noch ein valider Link? Bei mir

Code: Alles auswählen

# ll /etc/systemd/system/ /lib/systemd/system/ | grep autovt
lrwxrwxrwx 1 root root   17 Apr  5 23:33 autovt@.service -> mingetty@.service
lrwxrwxrwx 1 root root   14 Feb 25  2018 autovt@.service -> getty@.service

(mingetty@ ist dabei eine selbsterzeugte unit, entsprechend aktiviert, sodaß mingetty statt getty/agetty benutzt wird)



--------------------------------------------------------

Kann nicht mehr genau sagen, seit wann, aber ich meine, seitdem ich wg. Abhängigkeiten der originalen Virtualbox auf die Debian-Version geschwenkt bin.

Das läßt sich aus /var/log/dpkg.log* lesen.

[KP97]

....seitdem ich wg. Abhängigkeiten der originalen Virtualbox auf die Debian-Version geschwenkt bin.

Welche Abhängigkeiten waren das denn?
Wenn Du das Originalpaket Debian 9 unter Testing bzw. Sid laufen lassen willst, braucht es libcurl3. Das gibt es noch in beiden Zweigen, geht aber nicht parallel.
Ich meine, nur cmake ist abhängig von libcurl4, aber wenn Du keine Develop-Pakete brauchst, kannst Du ja bei libcurl3 bleiben.
Dann gibt es noch das Originalpaket für Debian 10, das wurde aber in einen Topf mit Ubuntu geworfen - sehr unschön - da dann auch Ubuntu im Namen auftaucht.
Du kannst ja mal testen, ob die Originale besser laufen oder ob es was anderes ist.
Ich habe in meinem Sid momentan keine Vbox, daher kann ich weiter nichts dazu sagen.

[willy4711]

Nur nochmal nachgefragt,
das Problem mit dem langsamen Upgrade-Prozeß betrifft (nur) die VM?

Definitiv: ja
Habe vorhin mal wieder Gnome gestartet (auch Buster) da gab es 645 Pakete /524 MB Updates incl. Nvidia-Treiber
--> 18 Minuten incl fast 10 Minuten bei mir normalen Schnecken - Download.

der Start ist für eine VM - Siduction Fluxbox - ganz in Ordnung (finde ich)

Code: Alles auswählen

~$ systemd-analyze
Startup finished in 3.454s (kernel) + 14.566s (userspace) = 18.020s
graphical.target reached after 11.402s in userspace

Wo hast du denn dieses ll her ? Gibt es bei mir nur in Siduction als Root und in Buster gar nicht.

Code: Alles auswählen

willy@sidflux:~$ ll /etc/systemd/system/ /lib/systemd/system/ | grep autovt
ll: command not found

Geht ja auch so

Code: Alles auswählen

willy@sidflux:~$ ls -al /etc/systemd/system/ /lib/systemd/system/ | grep autovt
lrwxrwxrwx  1 root root    14 Sep 25 16:11 autovt@.service -> getty@.service

mingetty ist bei mir nirgends installiert.

Wenn Du das Originalpaket Debian 9 unter Testing bzw. Sid laufen lassen willst, braucht es libcurl3. Das gibt es noch in beiden Zweigen, geht aber nicht parallel.
Ich meine, nur cmake ist abhängig von libcurl4, aber wenn Du keine Develop-Pakete brauchst, kannst Du ja bei libcurl3 bleiben.

Scheint raus geflogen bei Buster https://packages.debian.org/search?keywords=libcurl3

Code: Alles auswählen

~$ apt-cache depends libcurl4
libcurl4
  Hängt ab von: libc6
  Hängt ab von: libcom-err2
  Hängt ab von: libgssapi-krb5-2
  Hängt ab von: libidn2-0
  Hängt ab von: libk5crypto3
  Hängt ab von: libkrb5-3
  Hängt ab von: libldap-2.4-2
  Hängt ab von: libnghttp2-14
  Hängt ab von: libpsl5
  Hängt ab von: librtmp1
  Hängt ab von: libssh2-1
  Hängt ab von: libssl1.1
  Hängt ab von: zlib1g
  Kollidiert mit: <libcurl3>
  Empfiehlt: ca-certificates
  Ersetzt: <libcurl3>

Nach https://packages.debian.org/stretch/libcurl3
sind die Abhängigkeiten identisch.
Da immer ein > angegeben ist, sollte man an sich libcurl4 durch libcurl3 ersetzen können.

Dann gibt es noch das Originalpaket für Debian 10, das wurde aber in einen Topf mit Ubuntu geworfen - sehr unschön - da dann auch Ubuntu im Namen auftaucht.

Das ist neu und hab ich glatt übersehen

Ubuntu 18.04 / Debian 10 AMD64

Scheint mir aber die beste Lösung zu sein, anstatt am System herumzuschrauben.
Na dann habe ich ja was am Wochenende zu tun. und zu vergleichen.
Danke für den Tipp , wenn ich auch gerne wüsste, was da los ist.

[KP97]

@willy4711
Libcurl3 gibt es noch im Repo für Sid, das kann man problemlos installieren, ich hatte das auch gemacht. Da ich die Vbox aber auf meinem Testsystem eingerichtet habe, war das keine Lösung, nur zum kucken. Das Testsystem nutze ich zum kompilieren, es hat daher alle .dev-Pakete, u.a. brauche ich dort auch cmake, deswegen bin ich wieder mit libcurl4 unterwegs.
Dann habe ich auch die Pakete aus dem Repo installiert, aber bei mir liefen die echt unrund (wie so oft in der Vergangenheit). Die systemd-Services starteten nicht immer, die Kernel-Headers wurden zwischendurch nicht mehr gefunden, dann half nur ein reinstall von virtualbox-dkms, also ziemlich nervig das Ganze. Da ich momentan keine Vbox brauche, habe ich alles wieder deinstalliert.
Wie immer laufen bei mir die Originalpakete problemlos, daher bleibe ich auch dabei.
Wenn ich mal wieder eine Vbox aufsetze, werde ich mit dpkg-deb den Namen ändern. Ich weiß, das ist Erbsenzählerei, aber mich ärgert sowas. Als ob Ubuntu und Debian das Gleiche wäre....zum kotzen diese Maintainer....;-)

[tijuca]

Oder einfach mal libvirt benutzen/ausprobieren ... ist auf Dauer schmerzfreier.

Virtualbox ist von Oracle und somit aus Debiansicht eben auch nicht Debian da nicht DFSG konform.

[willy4711]

So - wollte an sich einen groß angelegte Vergleichs - Aktion starten Vm's angelegt und geklont - auf einem Xfce wieder
Oracle - Virtualbox installiert ---> das Debakel war ernüchternd nach 4 Stunden Siduction - erst- Upgrade hab ich mitten im Entpacken aufgegeben
so -- heute früh dann unter Gnome die gnome-boxes installiert, da ich keinerlei Erfahrung mit anderen Virtualisierungs- Lösungen
außer Virtualbox und ganz früher VMware habe.
Installiert ---> die gestoppte vdi - VM geöffnet ---> Das Upgrade in 5 Minuten vollendet.

Oder einfach mal libvirt benutzen/ausprobieren ... ist auf Dauer schmerzfreier.

Schein ja wirklich so zu sein. VirtualBox ist wohl im Augenblick einfach kaputt.
Zu Gnome-Boxes / libvirt /Qemu hab ich allerdings einen Haufen Fragen, die ich dann in diversen extra- Threads stellen möcht, soweit es nicht durch Manuals abgedeckt ist.

Eine Frage hätte ich aber möglichst hier noch beantwortet:
Wie bekomme ich es hin, einer VM gemeinsame Ordner zu verpassen?
In der Hilfe von Gnome-Boxes steht, dass man die unter Eigenschaften --> Geräte und Freigaben auswählen kann.

Nur. Da gibt es nur CD/DVD und USB - Geräte zum Auswählen.

Im "Supermarkt" von Synaptic habe ich qemu-guest-agentgefunden, was eventuell dafür verantwortlich sein könnte.
Bloß macht es ja nun keinen Sinn, einfach einmal quer durch da Angebot zu installieren.

[KP97]

@willy4711
Ich greife das nochmal auf, ließ mir doch keine Ruhe.
Ich habe auf meinem Sid Testsystem eine Virtualbox von der HP für Debian 10 eingerichtet:
https://www.virtualbox.org/wiki/Downloads
Bei der Gelegenheit habe ich mit dpkg-deb gleich den Namen geändert (Ubuntu~ entfernt).
So, dann wie gewohnt das Paket und die extensionpacks installiert, gestartet und alles lief sauber.
Dann Siduction patience mit Xfce-Desktop heruntergeladen und in der Vbox installiert. Nach 56% beim installieren der Pakete blieb es hängen und es bewegte sich so gut wie nichts mehr. Soweit kann ich also Deine Aussage bestätigen. Ich hatte aber den Eindruck, daß der Fehler im Installer von Siduction-Xfce liegt. Einen anderen Desktop habe ich aber nicht mehr getestet, sondern stattdessen Fedora 29 installiert. Hier lief alles wie gewohnt und innerhalb von 20 Minuten war Fedora einsatzbereit.
Also ich vermute, daß Virtualbox richtig funktioniert, nur halt nicht Xfce von Siduction.
Kannst ja nochmal probieren, ob Siduction-KDE besser läuft.

[willy4711]

@willy4711
Ich hatte aber den Eindruck, daß der Fehler im Installer von Siduction-Xfce liegt. Einen anderen Desktop habe ich aber nicht mehr getestet, sondern stattdessen Fedora 29 installiert. Hier lief alles wie gewohnt und innerhalb von 20 Minuten war Fedora einsatzbereit.

Ich hab das Problem auch mit normalen Debian- Installationen.
Hab nur noch meine Windows-Sachen in der Virtualbox und bin mit Linux VM's erstmal auf den virt-manager umgestiegen. Hatte vorhin mal Test halber eine Debian-Buster Minimal-Installation mit einer Net-Inst-CD gemacht (extra ohne Netz) es war grausam.45 Minuten um ein Paar Dateien zu kopieren.
Dann hieße dass, das der Fehler im Installer bzw. dem zuständige Entpacker (??) liegt, im Zusammenspiel mit Virtualbox, denn sonst funktioniert es ja bei einer normalen Installation.
Hab noch ein manjaro-iso und werde das auch nochmal testen.

[willy4711]

So - Hab jetzt nochmal getestet:
Manjaro: Normale Installation 12 Minuten, normal schnelles Erst--Update (12 Minuten 452MB)

Debian Stretch (debian-live-9.5.0-amd64-lxde.iso) : Etwas langsamere Installation (15 MInuten)

Das Erst- Update (247 MB) war dann mit 55 Minuten zugange.

Der Installer kann es also nicht wirklich sein. Oder ist der bei Update auch am Zuge? Glaube das nicht.
Das Entpacken der Headers / Image hat alleine fast 40 Minuten gedauert.

[rendegast]

Arbeitest Du mit Spezialitäten wie virtio?
Mal extensions / guest-additions weglassen?

Gegenprobe mit oracle-virtualbox gemacht?

Code: Alles auswählen

deb http://download.virtualbox.org/virtualbox/debian stretch contrib