macvlan call traces found via FixProblems Plugin

See the 6.12.4 release notes, you can use ipvlan to get rid of those or if you really want/need macvlan disable bridging for eth0.

I have seen the release notes. IPVLAN as i mentioned doesn't work for my use case.

 

These are the differences between IPvlan and MacVLAN:

 

The MacVLAN network allocates a unique MAC address to every container. Thus, a single network interface on a Docker host essentially advertises multiple MAC addresses. With an IPvlan network, all containers on a Docker host share a single MAC address.

A MacVLAN network requires you to enable promiscuous mode on the parent interface of the Docker host, which is not required with IPvlan.

In addition to the above two distinctions, IPvlan can work in two modes: L2 mode and L3 mode.

L2 (or Layer 2) mode is the default mode for IPvlan. It works just like MacVLAN (bridge) mode but without assigning a unique MAC address to each container. In L2 mode, the Docker host acts like a switch between the parent interface and a virtual NIC for each container. The entire communication is based only on MAC addresses. The containers in one IPvlan network (in L2 mode) can communicate with the containers in another IPvlan network. However, this generates many ARP broadcasts, which affects network performance.

In L3 (or Layer 3) mode, the Docker host works like a Layer 3 device to route the packets between the parent interface and the virtual NIC for each container. In this mode, containers are totally isolated from other networks, and the broadcasts are restricted to the Layer 2 subnet only; this improves network performance. The only downside is that you need to manually add a static route on your gateway router to let other network devices know how to reach your IPvlan network running in L3 mode.

I have multiple docker with different ip address and extra parm defined mac address

 

nextcloud:

--mac-address 02:42:C0:A8:--:-- --hostname NEXTCLOUD-DOCKER

 

Pihole:

--mac-address 02:42:C0:A8:--:-- --hostname PIHOLEDOHDOT

 

etc

 

that what macvlan is supposed to do older unraid releases had no issues with this. Same hardware on other Linux systems don't have errors in dmesg log with macvlan network..

 

https://docs.docker.com/network/drivers/macvlan/

 

Issues still exists and a move to ipvlan doesn't fix nor help the use case.

 

My current network setup requires IP and mac separation for nat port forwarding...

even folwoing hte release info:

https://docs.unraid.net/unraid-os/release-notes/6.12.4/

 

Has not fixed this issue:

 

Fix for macvlan call traces

The big news in this release is that we have resolved issues related to macvlan call traces and crashes!

The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel issue and have posted a bug report.

If you are getting call traces related to macvlan, as a first step we recommend navigating to Settings > Docker, switch to advanced view, and change the "Docker custom network type" from macvlan to ipvlan. This is the default configuration that Unraid has shipped with since version 6.11.5 and should work for most systems. If you are happy with this setting, then you are done! You will have no more call traces related to macvlan and can skip ahead to the next section.

However, some users have reported issues with port forwarding from certain routers (Fritzbox) and reduced functionality with advanced network management tools (Ubiquity) when in ipvlan mode.

For those users, we have a new method that reworks networking to avoid issues with macvlan. Tweak a few settings and your Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them:

Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work with this solution

Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)

Settings > Docker > Host access to custom networks = Enabled

Note: if you previously used the 2-nic docker segmentation method, you will also want to revert that:

Settings > Docker > custom network on interface eth0 or bond0 (i.e. make sure eth0/bond0 is configured for the custom network, not eth1/bond1)

When you Start the array, the host, VMs, and Docker containers will all be able to communicate, and there should be no more call traces!

Changed Status to Retest

i'm in testing stage as i think i have found a solution.

 

 

 

As I have different web gui options after removing the flash drive and deleting the config > network.conf file

 

This way I started over with the entire network setup.

 

boot no longer shows a trace error. Following release notes for macvlan setup and settings.

 

Still unknown why the error and call trace at boot.

Is there an issues with webui in place upgrade that changes the network config?

 

example of missing setting:

I was able to chose ipvlan and macvlan within docker setting.

 

 

 

 

Edited November 27, 2023 by bmartino1

11 hours ago, bmartino1 said:

I have seen the release notes. IPVLAN as i mentioned doesn't work for my use case.

