Kein Zugriff auf Konsole einer Virtuellen Maschine
- Thread starter chralt
- Start date
Nachtrag zu
for f in $(dpkg -l | grep "rc " | cut -d " " -f 3); do echo $f; sudo apt purge -y $f; done
sudo kann raus und apt-get statt apt vermeidet Warnungen bei Nutzung in scripts. Also:
for f in $(dpkg -l | grep "rc " | cut -d " " -f 3); do echo $f; apt-get purge -y $f; done
for f in $(dpkg -l | grep "rc " | cut -d " " -f 3); do echo $f; sudo apt purge -y $f; done
sudo kann raus und apt-get statt apt vermeidet Warnungen bei Nutzung in scripts. Also:
for f in $(dpkg -l | grep "rc " | cut -d " " -f 3); do echo $f; apt-get purge -y $f; done
Right, das Script läuft auch so auf meinem ZFS Desktoprechner und "sudo" hatte ich ich übersehen.
Für Proxmox ist bei der Ausführung als root, sudo, nicht notwendig und "sudo" ist nicht auf allen Promox VE nachträglich installiert worden.
Ich bin nicht davon überzeugt dass
apt list '~c' andere Werte liefert als dpkg -l | grep "^rc". Ich kann es jedenfalls nicht reproduzieren. Ich sehe daher keinen guten Grund Dinge komplizierter zu machen. Ohne ^ ist das Snippet ohnehin gefährlich.
Last edited:
Moin, der Weg ist das Ziel. Egal wie man die "Reste" aus seinen Systemen entfernen kann: "alle Wege führe nach Rom".
Quelle der APT Optionen:
# https://www.debian.org/doc/manuals/debian-reference/ch02.de.html
Unter "2.2.7. Aptitudes Regex-Formel" finden wir:
"Treffer auf entfernte Pakete, deren Konfigurationsdateien aber noch vorhanden sind ~c"
Die Google KI bestätigt das auch mit dem Suchausdruck: "was bedeutet debian apt list '~c'"
Dann sollte doch alles geklärt sein.
Zu 'dpkg -l' und der weiteren Auswahl im Script:
# https://wiki.ubuntuusers.de/dpkg/
Unter "Kommandozeilenoptionen zu dpkg" finden wir für:
Die Optionen '-l' oder '--list':
"Ruft dpkg-query auf und gibt eine Liste mit Status, Version und einer Kurzbeschreibung des Pakets aus. Statt des Namens kann auch ein regulärer Ausdruck angegeben werden. Wird kein Argument übergeben, werden alle installierten Pakete aufgelistet. Diese Option ist auch für unprivilegierte Nutzer verfügbar."
Nutzt man nur "dpkg -l", kann man noch feiner die zu löschenden Paket über 'apt purge -y <paket>' auswählen.
# https://www.debian.org/doc/manuals/debian-reference/ch02.de.html
Unter "2.2.7. Aptitudes Regex-Formel" finden wir:
"Treffer auf entfernte Pakete, deren Konfigurationsdateien aber noch vorhanden sind ~c"
Die Google KI bestätigt das auch mit dem Suchausdruck: "was bedeutet debian apt list '~c'"
Dann sollte doch alles geklärt sein.
Zu 'dpkg -l' und der weiteren Auswahl im Script:
# https://wiki.ubuntuusers.de/dpkg/
Unter "Kommandozeilenoptionen zu dpkg" finden wir für:
Die Optionen '-l' oder '--list':
"Ruft dpkg-query auf und gibt eine Liste mit Status, Version und einer Kurzbeschreibung des Pakets aus. Statt des Namens kann auch ein regulärer Ausdruck angegeben werden. Wird kein Argument übergeben, werden alle installierten Pakete aufgelistet. Diese Option ist auch für unprivilegierte Nutzer verfügbar."
Nutzt man nur "dpkg -l", kann man noch feiner die zu löschenden Paket über 'apt purge -y <paket>' auswählen.
Last edited:
Ein grep ^rc ist sicherlich eleganter als grep "rc ". Noch sicherer ist grep "^rc ".
Allerdings ist eine einzeilige Schleife auch kein kompliziertes Hexenwerk.
Dpkg ist auch näher an der Aufgabe dran, denn apt baut ja auch darauf auf.
So bin ich in meinem Leben noch nicht über einen ominösen Parameter '~c' für apt gestolpert. Selbst man kennt es nicht.
systemctl list-units --type=service
da werden Server Dienste geprüft online sind oder offline sind
dieser geht bei Debian oder Ubuntu
apt install htop
htop aufrufen und prüfen was da lost ist im System
da werden Server Dienste geprüft online sind oder offline sind
dieser geht bei Debian oder Ubuntu
apt install htop
htop aufrufen und prüfen was da lost ist im System
Genau!
Wie schaut es mit der Speicherkapazität aus und und laufen die "fehlenden" VMs wieder?
Update eingespielt?
Moin,
Die 64 GB im /mnt sind nun weg, da lagen einige Backups, die eigenlich auf die USB-Festplatte gehören - wo sie auch sind.. Leider hat das aber nicht ein dem Problem mit dem nicht sprechen VM geändert.
Wundert mich auch nicht, da die andere VM auf dem anderen Proxmx PVE das Platzprojekt nicht hat.
Was ich noch versucht habe: die VM-Platte der nicht erreichbaren VM (MariaDB) an eine andere VM anzudocken und so zumindest an die Datenbankdateien zu kommen und zu sichern. Die VM neu anzulegen ist ja kein Hexenwerk.
Die 64 GB im /mnt sind nun weg, da lagen einige Backups, die eigenlich auf die USB-Festplatte gehören - wo sie auch sind.. Leider hat das aber nicht ein dem Problem mit dem nicht sprechen VM geändert.
Wundert mich auch nicht, da die andere VM auf dem anderen Proxmx PVE das Platzprojekt nicht hat.
Der Speicher ist frei, die VMen laufen (was sie immer taten) aber die betroffenen VMen sind nach wie vor nicht erreichbar.
Was ich noch versucht habe: die VM-Platte der nicht erreichbaren VM (MariaDB) an eine andere VM anzudocken und so zumindest an die Datenbankdateien zu kommen und zu sichern. Die VM neu anzulegen ist ja kein Hexenwerk.
Last edited:
D.h. auch via Proxmox VM Konsole kommst du aktuell nach dem putzen trotzdem leider nicht weiter.
Die Meldung in deinem ersten Post mit SSH "no route to host" deutet ja auf ein Netzwerkproblem oder aktiver Firewall in deiner VM hin.
Hast vielleicht plötzlich eine doppelte MAC- oder IP-Adresse?
Du könntest mit einem Livesystem (bsp Linux Mint / Parted Magic, oder andere) die VM via ISO booten und dann mal die Platte einhängen und ggf. die gewünschten Dateien manuell rausziehen - wenn das neu aufsetzen kein Hexenwerk ist.
Last edited:
Ich habe nochmal einen angestrengten Blick auf dein Hardware-Lsiting geworfen. Dabei fiel mir die Zeile
als seltsam ins Auge.
In einer Standardumgebung sollte das
heißen.
Also per WebGUI mal prüfen, ob auf local-lvm->VM disks tatsächlich eine vm102.disk-0 liegt und falls ja, die Konfiguration von /etc/pve/qemu-server/102.conf per CLI mal testhalber ändern.
Code:
Laufwerk (scsi0) local.vm:vm102.disk-0,size=100GBIn einer Standardumgebung sollte das
Code:
Laufwerk (scsi0) local-vm:vm102.disk-0,size=100GBAlso per WebGUI mal prüfen, ob auf local-lvm->VM disks tatsächlich eine vm102.disk-0 liegt und falls ja, die Konfiguration von /etc/pve/qemu-server/102.conf per CLI mal testhalber ändern.
Last edited:
Unerquicklich.
Vergleiche, ob beide PVEs über identische storages verfügt.
Dann würde ich eine Sicherung auf dem alten 8er-PVE vornehmen.
Diese in eine Test-VM auf dem UrsprungsPVE zurückspielen.
Falls es dort funktioniert, die Sicherung der VM auf den 9er-PVE wiederherstellen.
Falls es dort immer noch nicht funktioniert, die Test-VM auf dem UsprungsPVE updaten.
Dann o.g. Kreislauf wiederholen.
Ich habe es nun endlich geschafft mittels Live-System den Ordner /var/lib/mysql von der VM zu sichern, ich hoff das reicht nun um den Server neu aufzubauen. (Warum das bei früheren Versuchen nicht gelungen ist? Fragt bitte nicht. Muß an mangelnder Geduld oder wiederholende Fehler meinerseits liegen).
An den Versuch das Backup auf dem 8er-PVE einzuspielen hatte ich auch schon gedacht, leider ist aber die Gesamtgröße des zur Verfügung stehenden Platzes nicht ausreichend ist. Da die MariaDB-VM leider 100GB groß ist. Normalerweise kein Problem, aber in diesem speziellen Fall doch da nur noch 46 GB von 128GB übrig sind. Das heißt das selbst wenn ich von der Maschine alle VMen löschen würde, mir das ich nicht helfen könnte.
Ich werde jetzt erst einmal auf der 8er-PVE die VM komplett neu aufbauen und dann hoffentlich die DB ans Laufen zu bekommen. Wenn das alles läuft werde ich mir die kaputte VM irgendwann noch mal anschauen.
Erst mal allen herzlichen Dank und ich werde mich noch mal melden wenn es denn funktioniert.
Gruß
chralt
An den Versuch das Backup auf dem 8er-PVE einzuspielen hatte ich auch schon gedacht, leider ist aber die Gesamtgröße des zur Verfügung stehenden Platzes nicht ausreichend ist. Da die MariaDB-VM leider 100GB groß ist. Normalerweise kein Problem, aber in diesem speziellen Fall doch da nur noch 46 GB von 128GB übrig sind. Das heißt das selbst wenn ich von der Maschine alle VMen löschen würde, mir das ich nicht helfen könnte.
Ich werde jetzt erst einmal auf der 8er-PVE die VM komplett neu aufbauen und dann hoffentlich die DB ans Laufen zu bekommen. Wenn das alles läuft werde ich mir die kaputte VM irgendwann noch mal anschauen.
Erst mal allen herzlichen Dank und ich werde mich noch mal melden wenn es denn funktioniert.
Gruß
chralt
Schön, dass du die wichtigen Daten sichern konntest. Ich würde die neue VM aber gleich auf dem neuen 9er aufbauen.Ich habe es nun endlich geschafft mittels Live-System den Ordner /var/lib/mysql von der VM zu sichern, ich hoff das reicht nun um den Server neu aufzubauen. (Warum das bei früheren Versuchen nicht gelungen ist? Fragt bitte nicht. Muß an mangelnder Geduld oder wiederholende Fehler meinerseits liegen).
An den Versuch das Backup auf dem 8er-PVE einzuspielen hatte ich auch schon gedacht, leider ist aber die Gesamtgröße des zur Verfügung stehenden Platzes nicht ausreichend ist. Da die MariaDB-VM leider 100GB groß ist. Normalerweise kein Problem, aber in diesem speziellen Fall doch da nur noch 46 GB von 128GB übrig sind. Das heißt das selbst wenn ich von der Maschine alle VMen löschen würde, mir das ich nicht helfen könnte.
Ich werde jetzt erst einmal auf der 8er-PVE die VM komplett neu aufbauen und dann hoffentlich die DB ans Laufen zu bekommen. Wenn das alles läuft werde ich mir die kaputte VM irgendwann noch mal anschauen.
Erst mal allen herzlichen Dank und ich werde mich noch mal melden wenn es denn funktioniert.
Gruß
chralt
Wäre schon ein erster Grund über Kapazitätserweiterungen nachzudenken. Lieber zuviel als zu wenig Plattenspeicher im System.