Kernel panic VFS: Unable to mount root fs on unknown-block (0,0) sobald ein 7.x Kernel verwendet wird.

Hmmm... eigentlich sollte eins die Ausgabe vom 7.x kernel sein. Hier nochmal alles hintereinander inkl. aktivem Kernel

Code: 
root@Raylane:~# uname -r
7.0.6-2-pve
root@Raylane:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-7.0.6-2-pve root=/dev/mapper/pve-root ro quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction nofb nomodeset video=vesafb:off,efifb:off
root@Raylane:~# dmesg | grep -i iommu
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-7.0.6-2-pve root=/dev/mapper/pve-root ro quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction nofb nomodeset video=vesafb:off,efifb:off
[    0.000000] Warning: PCIe ACS overrides enabled; This may allow non-IOMMU protected peer-to-peer DMA
[    0.045240] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-7.0.6-2-pve root=/dev/mapper/pve-root ro quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction nofb nomodeset video=vesafb:off,efifb:off
[    0.487747] iommu: Default domain type: Passthrough (set via kernel command line)
[    0.561768] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
[    0.561859] pci 0000:00:01.0: Adding to iommu group 0
[    0.561877] pci 0000:00:01.1: Adding to iommu group 1
[    0.561915] pci 0000:00:02.0: Adding to iommu group 2
[    0.561933] pci 0000:00:02.1: Adding to iommu group 3
[    0.561956] pci 0000:00:03.0: Adding to iommu group 4
[    0.561979] pci 0000:00:04.0: Adding to iommu group 5
[    0.562024] pci 0000:00:08.0: Adding to iommu group 6
[    0.562041] pci 0000:00:08.1: Adding to iommu group 7
[    0.562058] pci 0000:00:08.3: Adding to iommu group 8
[    0.562089] pci 0000:00:14.0: Adding to iommu group 9
[    0.562108] pci 0000:00:14.3: Adding to iommu group 9
[    0.562187] pci 0000:00:18.0: Adding to iommu group 10
[    0.562202] pci 0000:00:18.1: Adding to iommu group 10
[    0.562217] pci 0000:00:18.2: Adding to iommu group 10
[    0.562232] pci 0000:00:18.3: Adding to iommu group 10
[    0.562246] pci 0000:00:18.4: Adding to iommu group 10
[    0.562261] pci 0000:00:18.5: Adding to iommu group 10
[    0.562277] pci 0000:00:18.6: Adding to iommu group 10
[    0.562292] pci 0000:00:18.7: Adding to iommu group 10
[    0.562313] pci 0000:01:00.0: Adding to iommu group 11
[    0.562330] pci 0000:01:00.1: Adding to iommu group 12
[    0.562349] pci 0000:02:00.0: Adding to iommu group 13
[    0.562377] pci 0000:03:00.0: Adding to iommu group 14
[    0.562398] pci 0000:03:04.0: Adding to iommu group 15
[    0.562419] pci 0000:03:05.0: Adding to iommu group 16
[    0.562440] pci 0000:03:06.0: Adding to iommu group 17
[    0.562461] pci 0000:03:07.0: Adding to iommu group 18
[    0.562481] pci 0000:03:08.0: Adding to iommu group 19
[    0.562502] pci 0000:03:0c.0: Adding to iommu group 20
[    0.562524] pci 0000:03:0d.0: Adding to iommu group 21
[    0.562547] pci 0000:04:00.0: Adding to iommu group 22
[    0.562572] pci 0000:09:00.0: Adding to iommu group 23
[    0.562602] pci 0000:0a:00.0: Adding to iommu group 24
[    0.562633] pci 0000:0a:01.0: Adding to iommu group 25
[    0.562663] pci 0000:0a:02.0: Adding to iommu group 26
[    0.562694] pci 0000:0a:03.0: Adding to iommu group 27
[    0.562726] pci 0000:0a:04.0: Adding to iommu group 28
[    0.562757] pci 0000:0a:08.0: Adding to iommu group 29
[    0.562787] pci 0000:0a:0a.0: Adding to iommu group 30
[    0.562818] pci 0000:0a:0b.0: Adding to iommu group 31
[    0.562849] pci 0000:0a:0c.0: Adding to iommu group 32
[    0.562880] pci 0000:0a:0d.0: Adding to iommu group 33
[    0.562920] pci 0000:0e:00.0: Adding to iommu group 34
[    0.562956] pci 0000:10:00.0: Adding to iommu group 35
[    0.562988] pci 0000:13:00.0: Adding to iommu group 36
[    0.563020] pci 0000:14:00.0: Adding to iommu group 37
[    0.563041] pci 0000:15:00.0: Adding to iommu group 38
[    0.563061] pci 0000:16:00.0: Adding to iommu group 39
[    0.563089] pci 0000:17:00.0: Adding to iommu group 40
[    0.563108] pci 0000:17:00.1: Adding to iommu group 41
[    0.563125] pci 0000:17:00.2: Adding to iommu group 42
[    0.563144] pci 0000:17:00.3: Adding to iommu group 43
[    0.563162] pci 0000:17:00.4: Adding to iommu group 44
[    0.563180] pci 0000:17:00.6: Adding to iommu group 45
[    0.563197] pci 0000:18:00.0: Adding to iommu group 46
[    0.598090] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank).
root@Raylane:~#
 