Please reread what I posted, you can still use macvlan with 6.12.4

11 hours ago, JorgeB said:

Please reread what I posted, you can still use macvlan with 6.12.4

I don't understand the disconnect... I appreciate your willingness to help BUT please read my entire comments... Trace is still happening even after bridging is off after a upgrade.

 

This ATM only is affected from UNRAID os IN-PLACE Upgrade between revisions...

The latest versions has removed or is not parsing the network config as it should from upgrade.

 

If i remove the network config and start over after the upgrade and have bridging off as per suggestion and release notes it uses macvlan without the error. THIS IS ONLY AFTER I DELETE THE NETWORK CONFIG FILE AS I WAS STILL HAVING ERRORS BY JUST TURNING OFF BRIDGING...

 

And other before options seem to be missing in GUI from the changes. Previous Docker GUi allowed me to choose ipvlan or maclan for driver... attempted to reach out to a friend to get a picture of this... Comments have the new GUI options. With no clear info on what the actual driver option is for docker network.

 

Regardless I shouldn't have to delete my network config from a previous unraid version.

 

Regardless This will need to be retested...

 

 

 

Here is an example of the gui option that is now missing. This is a upgraded Unraid form version 6.9 > latest 6.12.4.

Their setting is bond yes bridge no. They also have the error under fix plugin macvlan traces found.

 

I bet if i deleted the network config to fix the issue it would indeed work the question is what changed in the old network config and new upgrade to change the gui options...

 

 

 

