ubuntuusers.de

der KVM-Server ist erfolgreich eingerichtet und läuft eigentlich problemlos. Starte ich aber den virt-manager gibt's alle 3 Sekunden in syslog:

kernel: [141559.341820] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7

Wie kann ich das beheben?

Unbekannt ist das nicht, allerdings zuvorderst vor einem Jahr in älterer Version...Ubuntu like.

Aktuell ist 9.0.0 und nicht 8.0.0 (Jammy) oder 8.6.0 (Kinetic, Lunar). Du kannst ja suchen, ob Du diese gesamte Virtualisierungssache in aktuellen Paketen bekommst. Ich würde allerdings die Distribution ersetzen.

Hmm, ich möchte eigentlich nicht weg von den LTS-Versionen und die Installation von virt-manager_4.1.0-2_all.deb scheitert:

Die folgenden Pakete haben unerfüllte Abhängigkeiten: virt-manager : Hängt ab von: virtinst (= 1:4.1.0-2) aber 1:4.0.0-1 soll installiert werden

Ich habe nicht grundlos geschrieben:

diese gesamte Virtualisierungssache in aktuellen Paketen bekommst.

Du kannst i.d.R. nicht irgendein einzelnes Paket aus Lunar installieren - das weißt Du doch (Du bist doch der mit den damaligen SANE-PPA-Paketen).

Ich würde allerdings die Distribution ersetzen.

Ich habe nicht Distributionsversion geschrieben.

von.wert schrieb:

Ich habe nicht grundlos geschrieben:

diese gesamte Virtualisierungssache in aktuellen Paketen bekommst.

Hmmm. Welche Pakete meinst Du mit "aktuell ist 9.0.0 und nicht 8.0.0..."? Offenbar nicht den virt-manager.

Du kannst i.d.R. nicht irgendein einzelnes Paket aus Lunar installieren - das weißt Du doch (Du bist doch der mit den damaligen SANE-PPA-Paketen).

Nein, das ist eine Verwechslung.

Ich würde allerdings die Distribution ersetzen.

Ich habe nicht Distributionsversion geschrieben.

Wenn nicht die Distribution und auch nicht Pakete aus neueren Distri-Versionen - was dann? Server und Clients wurden hier (bevor ich im Forum poste) natürlich aktualisiert. "virt-manager_4.1.0-2_all.deb" enthält "_all" und wurde ohne Verweis auf eine Distribution angeboten (ich glaube, es war bei virt-manager.org)

Ich weiß auch nicht, ob das das richtige Ende ist über das wir hier schreiben. Der Server bootet mit UEFI. Auf einem anderen (älteren) KVM-Server, der mit BIOS startet, erzeugt der gleiche virt-manager dieses Problem nicht. Die Fehlermeldung aus dem 1. Posting verweist m.E. auf ein Sicherheitsfeature (kernel_lockdown) des aktuellen Kernels und hier auf eine Zugriffsbeschränkung von debugfs. Die Kernfrage ist daher: wie kann man das erlauben?

Den virt-manager gibts z.B. hier in der Version 4.1.0-2:

https://launchpad.net/~savoury1/+archive/ubuntu/virtualisation

Dort liegen auch qemu 7.2.0 und libvirt 8.10.0, also 9.0.0 noch nicht.

Fremdquellen <-lesen

verdooft schrieb:

Den virt-manager gibts z.B. hier in der Version 4.1.0-2:

https://launchpad.net/~savoury1/+archive/ubuntu/virtualisation

Dort liegen auch qemu 7.2.0 und libvirt 8.10.0, also 9.0.0 noch nicht.

Fremdquellen <-lesen

Danke für die Infos. Leider führt das noch nicht zum Ergebnis. Installiert ist jetzt:

1
2
3
4
5
6
7

IBK-KVM-Host (/) # kvm --version
QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.6)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
IBK-KVM-Host (/) # virt-manager --version
4.1.0
IBK-KVM-Host (/) # libvirtd --version
libvirtd (libvirt) 8.10.0

Die Fehlermeldung bleibt. Qemu liefert noch eine Version 6.2.0. Weshalb das so ist, kann ich nicht feststellen. Das Update (auf dem Server und Client) lief ohne Fehlermeldung durch. Es gibt auch keine zurückgehaltenen Pakete.

Seltsam, ich habe eben mal geschaut, wo die /bin/kvm liegt, da kommt raus:

apt-file search /bin/kvm
[...}
qemu-system-x86: /usr/bin/kvm

Abfrage der Paketversionen:

apt-cache policy qemu-system-x86
qemu-system-x86:
  Installiert:           (keine)
  Installationskandidat: 1:7.2+dfsg-1ubuntu0~22.04.sav0
  Versionstabelle:
     1:7.2+dfsg-1ubuntu0~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/virtualisation/ubuntu jammy/main amd64 Packages

Was bringt denn:

which kvm

Hier siehts so aus, als hätte das was mit qemu zu tun, drum besteht die Chance, dass mit der neueren Version in Kombination mit dem Virtmanager der Fehler nicht mehr auftritt: https://gitlab.com/libvirt/libvirt/-/issues/213

verdooft schrieb:

Seltsam, ich habe eben mal geschaut, wo die /bin/kvm liegt, da kommt raus:

apt-file search /bin/kvm
[...}
qemu-system-x86: /usr/bin/kvm

Hier identisch

Abfrage der Paketversionen:

apt-cache policy qemu-system-x86
qemu-system-x86:
  Installiert:           (keine)
  Installationskandidat: 1:7.2+dfsg-1ubuntu0~22.04.sav0
  Versionstabelle:
     1:7.2+dfsg-1ubuntu0~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/virtualisation/ubuntu jammy/main amd64 Packages

Hier wird's vielleicht interessant:

IBK-KVM-Host (/) # apt-cache policy qemu-system-x86
qemu-system-x86:
  Installiert:           1:6.2+dfsg-2ubuntu6.6
  Installationskandidat: 1:7.2+dfsg-1ubuntu0~22.04.sav0
  Versionstabelle:
     1:7.2+dfsg-1ubuntu0~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/virtualisation/ubuntu jammy/main amd64 Packages
 *** 1:6.2+dfsg-2ubuntu6.6 500
        500 http://de.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1:6.2+dfsg-2ubuntu6 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

Da frage ich mich, weshalb wird der "Installationskandidat" nicht installiert? Kann man das forcieren?

Was bringt denn:

which kvm

/usr/bin/kvm

Hier siehts so aus, als hätte das was mit qemu zu tun, drum besteht die Chance, dass mit der neueren Version in Kombination mit dem Virtmanager der Fehler nicht mehr auftritt: https://gitlab.com/libvirt/libvirt/-/issues/213

Das hatte ich auch schon gefunden. Am Ende heißt es: "...but work is now needed on the libvirt side to use the new QEMU APIs..."

Nebenbei frage ich mich zunehmend weshalb man nicht einfach rpc-libvirtd für debugfs berechtigt. Besonderes Bauchweh hätte ich damit nicht.

Ich update Pakete so:

sudo apt dist-upgrade

oder

udo apt install paketname

oder

sudo apt remove paketname
sudo apt autoremove
sudo apt install paketname

Den letzten Fall verwende ich, wenn ich weiß oder annehme, dass Pakete anders gebaut wurden als die installierten, oder wenn Pakete anders heißen.

verdooft schrieb:

sudo apt install paketname

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

IBK-KVM-Host (/) # apt install qemu-system-x86
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 qemu-system-common : Hängt ab von: libsndio7 (>= 1.8.1) ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

IBK-KVM-Host (/) # apt-get install libsndio7.0
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Vorgeschlagene Pakete:
  sndiod