OK, die IOMMU-Gruppen sind auf 6.x und 7.x identisch, ACS-Override greift auf beiden gleich. Meine Vermutung mit den geänderten Gruppen war falsch.

Aber: dmesg | grep -i vfio auf dem 7.x Kernel fehlt noch, poste das bitte auch mal. Mich interessiert ob vfio-pci da bindet.

Was ich jetzt testen würde: boot mal den 7.x Kernel ohne pcie_acs_override=downstream,multifunction in der Cmdline und versuch dann nur die RTX 4070 (01:00.0 + 01:00.1) durchzureichen. Die sitzt in einer eigenen nativen IOMMU-Gruppe, die braucht kein ACS-Override. Wenn das geht ohne Freeze, ist der ACS-Override-Patch im 7.x Kernel buggy. Die Gruppen können beim Booten identisch aussehen, aber der Patch fummelt an den PCI ACS Capability Bits rum, und wenn da was im neuen Kernel nicht stimmt, kracht's erst beim tatsächlichen Device Assignment.

Dafür in /etc/default/grub temporär das pcie_acs_override=downstream,multifunction rausnehmen, update-grub, in 7.x booten, und dann nur ne Test-VM mit der RTX starten. Wenn der Node stabil bleibt, wissen wir wo das Problem liegt.
 
So hier die Daten vom vfio:
Code: 
root@Raylane:~# uname -r
7.0.6-2-pve
root@Raylane:~# dmesg | grep -i vfio
[   12.161952] VFIO - User Level meta-driver version: 0.3
[   12.184064] vfio-pci 0000:17:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none
[   12.184155] vfio_pci: add [1002:164e[ffffffff:ffffffff]] class 0x000000/00000000
[   12.207563] vfio_pci: add [1002:1640[ffffffff:ffffffff]] class 0x000000/00000000
[   12.207652] vfio_pci: add [1022:15e3[ffffffff:ffffffff]] class 0x000000/00000000
[   12.207731] vfio_pci: add [1022:1649[ffffffff:ffffffff]] class 0x000000/00000000
[   12.207804] vfio_pci: add [1022:15b6[ffffffff:ffffffff]] class 0x000000/00000000
[   12.207876] vfio_pci: add [1022:15b7[ffffffff:ffffffff]] class 0x000000/00000000
[   12.252137] vfio-pci 0000:01:00.0: vgaarb: deactivate vga console
[   12.252149] vfio-pci 0000:01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none
[   12.252228] vfio_pci: add [10de:2786[ffffffff:ffffffff]] class 0x000000/00000000
[   12.299864] vfio_pci: add [10de:22bc[ffffffff:ffffffff]] class 0x000000/00000000
root@Raylane:~#
Mehr taucht hier einfach nicht auf.


und auch ohne pcie_acs_override=downstream,multifunction friert der Node ein. (Pop!OS VM wo nur noch die RTX gemapped weitergereicht wird.)

Inhalt Grub:
Code: 
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`( . /etc/os-release && echo ${NAME} )`
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt nofb nomodeset video=vesafb:off,efifb:off"
GRUB_CMDLINE_LINUX=""
 