Nov 28 14:16:51 TheFang kernel: ------------[ cut here ]------------
Nov 28 14:16:51 TheFang kernel: WARNING: CPU: 28 PID: 24859 at net/netfilter/nf_conntrack_core.c:1210 __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Nov 28 14:16:51 TheFang kernel: Modules linked in: xt_nat xt_tcpudp veth nvidia_uvm(PO) macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype br_netfilter xfs dm_crypt dm_mod md_mod zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) tcp_diag inet_diag ipmi_devintf hwmon_vid wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha ip6table_filter ip6_tables iptable_filter ip_tables x_tables af_packet 8021q garp mrp bridge stp llc e1000e igb intel_rapl_msr intel_rapl_common iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp nvidia_drm(PO) nvidia_modeset(PO) kvm_intel kvm nvidia(PO) crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel sha512_ssse3 aesni_intel crypto_simd cryptd mgag200 video drm_shmem_helper drm_kms_helper ipmi_ssif rapl intel_cstate drm isci nvme mpt3sas
Nov 28 14:16:51 TheFang kernel: i2c_i801 mei_me i2c_smbus i2c_algo_bit backlight ahci syscopyarea input_leds sysfillrect sysimgblt intel_uncore libsas libahci mei nvme_core joydev led_class fb_sys_fops i2c_core raid_class scsi_transport_sas acpi_ipmi wmi ipmi_si button unix [last unloaded: e1000e]
Nov 28 14:16:51 TheFang kernel: CPU: 28 PID: 24859 Comm: kworker/u66:12 Tainted: P           O       6.1.49-Unraid #1
Nov 28 14:16:51 TheFang kernel: Hardware name: Supermicro X9DR7/E-(J)LN4F/X9DR7/E-(J)LN4F, BIOS 3.2  05/22/2015
Nov 28 14:16:51 TheFang kernel: Workqueue: events_unbound macvlan_process_broadcast [macvlan]
Nov 28 14:16:51 TheFang kernel: RIP: 0010:__nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Nov 28 14:16:51 TheFang kernel: Code: 44 24 10 e8 e2 e1 ff ff 8b 7c 24 04 89 ea 89 c6 89 04 24 e8 7e e6 ff ff 84 c0 75 a2 48 89 df e8 9b e2 ff ff 85 c0 89 c5 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 18 dd ff ff e8 93 e3 ff ff e9 72 01
Nov 28 14:16:51 TheFang kernel: RSP: 0018:ffffc90006a74d98 EFLAGS: 00010202
Nov 28 14:16:51 TheFang kernel: RAX: 0000000000000001 RBX: ffff8890cc1caf00 RCX: fcef0fb0d649d41c
Nov 28 14:16:51 TheFang kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8890cc1caf00
Nov 28 14:16:51 TheFang kernel: RBP: 0000000000000001 R08: d7eb5924399a04f2 R09: 64236f1799c3fd26
Nov 28 14:16:51 TheFang kernel: R10: 5ea7889a28d29ef2 R11: ffffc90006a74d60 R12: ffffffff82a11d00
Nov 28 14:16:51 TheFang kernel: R13: 000000000000885c R14: ffff88908a2bfc00 R15: 0000000000000000
Nov 28 14:16:51 TheFang kernel: FS:  0000000000000000(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000
Nov 28 14:16:51 TheFang kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 28 14:16:51 TheFang kernel: CR2: 000015284d3ad000 CR3: 000000000220a001 CR4: 00000000001706e0
Nov 28 14:16:51 TheFang kernel: Call Trace:
Nov 28 14:16:51 TheFang kernel: <IRQ>
Nov 28 14:16:51 TheFang kernel: ? __warn+0xab/0x122
Nov 28 14:16:51 TheFang kernel: ? report_bug+0x109/0x17e
Nov 28 14:16:51 TheFang kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Nov 28 14:16:51 TheFang kernel: ? handle_bug+0x41/0x6f
Nov 28 14:16:51 TheFang kernel: ? exc_invalid_op+0x13/0x60
Nov 28 14:16:51 TheFang kernel: ? asm_exc_invalid_op+0x16/0x20
Nov 28 14:16:51 TheFang kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Nov 28 14:16:51 TheFang kernel: ? __nf_conntrack_confirm+0x9e/0x2b0 [nf_conntrack]
Nov 28 14:16:51 TheFang kernel: ? nf_nat_inet_fn+0xc0/0x1a8 [nf_nat]
Nov 28 14:16:51 TheFang kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack]
Nov 28 14:16:51 TheFang kernel: nf_hook_slow+0x3d/0x96
Nov 28 14:16:51 TheFang kernel: ? ip_protocol_deliver_rcu+0x164/0x164
Nov 28 14:16:51 TheFang kernel: NF_HOOK.constprop.0+0x79/0xd9
Nov 28 14:16:51 TheFang kernel: ? ip_protocol_deliver_rcu+0x164/0x164
Nov 28 14:16:51 TheFang kernel: __netif_receive_skb_one_core+0x77/0x9c
Nov 28 14:16:51 TheFang kernel: process_backlog+0x8c/0x116
Nov 28 14:16:51 TheFang kernel: __napi_poll.constprop.0+0x2b/0x124
Nov 28 14:16:51 TheFang kernel: net_rx_action+0x159/0x24f
Nov 28 14:16:51 TheFang kernel: __do_softirq+0x129/0x288
Nov 28 14:16:51 TheFang kernel: do_softirq+0x7f/0xab
Nov 28 14:16:51 TheFang kernel: </IRQ>
Nov 28 14:16:51 TheFang kernel: <TASK>
Nov 28 14:16:51 TheFang kernel: __local_bh_enable_ip+0x4c/0x6b
Nov 28 14:16:51 TheFang kernel: netif_rx+0x52/0x5a
Nov 28 14:16:51 TheFang kernel: macvlan_broadcast+0x10a/0x150 [macvlan]
Nov 28 14:16:51 TheFang kernel: ? _raw_spin_unlock+0x14/0x29
Nov 28 14:16:51 TheFang kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]
Nov 28 14:16:51 TheFang kernel: process_one_work+0x1ab/0x295
Nov 28 14:16:51 TheFang kernel: worker_thread+0x18b/0x244
Nov 28 14:16:51 TheFang kernel: ? rescuer_thread+0x281/0x281
Nov 28 14:16:51 TheFang kernel: kthread+0xe7/0xef
Nov 28 14:16:51 TheFang kernel: ? kthread_complete_and_exit+0x1b/0x1b
Nov 28 14:16:51 TheFang kernel: ret_from_fork+0x22/0x30
Nov 28 14:16:51 TheFang kernel: </TASK>
Nov 28 14:16:51 TheFang kernel: ---[ end trace 0000000000000000 ]---Nov 28 14:16:51 TheFang kernel: ------------[ cut here ]------------

 