Die folgenden NEUEN Pakete werden installiert:
  libsndio7.0
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.
Es müssen 29,3 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 90,1 kB Plattenplatz zusätzlich benutzt.
Holen:1 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 libsndio7.0 amd64 1.8.1-1.1 [29,3 kB]
Es wurden 29,3 kB in 0 s geholt (244 kB/s).
Vormals nicht ausgewähltes Paket libsndio7.0:amd64 wird gewählt.
(Lese Datenbank ... 188585 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libsndio7.0_1.8.1-1.1_amd64.deb ...
Entpacken von libsndio7.0:amd64 (1.8.1-1.1) ...
libsndio7.0:amd64 (1.8.1-1.1) wird eingerichtet ...
Trigger für libc-bin (2.35-0ubuntu3.1) werden verarbeitet ...

IBK-KVM-Host (/) # apt list libsndio7*
Auflistung… Fertig
libsndio7.0/jammy,now 1.8.1-1.1 amd64  [installiert]
libsndio7.0/jammy 1.8.1-1.1 i386

IBK-KVM-Host (/) # apt install qemu-system-x86
...
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 qemu-system-common : Hängt ab von: libsndio7 (>= 1.8.1) ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Die Version von libsndio7 passt jetzt, qemu-system-x68 lässt sich weiterhin nicht installieren. Dann eben die harte Tour:

...

sudo apt remove paketname
sudo apt autoremove
sudo apt install paketname

Den letzten Fall verwende ich, wenn ich weiß oder annehme, dass Pakete anders gebaut wurden als die installierten, oder wenn Pakete anders heißen.

Die Deinstallation erfolgte problemlos, bei der Installation aber weiterhin:

1
2
3
4
5

IBK-KVM-Host (/) # apt install qemu-system-x86
...
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 qemu-system-common : Hängt ab von: libsndio7 (>= 1.8.1) ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Musste daraufhin die Paketquelle löschen damit ich qemu-system-x86 wieder auf den Server bekomme. Bin also aktuell wieder beim Ausgangspunkt.

Ja, aus der PPA Beschreibung:

Note for all: This PPA depends on ppa:savoury1/ffmpeg4 for all series. For a successful install all users therefore need to do the following steps:

  sudo add-apt-repository ppa:savoury1/ffmpeg4
  sudo add-apt-repository ppa:savoury1/virtualisation
  sudo apt-get update
  sudo apt-get upgrade && sudo apt-get dist-upgrade

Ob man sich das System mit PPAs zupflastern möchte, muss man selbst entscheiden, libsndio7 gibts in dem ffmpeg4 PPA jedenfalls in einer geforderten aktuelleren Version, warum das mit der 1.8.1 von Buntu direkt nicht funktioniert, weiß ich nicht, vielleicht weils nur libsndio7.0 in den Paketquellen gibt und nicht libsndio7:

apt-cache policy libsndio7
libsndio7:
  Installiert:           1.9.0-0.3~22.04.sav0
  Installationskandidat: 1.9.0-0.3~22.04.sav0
  Versionstabelle:
 *** 1.9.0-0.3~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/ffmpeg4/ubuntu jammy/main amd64 Packages
        500 https://ppa.launchpadcontent.net/savoury1/multimedia/ubuntu jammy/main amd64 Packages
        500 https://ppa.launchpadcontent.net/savoury1/vlc3/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

multimedia und vlc3 Fremdquellen wirst du nicht brauchen, ich habe nur die Ausgabe bei mir vollständig gepostet.

verdooft schrieb:

Ja, aus der PPA Beschreibung:

Note for all: This PPA depends on ppa:savoury1/ffmpeg4 for all series. For a successful install all users therefore need to do the following steps:

  sudo add-apt-repository ppa:savoury1/ffmpeg4
  sudo add-apt-repository ppa:savoury1/virtualisation
  sudo apt-get update
  sudo apt-get upgrade && sudo apt-get dist-upgrade

... und ich habe das geflissentlich überlesen ☹

Die Installation lief jetzt erfolgreich:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

IBK-KVM-Host (/) # apt-cache policy libsndio7
libsndio7:
  Installiert:           1.9.0-0.3~22.04.sav0
  Installationskandidat: 1.9.0-0.3~22.04.sav0
  Versionstabelle:
 *** 1.9.0-0.3~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/ffmpeg4/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

IBK-KVM-Host (/) # apt-cache policy qemu-system-x86
qemu-system-x86:
  Installiert:           1:7.2+dfsg-1ubuntu0~22.04.sav0
  Installationskandidat: 1:7.2+dfsg-1ubuntu0~22.04.sav0
  Versionstabelle:
 *** 1:7.2+dfsg-1ubuntu0~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/virtualisation/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status
     1:6.2+dfsg-2ubuntu6.6 500
        500 http://de.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
     1:6.2+dfsg-2ubuntu6 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

IBK-KVM-Host (/) # apt-cache policy virt-manager
virt-manager:
  Installiert:           1:4.1.0-2~22.04.sav0
  Installationskandidat: 1:4.1.0-2~22.04.sav0
  Versionstabelle:
 *** 1:4.1.0-2~22.04.sav0 500
        500 https://ppa.launchpadcontent.net/savoury1/virtualisation/ubuntu jammy/main amd64 Packages
        500 https://ppa.launchpadcontent.net/savoury1/virtualisation/ubuntu jammy/main i386 Packages
        100 /var/lib/dpkg/status
     1:4.0.0-1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        500 http://de.archive.ubuntu.com/ubuntu jammy/universe i386 Packages

Jedoch bleibt das Problem:

1

Feb 21 08:49:37 IBK-KVM-Host kernel: [80909.762598] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7

Muss ich damit leben oder gibt's noch einen Tipp?

Rolf_Bensch schrieb:

Jedoch bleibt das Problem:

1	Feb 21 08:49:37 IBK-KVM-Host kernel: [80909.762598] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7

Muss ich damit leben oder gibt's noch einen Tipp?

Kommando zurück: nach Neustart des Server bleibt die Fehlermeldung aus. 👍 Weltklasse!!!!!

Vielen Dank für die Unterstützung!!!

Rolf_Bensch schrieb:

... nach Neustart des Server bleibt die Fehlermeldung aus.