Last edited:
OK, ACS-Override war's also nicht. Damit haben wir so ziemlich alles ausgeschlossen, was konfigurationsseitig schiefgehen könnte: IOMMU-Gruppen identisch, vfio-pci bindet sauber, alle Functions auf vfio-pci, kein ACS-Override, nur die RTX in eigener nativer Gruppe. Trotzdem Freeze. Das ist wahrscheinlich ein Bug im VFIO/KVM-Codepath vom 7.x Kernel auf AMD.

Der Node friert so hart ein, dass keine Logs mehr geschrieben werden. Du brauchst netconsole, um rauszufinden was los ist. Damit werden Kernel-Messages über Netzwerk an einen anderen Rechner geschickt, bevor der Node stirbt. Auf dem 7.x Kernel vor dem VM-Start:
Code: 
modprobe netconsole netconsole=@/,@<IP-deines-zweiten-Rechners>/
Auf dem zweiten Rechner dann nc -u -l 6666 und gucken was beim VM-Start rauskommt. So siehst du den eigentlichen Crash oder Oops.

Ich würd das als Bug im PVE-Bugtracker melden (https://bugzilla.proxmox.com). Du hast ja alle Infos: Hardware, beide Kernel-Versionen, dmesg/cmdline/iommu von beiden, und dass es mit 6.x geht und mit 7.x bei jedem Passthrough knallt. Das reicht für einen Bug-Report.

Auf dem 6.x Kernel bleiben ist bis dahin völlig OK, einfach pragmatisch.
 
so ich hab auf einem meiner Proxmox Server einen LXC Container als 2. PC erstellt und die IP nun in den modprobe eingeben:
Code: 
root@Raylane:~# modprobe netconsole netconsole=@/,@192.168.100.192/
root@Raylane:~#

auf dem "2. Rechner hab ich nun folgendes gemacht:

Code: 
root@Netconsole:~# nc -l -u -p 6666
ohne dem -p wollte der Befehl nicht.
Hier bekomme ich nun aber keine Output oder ähnliches. Wird die log in irgendeine Datei geschrieben? Und wenn ja wo müsste ich die suchen oder muss ich oben in dem Befehl mehr als nur die IPv4 Adresse hinterlegen?
 
Der nc Befehl ist okay. Das Problem ist vermutlich dass netconsole das Netzwerk-Interface nicht automatisch findet. Probier mal explizit mit Interface und MAC-Adresse vom Ziel:

Erstmal auf dem LXC die MAC rausfinden: ip link show eth0 (oder wie das Interface heißt), dann auf dem Raylane-Host:

Code: 
modprobe -r netconsole
modprobe netconsole netconsole=6666@/vmbr0,6666@192.168.100.192/AA:BB:CC:DD:EE:FF
(AA:BB:CC:DD:EE:FF durch die echte MAC ersetzen, und vmbr0 durch das Interface wo die 192.168.100.x drauf liegt)

Zum Testen ob überhaupt was ankommt, bevor du die VM startest:
Code: 
echo "netconsole test" > /dev/kmsg
Das sollte dann im nc auf dem LXC auftauchen. Wenn nichts kommt, stimmt was am Netzwerkpfad nicht.

Wenn der Test klappt, VM starten und schauen was rauskommt kurz bevor der Node einfriert.
 
über den befehl echo "Netconsole-Test" | nc -u 192.168.100.192 6666 bekomme ich die Nachricht Netconsole-Test am LXC mit dem Befehl
echo "netconsole test" &gt; /dev/kmsg über den Befehl kommt leider nix an. Vermutlich bekomme ich daher auch nichts angezeigt wenn der Node einfriert.

Ich hab nun folgendes eingegeben (Mac wurde durch xx:xx:xx:xx:xx:xx ersetzt):
Code: 
root@Raylane:~# modprobe -r netconsole
root@Raylane:~# modprobe netconsole netconsole=6666@192.168.100.80/vmbr0,6666@192.168.100.192/xx:xx:xx:xx:xx:xx

netconsole scheint aber zu funktionieren dmesg | grep -i netconsole wenn man dem Output trauen kann.
Code: 
root@Raylane:~# dmesg | grep -i netconsole
[   46.299088] netconsole: netconsole: local port 6666
[   46.299092] netconsole: netconsole: local IPv4 address 192.168.100.80
[   46.299095] netconsole: netconsole: interface name 'eth0'
[   46.299096] netconsole: netconsole: local ethernet address 'ff:ff:ff:ff:ff:ff'
[   46.299097] netconsole: netconsole: remote port 6666
[   46.299098] netconsole: netconsole: remote IPv4 address 192.168.100.192
[   46.299099] netconsole: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
[   46.299101] netpoll: netconsole: eth0 doesn't exist, aborting
[   46.299103] netconsole: Not enabling netconsole for cmdline0. Netpoll setup failed
[   46.299202] netconsole: network logging started
[  178.783172] netconsole test
[  480.095104] TEST NETCONSOLE
[ 1063.374397] TEST NETCONSOLE
[ 1075.806001] TEST NETCONSOLE
[ 1145.950173] netconsole: netconsole: local port 6666
[ 1145.950176] netconsole: netconsole: local IPv4 address 192.168.100.80
[ 1145.950178] netconsole: netconsole: interface name 'vmbr0'
[ 1145.950179] netconsole: netconsole: local ethernet address 'ff:ff:ff:ff:ff:ff'
[ 1145.950180] netconsole: netconsole: remote port 6666
[ 1145.950181] netconsole: netconsole: remote IPv4 address 192.168.100.192
[ 1145.950182] netconsole: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
[ 1145.967311] netconsole: network logging started
[ 1151.305612] TEST NETCONSOLE
[ 1180.375532] TEST NETCONSOLE
root@Raylane:~#


Beim Starten der VM kommt nun folgendes (blockiere ich nun irgendwie das Netzwerk?):
Code: 
RTNETLINK answers: Unknown error 524
can't enslave 'fwpr101p0' to 'vmbr0'
kvm: -netdev type=tap,id=net0,ifname=tap101i0,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on: network script /usr/libexec/qemu-server/pve-bridge failed with status 512
TASK ERROR: start failed: QEMU exited with code 1
 
Ja, genau das ist das Problem. Netconsole auf vmbr0 blockiert die Bridge-Operationen, deswegen kann QEMU kein tap-Device mehr an die Bridge hängen. Netconsole/netpoll funktioniert nicht mit Bridge-Port-Änderungen.

Du musst netconsole auf das physische Interface setzen, nicht auf die Bridge. Schau mal mit ip link wie dein Realtek-NIC (0e:00.0) heißt, vermutlich sowas wie enp14s0. Dann:

Code: 
modprobe -r netconsole
modprobe netconsole netconsole=6666@192.168.100.80/enp14s0,6666@192.168.100.192/xx:xx:xx:xx:xx:xx
(enp14s0 durch den echten Interface-Namen ersetzen)

Danach nochmal mit echo "test" > /dev/kmsg checken ob's beim LXC ankommt, und dann VM starten. Die Bridge sollte dann wieder normal funktionieren und du bekommst trotzdem die Kernel-Messages mit.
 
Kann es sein das mein Netzwerkadapter nicht angezeigt wird (onboard chip) wegen den vfio einstellungen? Die sehen nämlich alle irgendwie nicht nach dem Physischem Interface aus. Laut Hersteller Seite hat das ASROCK X670E PG Lightning ein Dragon 2,5GbE Networking Anschluss... hört sich auch mehr nach Marketing als alles andere an.

Code: 
root@Raylane:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enx9c6b0031e1ee
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: fwbr103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: fwpr103p0@fwln103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
7: fwln103i0@fwpr103p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
9: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
10: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
11: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

USB-Serial Wandler besitze ich leider nicht.
 
Last edited:
Dein physisches Interface ist nic0 (das mit master vmbr0 in der Ausgabe, altname enx9c6b0031e1ee). Das ist dein Realtek 2.5GbE. Ist nicht von vfio versteckt, PVE bennent das manchmal um.

Also:
Code: 
modprobe -r netconsole
modprobe netconsole netconsole=6666@192.168.100.80/nic0,6666@192.168.100.192/xx:xx:xx:xx:xx:xx
Dann wieder echo "test" > /dev/kmsg und schauen ob's ankommt. Wenn ja, VM starten und den Output vom LXC posten, der kurz vor dem Freeze kommt.
 
You must log in or register to reply here.
Top Bottom
Back