Having a similar issue... switching to IPVlan does not fix this... 

 

Ever since the update, I have not be able to get my reverse proxy (SWAG) to work. Everything was running smooth for years until approximately two weeks ago. 

 

 

Edited November 28, 2023 by Slik

41 minutes ago, bmartino1 said:

Here is an example of the gui option that is now missing. This is a upgraded Unraid form version 6.9 > latest 6.12.4.

Their setting is bond yes bridge no. They also have the error under fix plugin macvlan traces found.

 

I bet if i deleted the network config to fix the issue it would indeed work the question is what changed in the old network config and new upgrade to change the gui options...

 

 

 

 

You fixed this by deleteing your network config file on the flash drive?

6 hours ago, Slik said:

 

You fixed this by deleteing your network config file on the flash drive?

 

thats correct. I don't know what line in the config setting is there that is broken or not pasrsed correctly.

 

After deleting the /boot/config/network.cfg

-as /boot is the flash drive if using web terminal and MC to delete the file.

 

 

Reboot and unraid should recreate the network config. I have a New IP set from DHCP.

 

Then you reset up the network by flowing the release notes. Bridging off.

^as seen in the above comments. I have not seen a mac valn trace in the plug nor the log since the deletion of the network config.

 

I wish I made a backup of the file to compare the two. May attempt with friends system if they are ok with it...

Edited November 29, 2023 by bmartino1
adding path and pictures

Sorry guys.. i got the Same issue.. i switched to IPVLAN it worked for longer than a month.. now i got no connections to Unraid.. 

 

So if  i understand it correct.. you delate the network.cfg and than?

let the System on IPVLAN? 

16 hours ago, bmartino1 said:

I don't understand the disconnect... I appreciate your willingness to help BUT please read my entire comments... Trace is still happening even after bridging is off after a upgrade.

 

I'm sorry, I did not read all the comments, in my defense your first reply was

 

On 11/27/2023 at 8:33 PM, bmartino1 said:

I have seen the release notes. IPVLAN as i mentioned doesn't work for my use case.

So I assumed you didn't understand that you could still use macvlan, but I should have read the rest, sometimes too many threads to read and not enough time, my fault.

 

On 11/27/2023 at 9:30 PM, bmartino1 said:

Is there an issues with webui in place upgrade that changes the network config?

 

example of missing setting:

I was able to chose ipvlan and macvlan within docker setting.

 

v6.12.4 doesn't show the macvlan/ipvlan option if bridging is disabled for eth0, v6.12.5 shows it again to avoid confusion, but if bridging for eth0 is disabled only macvlan can be used.

 

If I understand correctly you are now using macvlan and no longer see the call traces?

 

 

 

 

 

7 hours ago, JorgeB said:

v6.12.4 doesn't show the macvlan/ipvlan option if bridging is disabled for eth0, v6.12.5 shows it again to avoid confusion, but if bridging for eth0 is disabled only macvlan can be used.

 

If I understand correctly you are now using macvlan and no longer see the call traces?

 

 

 

 

 

 

That is correct, my macvlan trace has stopped in the boot process and logging after the change. That's my bad, I could be more clear in my report. Trying to follow rules and not be as public with my information for security.

 

Good to know that the bridge setting, this what removes the gui options.

 

eLpresidente

That is correct. After deleting the network config file and having unraid recreate and set the setting per the release notes

when you get back to the gui if you set bridging off you will be using macvlan.

This is the process:

 

step 1: Connect a monitor to see boot process of unraid and get ip at boot.

 

step 2: make a backup of the file before deleting the file for recover

 

step 3 delete the file  /boot/config/network.cfg

--Step 3.5 you should disable VM and docker before reboot

 

Step 4 reboot

 

Step 5 acquire unraid's new IP address

 

Step 6 sign in to unraid

 

Step 7 settings > network

Folow https://docs.unraid.net/unraid-os/release-notes/6.12.4/ release notes for macvlan

*Disable Bridging

 

Example of my settings for macvlan:

 

step 8 reboot and check log / fix plug to see if you have any macvlan traces.

step 8.5 enable VM and docker. before reboot and check again

 

this will no use vhost@eth and or macvtap0@eth0 for the ip for the docker network for macvlan connections to and from the docker.

Edited November 29, 2023 by bmartino1
I can't type - fix speling

4 hours ago, bmartino1 said:

 

That is correct, my macvlan trace has stopped in the boot process and logging after the change. That's my bad, I could be more clear in my report. Trying to follow rules and not be as public with my information for security.

 

Good to know that the bridge setting, this what removes the gui options.

 

eLpresidente

That is correct. After deleting the network config file and having unraid recreate and set the setting per the release notes

when you get back to the gui if you set bridging off you will be using macvlan.

This is the process:

 

step 1: Connect a monitor to see boot process of unraid and get ip at boot.

 

step 2: make a backup of the file before deleting the file for recover

 

step 3 delete the file  /boot/config/network.cfg

--Step 3.5 you should disable VM and docker before reboot

 

Step 4 reboot

 

Step 5 acquire unraid's new IP address

 

Step 6 sign in to unraid

 

Step 7 settings > network

Folow https://docs.unraid.net/unraid-os/release-notes/6.12.4/ release notes for macvlan

*Disable Bridging

 

Example of my settings for macvlan:

 

step 8 reboot and check log / fix plug to see if you have any macvlan traces.

step 8.5 enable VM and docker. before reboot and check again

 

this will no use vhost@eth and or macvtap0@eth0 for the ip for the docker network for macvlan connections to and from the docker.

i will try this next.. just set up things like in the release note says.. 

but getting still Crashes with IP and Unraid.. Server works fine if you use a Display directly attached.. 

 

No i will try your way  but not today.. thanks for giving me a Step by Step introduction.. 

 

Maybe somone could check my Syslog.. if it is the MACVLAN problem. 

syslog Absturz2

Thanks 

2 hours ago, eLpresidente said:

i will try this next.. just set up things like in the release note says.. 

but getting still Crashes with IP and Unraid.. Server works fine if you use a Display directly attached.. 

 

No i will try your way  but not today.. thanks for giving me a Step by Step introduction.. 

 

Maybe somone could check my Syslog.. if it is the MACVLAN problem. 

syslog Absturz2

Thanks 

 

Your issues according to your syslog attached is not a macvlan issues:

Reviewing your dmeseg syslog your error is with the Intel Graphic controller driver and wrong plugin installed.

 

Nov 30 00:57:55 stevenas kernel: ------------[ cut here ]------------
Nov 30 00:57:55 stevenas kernel: igc: Failed to read reg 0xc030!
Nov 30 00:57:55 stevenas kernel: WARNING: CPU: 1 PID: 21978 at drivers/net/ethernet/intel/igc/igc_main.c:6472 igc_rd32+0x76/0x8b [igc]
Nov 30 00:57:55 stevenas kernel: Modules linked in: xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle vhost_net tun vhost vhost_iotlb udp_diag nft_chain_nat nft_compat nf_tables tls wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype br_netfilter bridge stp llc xfs md_mod tcp_diag inet_diag it87(O) hwmon_vid kvmgt mdev i915 drm_buddy i2c_algo_bit ttm drm_display_helper drm_kms_helper drm intel_gtt agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops ip6table_filter ip6_tables iptable_filter ip_tables x_tables efivarfs macvtap macvlan tap zfs(PO) intel_rapl_msr intel_rapl_common iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel zunicode(PO) zzstd(O) kvm zlua(O) zavl(PO) icp(PO) btusb btrtl btbcm btintel
Nov 30 00:57:55 stevenas kernel: crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel bluetooth sha512_ssse3 sr_mod aesni_intel cdrom crypto_simd zcommon(PO) cryptd znvpair(PO) rapl input_leds spl(O) intel_cstate ecdh_generic mei_hdcp mei_pxp gigabyte_wmi wmi_bmof led_class joydev ecc nvme i2c_i801 tpm_crb intel_uncore tpm_tis i2c_smbus mei_me video ahci tpm_tis_core igc i2c_core nvme_core mei libahci wmi thermal fan tpm backlight intel_pmc_core acpi_tad acpi_pad button unix
Nov 30 00:57:55 stevenas kernel: CPU: 1 PID: 21978 Comm: kworker/1:1 Tainted: P     U     O       6.1.49-Unraid #1
Nov 30 00:57:55 stevenas kernel: Hardware name: Gigabyte Technology Co., Ltd. B760I AORUS PRO DDR4/B760I AORUS PRO DDR4, BIOS F5 07/24/2023
Nov 30 00:57:55 stevenas kernel: Workqueue: events igc_watchdog_task [igc]
Nov 30 00:57:55 stevenas kernel: RIP: 0010:igc_rd32+0x76/0x8b [igc]
Nov 30 00:57:55 stevenas kernel: Code: 8b bb 28 ff ff ff e8 d8 41 ff e0 84 c0 75 0d 83 c8 ff eb 1a 8b 02 ff c0 75 f5 eb bf 89 ee 48 c7 c7 db 6f 4b a0 e8 97 48 bc e0 <0f> 0b eb e1 5b 5d 41 5c c3 cc cc cc cc 83 c8 ff c3 cc cc cc cc 0f
Nov 30 00:57:55 stevenas kernel: RSP: 0018:ffffc90001273e00 EFLAGS: 00010286
Nov 30 00:57:55 stevenas kernel: RAX: 0000000000000000 RBX: ffff888132240ba0 RCX: 0000000000000027
Nov 30 00:57:55 stevenas kernel: RDX: 0000000000000003 RSI: ffffffff820ed4af RDI: 00000000ffffffff
Nov 30 00:57:55 stevenas kernel: RBP: 000000000000c030 R08: 0000000000000000 R09: ffffffff8294e3f0
Nov 30 00:57:55 stevenas kernel: R10: 00003fffffffffff R11: ffff8890bfbd2b06 R12: ffff888132240000
Nov 30 00:57:55 stevenas kernel: R13: 000000000000c030 R14: ffff888103da4c80 R15: 0000000000000000
Nov 30 00:57:55 stevenas kernel: FS:  0000000000000000(0000) GS:ffff88907f640000(0000) knlGS:0000000000000000
Nov 30 00:57:55 stevenas kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 30 00:57:55 stevenas kernel: CR2: 000014938a339a60 CR3: 000000000420a000 CR4: 0000000000752ee0
Nov 30 00:57:55 stevenas kernel: PKRU: 55555554
Nov 30 00:57:55 stevenas kernel: Call Trace:
Nov 30 00:57:55 stevenas kernel: <TASK>
Nov 30 00:57:55 stevenas kernel: ? __warn+0xab/0x122
Nov 30 00:57:55 stevenas kernel: ? report_bug+0x109/0x17e
Nov 30 00:57:55 stevenas kernel: ? igc_rd32+0x76/0x8b [igc]
Nov 30 00:57:55 stevenas kernel: ? handle_bug+0x41/0x6f
Nov 30 00:57:55 stevenas kernel: ? exc_invalid_op+0x13/0x60
Nov 30 00:57:55 stevenas kernel: ? asm_exc_invalid_op+0x16/0x20
Nov 30 00:57:55 stevenas kernel: ? igc_rd32+0x76/0x8b [igc]
Nov 30 00:57:55 stevenas kernel: igc_update_stats+0x70/0x6ae [igc]
Nov 30 00:57:55 stevenas kernel: igc_watchdog_task+0x308/0x435 [igc]
Nov 30 00:57:55 stevenas kernel: process_one_work+0x1a8/0x295
Nov 30 00:57:55 stevenas kernel: worker_thread+0x18b/0x244
Nov 30 00:57:55 stevenas kernel: ? rescuer_thread+0x281/0x281
Nov 30 00:57:55 stevenas kernel: kthread+0xe4/0xef
Nov 30 00:57:55 stevenas kernel: ? kthread_complete_and_exit+0x1b/0x1b
Nov 30 00:57:55 stevenas kernel: ret_from_fork+0x1f/0x30
Nov 30 00:57:55 stevenas kernel: </TASK>
Nov 30 00:57:55 stevenas kernel: ---[ end trace 0000000000000000 ]---

 

Other than some weird bridging of eth0 which resembles multiple unplug in and/or plunging a nic in and out multiple times.
I would have you check your Ethernet cable.

 

Network starting around line 880 Nov 29 22:58:18 stevenas kernel: igc 0000:04:00.0 eth0: MAC: 74:56:3c:46:79:e3

and onward...

 

macvlan was setup at line 1071  and line 1129 is when you had network and should have been able to ping.

line 2803 is when some weirdness happened with eth0 being renamed

but this has nothing to do with macvlan...

 

Then some side questions with the plugins as some of the apps from nerd tool you have.

error with python. I recommend installing the python 2 pack.

Python2 Package dlandon and not use nerd tools to install python.

 

The error seems to happen after the intel graphic plugin comes in and changes your driver.

line 1898

Nov 29 22:58:32 stevenas kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
Nov 29 22:58:32 stevenas kernel: ACPI: video: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Nov 29 22:58:32 stevenas kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
Nov 29 22:58:32 stevenas kernel: fbcon: i915drmfb (fb0) is primary device
Nov 29 22:58:32 stevenas kernel: Console: switching to colour frame buffer device 240x67
Nov 29 22:58:32 stevenas kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Nov 29 22:58:32 stevenas kernel: i915 0000:00:02.0: [drm] Unsupported device. GVT-g is disabled
Nov 29 22:58:33 stevenas root: 
Nov 29 22:58:33 stevenas root: -------------Installation of Intel GVT-g successful--------------
Nov 29 22:58:33 stevenas root: 
Nov 29 22:58:33 stevenas root: 
Nov 29 22:58:33 stevenas root: -----------------------------------------------------------------
Nov 29 22:58:33 stevenas root: -----------------Intel GVT-g plugin installed--------------------
Nov 29 22:58:33 stevenas root: -----------------------------------------------------------------
Nov 29 22:58:33 stevenas root: plugin: intel-gvt-g.plg installed
Nov 29 22:58:33 stevenas root: plugin: intel-gvt-g.plg installed
Nov 29 22:58:33 stevenas root: Executing hook script: gui_search_post_hook.sh
Nov 29 22:58:33 stevenas root: Executing hook script: post_plugin_checks
Nov 29 22:58:33 stevenas root: plugin: installing: it87-driver.plg
Nov 29 22:58:33 stevenas root: Executing hook script: pre_plugin_checks
Nov 29 22:58:33 stevenas root: plugin: creating: /usr/local/emhttp/plugins/it87-driver/README.md - from INLINE content
Nov 29 22:58:33 stevenas root: plugin: running: anonymous

 

this may be why you require a monitor to run.

 

 

I recommend reaching out on the forum about your graphic issue.

 

line 4950:

Nov 30 00:57:55 stevenas kernel: Hardware name: Gigabyte Technology Co., Ltd. B760I AORUS PRO DDR4/B760I AORUS PRO DDR4, BIOS F5 07/24/2023

 

seeing as you are using beta plugins and that you have a i915 IGPU

I believe you should be using Intel i915 SR-IOV and not Intel-GVT-g plugin

Edited November 30, 2023 by bmartino1
update to correct fourm link fix spelling/typing

4 hours ago, bmartino1 said:

 

I would have you check your Ethernet cable.

I will check it. Thanks.. maybe changing to be sure.. 

 

4 hours ago, bmartino1 said:

 

Then some side questions with the plugins as some of the apps from nerd tool you have.

error with python. I recommend installing the python 2 pack.

Python2 Package dlandon and not use nerd tools to install python.

okey i will try to install python 2, but i am to new in Unraid and Linux i'll try my best

 

Quote

seeing as you are using beta plugins and that you have a i915 IGPU

I believe you should be using Intel i915 SR-IOV and not Intel-GVT-g plugin

i have a Intel i5 13500k wit 770UHD iGPU <-- guess i messed totaly with the Plugins... but transcoding etc. worked for me.. What do i have to install instead ? Sorry like i said, totaly newbee 

Changed Status to Closed

Tested in updated form 12.4 > 12.5

and tested in 12.5 > 12.6

 

see solution steps here:

 

Per client issue.

I recommend reviewing: