dumurluk

Members
  • Posts

    21
  • Joined

  • Last visited

Everything posted by dumurluk

  1. Right, the volumes were created in command line, but unraid's gui accepts them as the host path. Same with regular named volumes, if the host path does not begin with a forward slash, docker will use a named volume instead of a bind mount. Unraid's gui simply passes that value to docker run and does not interfere with the outcome. Here's what the volume setting looks like:
  2. Great job on the new grouped containers feature. It was much needed for containers with dependencies or external databases. It works flawlessly. However, I did run into a minor issue with nfs docker volumes that were not properly detected by the plugin and resulted in log errors. It didn't end up causing an actual issue other than log errors, so not that big of a deal in my case, but I'll detail it below. My plex container has a few docker volumes (named volumes) set up using the nfs volume driver (because my media resides on a different server): https://docs.docker.com/storage/volumes/#create-a-service-which-creates-an-nfs-volume It is a docker volume that automatically mounts a remote nfs path inside the container. The plugin settings don't detect them at all and they are not listed under "Configured Volumes" under plex. However, when I run the backup, I get the following errors where they do get detected but the plugin can't figure out the host path (there is no host path as it's not a bind mount). [06.02.2024 22:25:52][❌][plex] '3dmovies' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:25:55][❌][plex] '4kmovies' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:25:58][❌][plex] 'movies' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:26:00][❌][plex] 'tvshows' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:26:03][❌][plex] 'music' does NOT exist! Please check your mappings! Skipping it for now. As I mentioned earlier, it didn't end up causing an actual issue for me because the paths were skipped, and that would be my preference anyway since those media paths are remote. For reference, the inspect for one of those volumes looks like this: # docker inspect movies [ { "CreatedAt": "2024-02-12T03:40:01-05:00", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/movies/_data", "Name": "movies", "Options": { "device": ":/mnt/user/Movies", "o": "addr=192.168.1.10,rw", "type": "nfs" }, "Scope": "local" } ]
  3. Updated the same server that was previously having issues, without any changes to the flash drive and 6.10.1 is starting up just fine. Thanks By the way, the issue with my flash drive was that it doesn't have a partition and is listed at "/dev/sda"
  4. I don't believe partitioning was ever a requirement when I set my servers up. The process was just format, label, unzip the files and run the make bootable script.
  5. I just ran "blkid" on my server currently running 6.9.2 and there is only one "sda" partition listed: /dev/sda: LABEL="UNRAID" UUID="DAA4-D416" BLOCK_SIZE="512" TYPE="vfat" Yet when I update to 6.10, unraid can't find the device
  6. @limetechthanks for addressing the issue and providing details and a workaround. I just wanted to point out that I did not to anything special when I set up the boot drive several years ago and never messed with any partitions. At the time, the imager app was not available so I'm pretty sure I just formatted it in Windows, with the UNRAID label, added the unraid files and ran the make bootable script. I'll check its partitions next time I take my server offline and get ready for another attempt at an upgrade.
  7. Oh yeah, I saw your post yesterday. Unfortunately it doesn't make a difference for me whether it's restarted or started from power down. Either way it gets stuck on the drive check.
  8. There were reports but they didn't seem to be acted on. Folks seem to have just reverted back to the stable then. Here is one from last August: And here's one from September:
  9. Yes, I agree. That's why we need @limetechto chime in on how exactly it tries to enumerate and detect the flash drive (different from 6.9.x, which works just fine). I'm really surprised that they didn't set the few days after a major stable release aside as an all hands on deck for support type of situation. It's not like they do releases often. The last one was a long time ago. Limetech is not a one person hobby project anymore. They really should be checking the bugs section on their official forum the day after a major stable release.
  10. Tried both, no difference. Unraid 6.9.2 boots in usb3 and 2. Like I said, it's not an issue with booting. It boots fine, unraid gets loaded up in ram, it's only when the init steps are happening, unraid somehow thinks the flash drive is not there (likely for license check). There is no issue with actual bios booting
  11. It's not the system that can't see it, it's whatever script limetech coded that can't "see" it.
  12. @limetechcan you chime in on what that new functionality is supposed to be doing? That way we can try and properly troubleshoot. "waiting up to 30 sec for device with label UNRAID to come online"? I mean, it is booting off of the usb drive up to that point. And the usb drive is clearly labeled "UNRAID". Thanks EDIT: I have a feeling it's exclusively for checking the usb id for license check, which would be quite annoying (to bring down the whole server because of a failure in simple license check). Even Windows doesn't completely disable itself when the license activation fails.
  13. Same issue here. Updated from previous stable via gui, rebooted and get the 30 sec message looking for device labeled UNRAID and it can't find it. I tried to manually unzip the bz files and try again, same result. I unzipped the previous stable's bz files and everything's working again. So there are no issues with my flash drive. Perhaps limetech can clarify what that new process is so we can try and figure what the issue is?
  14. No, I did not. At this point I don't have it in me to deal with more cmos resets. I've also been dealing with another issue that affects this board on unraid (kernel panics and lock ups every 12 hours or so). This board and unraid have been a bad combo so far.
  15. Same. I'm assuming you have unraid load igpu drivers for hw transcode? Once those drivers are loaded, the motherboard disables vga, which is connected to the IPMI for ikvm. See here for a broader discussion on that:
  16. Here we go again. Before I could get to my server, it's locked up again. Barely lasted 12 hours. No br0 static IP containers. I have a couple on br0.10 vlan. "host access to custom networks" was enabled iirc. Here's the last of the log sent to remote syslog before the crash: May 1 13:35:22 Tower kernel: BUG: unable to handle page fault for address: 00000000ffffffae May 1 13:35:22 Tower kernel: #PF: supervisor read access in kernel mode May 1 13:35:22 Tower kernel: #PF: error_code(0x0000) - not-present page May 1 13:35:22 Tower kernel: PGD 800000061069f067 P4D 800000061069f067 PUD 0 May 1 13:35:22 Tower kernel: Oops: 0000 [#1] SMP PTI May 1 13:35:22 Tower kernel: CPU: 6 PID: 20760 Comm: node Tainted: G W 5.10.28-Unraid #1 May 1 13:35:22 Tower kernel: Hardware name: Supermicro Super Server/X11SCA-F, BIOS 1.4 09/03/2020 May 1 13:35:22 Tower kernel: RIP: 0010:nf_nat_setup_info+0x129/0x6aa [nf_nat] May 1 13:35:22 Tower kernel: Code: ff 48 8b 15 ef 6a 00 00 89 c0 48 8d 04 c2 48 8b 10 48 85 d2 74 80 48 81 ea 98 00 00 00 48 85 d2 0f 84 70 ff ff ff 8a 44 24 46 <38> 42 46 74 09 48 8b 92 98 00 00 00 eb d9 48 8b 4a 20 48 8b 42 28 May 1 13:35:22 Tower kernel: RSP: 0018:ffffc9000023c700 EFLAGS: 00010202 May 1 13:35:22 Tower kernel: RAX: ffff88815d423e06 RBX: ffff8881147c57c0 RCX: 0000000000000000 May 1 13:35:22 Tower kernel: RDX: 00000000ffffff68 RSI: 00000000c2955a34 RDI: ffffc9000023c720 May 1 13:35:22 Tower kernel: RBP: ffffc9000023c7c8 R08: 00000000f7570d7c R09: ffff8881010870a0 May 1 13:35:22 Tower kernel: R10: ffff8886a70e0388 R11: ffffffff815cbe4b R12: 0000000000000000 May 1 13:35:22 Tower kernel: R13: ffffc9000023c720 R14: ffffc9000023c7dc R15: ffffffff8210b440 May 1 13:35:22 Tower kernel: FS: 000015372ba5eb48(0000) GS:ffff88902c380000(0000) knlGS:0000000000000000 May 1 13:35:22 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 1 13:35:22 Tower kernel: CR2: 00000000ffffffae CR3: 00000001fee5c001 CR4: 00000000003726e0 May 1 13:35:22 Tower kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 May 1 13:35:22 Tower kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 May 1 13:35:22 Tower kernel: Call Trace: May 1 13:35:22 Tower kernel: <IRQ> May 1 13:35:22 Tower kernel: ? bond_start_xmit+0x26e/0x292 [bonding] May 1 13:35:22 Tower kernel: ? __ksize+0x15/0x64 May 1 13:35:22 Tower kernel: ? krealloc+0x26/0x7a May 1 13:35:22 Tower kernel: nf_nat_masquerade_ipv4+0x10b/0x131 [nf_nat] May 1 13:35:22 Tower kernel: masquerade_tg+0x44/0x5e [xt_MASQUERADE] May 1 13:35:22 Tower kernel: ipt_do_table+0x51a/0x5c0 [ip_tables] May 1 13:35:22 Tower kernel: ? ipt_do_table+0x570/0x5c0 [ip_tables] May 1 13:35:22 Tower kernel: ? fib_validate_source+0xb0/0xda May 1 13:35:22 Tower kernel: nf_nat_inet_fn+0xe9/0x183 [nf_nat] May 1 13:35:22 Tower kernel: nf_nat_ipv4_out+0xf/0x88 [nf_nat] May 1 13:35:22 Tower kernel: nf_hook_slow+0x39/0x8e May 1 13:35:22 Tower kernel: nf_hook+0xab/0xd3 May 1 13:35:22 Tower kernel: ? __ip_finish_output+0x146/0x146 May 1 13:35:22 Tower kernel: ip_output+0x7d/0x8a May 1 13:35:22 Tower kernel: ? __ip_finish_output+0x146/0x146 May 1 13:35:22 Tower kernel: ip_forward+0x3f1/0x420 May 1 13:35:22 Tower kernel: ? ip_check_defrag+0x18f/0x18f May 1 13:35:22 Tower kernel: ip_sabotage_in+0x43/0x4d [br_netfilter] May 1 13:35:22 Tower kernel: nf_hook_slow+0x39/0x8e May 1 13:35:22 Tower kernel: nf_hook.constprop.0+0xb1/0xd8 May 1 13:35:22 Tower kernel: ? l3mdev_l3_rcv.constprop.0+0x50/0x50 May 1 13:35:22 Tower kernel: ip_rcv+0x41/0x61 May 1 13:35:22 Tower kernel: __netif_receive_skb_one_core+0x74/0x95 May 1 13:35:22 Tower kernel: netif_receive_skb+0x79/0xa1 May 1 13:35:22 Tower kernel: br_handle_frame_finish+0x30d/0x351 May 1 13:35:22 Tower kernel: ? ipt_do_table+0x570/0x5c0 [ip_tables] May 1 13:35:22 Tower kernel: ? br_pass_frame_up+0xda/0xda May 1 13:35:22 Tower kernel: br_nf_hook_thresh+0xa3/0xc3 [br_netfilter] May 1 13:35:22 Tower kernel: ? br_pass_frame_up+0xda/0xda May 1 13:35:22 Tower kernel: br_nf_pre_routing_finish+0x23d/0x264 [br_netfilter] May 1 13:35:22 Tower kernel: ? br_pass_frame_up+0xda/0xda May 1 13:35:22 Tower kernel: ? br_handle_frame_finish+0x351/0x351 May 1 13:35:22 Tower kernel: ? nf_nat_ipv4_pre_routing+0x1e/0x4a [nf_nat] May 1 13:35:22 Tower kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] May 1 13:35:22 Tower kernel: ? br_handle_frame_finish+0x351/0x351 May 1 13:35:22 Tower kernel: NF_HOOK+0xd7/0xf7 [br_netfilter] May 1 13:35:22 Tower kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] May 1 13:35:22 Tower kernel: br_nf_pre_routing+0x229/0x239 [br_netfilter] May 1 13:35:22 Tower kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] May 1 13:35:22 Tower kernel: br_handle_frame+0x25e/0x2a6 May 1 13:35:22 Tower kernel: ? br_pass_frame_up+0xda/0xda May 1 13:35:22 Tower kernel: __netif_receive_skb_core+0x335/0x4e7 May 1 13:35:22 Tower kernel: ? igb_poll+0xcc8/0xef6 [igb] May 1 13:35:22 Tower kernel: __netif_receive_skb_one_core+0x3d/0x95 May 1 13:35:22 Tower kernel: process_backlog+0xa3/0x13b May 1 13:35:22 Tower kernel: net_rx_action+0xf4/0x29d May 1 13:35:22 Tower kernel: __do_softirq+0xc4/0x1c2 May 1 13:35:22 Tower kernel: asm_call_irq_on_stack+0x12/0x20 May 1 13:35:22 Tower kernel: </IRQ> May 1 13:35:22 Tower kernel: do_softirq_own_stack+0x2c/0x39 May 1 13:35:22 Tower kernel: do_softirq+0x3a/0x44 May 1 13:35:22 Tower kernel: __local_bh_enable_ip+0x3b/0x43 May 1 13:35:22 Tower kernel: ip_finish_output2+0x2ec/0x31f May 1 13:35:22 Tower kernel: ? ipv4_mtu+0x3d/0x64 May 1 13:35:22 Tower kernel: __ip_queue_xmit+0x2a3/0x2df May 1 13:35:22 Tower kernel: __tcp_transmit_skb+0x845/0x8ba May 1 13:35:22 Tower kernel: tcp_connect+0x76d/0x7f4 May 1 13:35:22 Tower kernel: tcp_v4_connect+0x3fc/0x455 May 1 13:35:22 Tower kernel: __inet_stream_connect+0xd3/0x2b6 May 1 13:35:22 Tower kernel: inet_stream_connect+0x34/0x49 May 1 13:35:22 Tower kernel: __sys_connect+0x62/0x9d May 1 13:35:22 Tower kernel: __x64_sys_connect+0x11/0x14 May 1 13:35:22 Tower kernel: do_syscall_64+0x5d/0x6a May 1 13:35:22 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 May 1 13:35:22 Tower kernel: RIP: 0033:0x15372ba1d352 May 1 13:35:22 Tower kernel: Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 8a d2 ff ff 41 54 b8 02 00 00 00 49 89 f4 be 00 88 08 00 55 May 1 13:35:22 Tower kernel: RSP: 002b:00007ffcbe850d08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a May 1 13:35:22 Tower kernel: RAX: ffffffffffffffda RBX: 000015372ba5eb48 RCX: 000015372ba1d352 May 1 13:35:22 Tower kernel: RDX: 0000000000000010 RSI: 00007ffcbe850dd0 RDI: 000000000000001c May 1 13:35:22 Tower kernel: RBP: 000015372ba5eb7c R08: 0000000000000000 R09: 0000000000000000 May 1 13:35:22 Tower kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000002a May 1 13:35:22 Tower kernel: R13: 0000000000000010 R14: 0000153729a44c68 R15: 0000559800038140 May 1 13:35:22 Tower kernel: Modules linked in: xt_mark xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat xt_nat xt_tcpudp iptable_mangle nf_tables vhost_net tun vhost vhost_iotlb tap veth macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs dm_crypt dm_mod dax nfsd lockd grace sunrpc i915 iosf_mbi drm_kms_helper drm intel_gtt agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops md_mod ipmi_devintf ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding e1000e igb i2c_algo_bit x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel wmi_bmof kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ipmi_ssif crypto_simd cryptd glue_helper rapl intel_cstate mpt3sas i2c_i801 i2c_smbus input_leds raid_class intel_uncore nvme i2c_core scsi_transport_sas ahci led_class nvme_core wmi libahci video intel_pch_thermal acpi_ipmi ie31200_edac backlight ipmi_si May 1 13:35:22 Tower kernel: acpi_pad thermal button fan [last unloaded: e1000e] May 1 13:35:22 Tower kernel: CR2: 00000000ffffffae
  17. Thanks, that's what I was going to try next. Btw do you know which nic is the one shared with ipmi? Is it the igb one or the e1000e one as shown in unraid gui?
  18. I was on a Supermicro X9SRL-F board with an old Xeon E5 and no issues on 6.9.2. I just swapped the mobo with a Supermicro X11SCA-F and every few hours I get a kernel panic and the nf_conntrack message. It locked up once yesterday (no console, no ssh access, etc.) and required a hard reset and parity check. Today I moved the 2 containers off of br0 into br0.10 (vlan) and 2 hours later I got the kernel panic again (no lock up, though). I have 2 network interfaces bonded in this case. Here's the message: Apr 30 19:36:53 Tower kernel: ------------[ cut here ]------------ Apr 30 19:36:53 Tower kernel: WARNING: CPU: 5 PID: 0 at net/netfilter/nf_conntrack_core.c:1120 __nf_conntrack_confirm+0x9b/0x1e6 [nf_conntrack] Apr 30 19:36:53 Tower kernel: Modules linked in: xt_mark xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat xt_nat xt_tcpudp iptable_mangle nf_tables vhost_net tun vhost vhost_iotlb tap veth macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs dm_crypt dm_mod dax nfsd lockd grace sunrpc i915 iosf_mbi drm_kms_helper drm intel_gtt agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops md_mod ipmi_devintf ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding e1000e igb i2c_algo_bit x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel wmi_bmof kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ipmi_ssif crypto_simd cryptd glue_helper rapl intel_cstate mpt3sas i2c_i801 i2c_smbus input_leds raid_class intel_uncore nvme i2c_core scsi_transport_sas ahci led_class nvme_core wmi libahci video intel_pch_thermal acpi_ipmi ie31200_edac backlight ipmi_si Apr 30 19:36:53 Tower kernel: acpi_pad thermal button fan [last unloaded: e1000e] Apr 30 19:36:53 Tower kernel: CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.10.28-Unraid #1 Apr 30 19:36:53 Tower kernel: Hardware name: Supermicro Super Server/X11SCA-F, BIOS 1.4 09/03/2020 Apr 30 19:36:53 Tower kernel: RIP: 0010:__nf_conntrack_confirm+0x9b/0x1e6 [nf_conntrack] Apr 30 19:36:53 Tower kernel: Code: e8 dc f8 ff ff 44 89 fa 89 c6 41 89 c4 48 c1 eb 20 89 df 41 89 de e8 36 f6 ff ff 84 c0 75 bb 48 8b 85 80 00 00 00 a8 08 74 18 <0f> 0b 89 df 44 89 e6 31 db e8 6d f3 ff ff e8 35 f5 ff ff e9 22 01 Apr 30 19:36:53 Tower kernel: RSP: 0018:ffffc900002108a0 EFLAGS: 00010202 Apr 30 19:36:53 Tower kernel: RAX: 0000000000000188 RBX: 0000000000006ffc RCX: 0000000020a3ac63 Apr 30 19:36:53 Tower kernel: RDX: 0000000000000000 RSI: 00000000000000fe RDI: ffffffffa060b1f0 Apr 30 19:36:53 Tower kernel: RBP: ffff888617023400 R08: 0000000093f9e799 R09: ffff888101087480 Apr 30 19:36:53 Tower kernel: R10: 0000000000000158 R11: ffff888105074100 R12: 00000000000034fe Apr 30 19:36:53 Tower kernel: R13: ffffffff8210b440 R14: 0000000000006ffc R15: 0000000000000000 Apr 30 19:36:53 Tower kernel: FS: 0000000000000000(0000) GS:ffff88902c340000(0000) knlGS:0000000000000000 Apr 30 19:36:53 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 30 19:36:53 Tower kernel: CR2: 000014ea44ed23f4 CR3: 000000000200a003 CR4: 00000000003726e0 Apr 30 19:36:53 Tower kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Apr 30 19:36:53 Tower kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Apr 30 19:36:53 Tower kernel: Call Trace: Apr 30 19:36:53 Tower kernel: <IRQ> Apr 30 19:36:53 Tower kernel: nf_conntrack_confirm+0x2f/0x36 [nf_conntrack] Apr 30 19:36:53 Tower kernel: nf_hook_slow+0x39/0x8e Apr 30 19:36:53 Tower kernel: nf_hook.constprop.0+0xb1/0xd8 Apr 30 19:36:53 Tower kernel: ? ip_protocol_deliver_rcu+0xfe/0xfe Apr 30 19:36:53 Tower kernel: ip_local_deliver+0x49/0x75 Apr 30 19:36:53 Tower kernel: ip_sabotage_in+0x43/0x4d [br_netfilter] Apr 30 19:36:53 Tower kernel: nf_hook_slow+0x39/0x8e Apr 30 19:36:53 Tower kernel: nf_hook.constprop.0+0xb1/0xd8 Apr 30 19:36:53 Tower kernel: ? l3mdev_l3_rcv.constprop.0+0x50/0x50 Apr 30 19:36:53 Tower kernel: ip_rcv+0x41/0x61 Apr 30 19:36:53 Tower kernel: __netif_receive_skb_one_core+0x74/0x95 Apr 30 19:36:53 Tower kernel: netif_receive_skb+0x79/0xa1 Apr 30 19:36:53 Tower kernel: br_handle_frame_finish+0x30d/0x351 Apr 30 19:36:53 Tower kernel: ? ipt_do_table+0x570/0x5c0 [ip_tables] Apr 30 19:36:53 Tower kernel: ? br_pass_frame_up+0xda/0xda Apr 30 19:36:53 Tower kernel: br_nf_hook_thresh+0xa3/0xc3 [br_netfilter] Apr 30 19:36:53 Tower kernel: ? br_pass_frame_up+0xda/0xda Apr 30 19:36:53 Tower kernel: br_nf_pre_routing_finish+0x23d/0x264 [br_netfilter] Apr 30 19:36:53 Tower kernel: ? br_pass_frame_up+0xda/0xda Apr 30 19:36:53 Tower kernel: ? br_handle_frame_finish+0x351/0x351 Apr 30 19:36:53 Tower kernel: ? nf_nat_ipv4_pre_routing+0x1e/0x4a [nf_nat] Apr 30 19:36:53 Tower kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] Apr 30 19:36:53 Tower kernel: ? br_handle_frame_finish+0x351/0x351 Apr 30 19:36:53 Tower kernel: NF_HOOK+0xd7/0xf7 [br_netfilter] Apr 30 19:36:53 Tower kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] Apr 30 19:36:53 Tower kernel: br_nf_pre_routing+0x229/0x239 [br_netfilter] Apr 30 19:36:53 Tower kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] Apr 30 19:36:53 Tower kernel: br_handle_frame+0x25e/0x2a6 Apr 30 19:36:53 Tower kernel: ? br_pass_frame_up+0xda/0xda Apr 30 19:36:53 Tower kernel: __netif_receive_skb_core+0x335/0x4e7 Apr 30 19:36:53 Tower kernel: __netif_receive_skb_list_core+0x78/0x104 Apr 30 19:36:53 Tower kernel: netif_receive_skb_list_internal+0x1bf/0x1f2 Apr 30 19:36:53 Tower kernel: ? dev_gro_receive+0x55d/0x578 Apr 30 19:36:53 Tower kernel: gro_normal_list+0x1d/0x39 Apr 30 19:36:53 Tower kernel: napi_complete_done+0x79/0x104 Apr 30 19:36:53 Tower kernel: igb_poll+0xcc8/0xef6 [igb] Apr 30 19:36:53 Tower kernel: ? resched_curr+0x1e/0x4c Apr 30 19:36:53 Tower kernel: net_rx_action+0xf4/0x29d Apr 30 19:36:53 Tower kernel: __do_softirq+0xc4/0x1c2 Apr 30 19:36:53 Tower kernel: asm_call_irq_on_stack+0x12/0x20 Apr 30 19:36:53 Tower kernel: </IRQ> Apr 30 19:36:53 Tower kernel: do_softirq_own_stack+0x2c/0x39 Apr 30 19:36:53 Tower kernel: __irq_exit_rcu+0x45/0x80 Apr 30 19:36:53 Tower kernel: common_interrupt+0x119/0x12e Apr 30 19:36:53 Tower kernel: asm_common_interrupt+0x1e/0x40 Apr 30 19:36:53 Tower kernel: RIP: 0010:arch_local_irq_enable+0x7/0x8 Apr 30 19:36:53 Tower kernel: Code: 00 48 83 c4 28 4c 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 9c 58 0f 1f 44 00 00 c3 fa 66 0f 1f 44 00 00 c3 fb 66 0f 1f 44 00 00 <c3> 55 8b af 28 04 00 00 b8 01 00 00 00 45 31 c9 53 45 31 d2 39 c5 Apr 30 19:36:53 Tower kernel: RSP: 0018:ffffc900000fbea0 EFLAGS: 00000246 Apr 30 19:36:53 Tower kernel: RAX: ffff88902c362380 RBX: 0000000000000008 RCX: 000000000000001f Apr 30 19:36:53 Tower kernel: RDX: 0000000000000000 RSI: 0000000024879873 RDI: 0000000000000000 Apr 30 19:36:53 Tower kernel: RBP: ffffe8ffffb67a00 R08: 00000de4ea48c35c R09: 0000000000000000 Apr 30 19:36:53 Tower kernel: R10: 000000000000218c R11: 071c71c71c71c71c R12: 00000de4ea48c35c Apr 30 19:36:53 Tower kernel: R13: ffffffff820c5dc0 R14: 0000000000000008 R15: 0000000000000000 Apr 30 19:36:53 Tower kernel: cpuidle_enter_state+0x101/0x1c4 Apr 30 19:36:53 Tower kernel: cpuidle_enter+0x25/0x31 Apr 30 19:36:53 Tower kernel: do_idle+0x1a6/0x214 Apr 30 19:36:53 Tower kernel: cpu_startup_entry+0x18/0x1a Apr 30 19:36:53 Tower kernel: secondary_startup_64_no_verify+0xb0/0xbb Apr 30 19:36:53 Tower kernel: ---[ end trace d5200fbed8c48686 ]---
  19. Yeah, I spent way too much time on way too many cmos resets. I finally got it to a state where it seems to be stable (after several power cycles). At least now I have ikvm access to bios and can see most of the unraid boot process; and hw transcode works. I guess I can live without console access over ikvm.
  20. As a last ditch effort, I tried to bump the memory limits under graphics settings to see if it would fix the black screen issue with onboard oprom set to efi, but now it is getting stuck on PCI enumeration before you can get into bios. I officially give up. Going back to legacy boot with everything else legacy and pci primary set to onboard. At least I'll have bios access and most of the boot process on ikvm (modprobe is the last line in the go file). I don't have it in me to clear cmos and start over one more time.
  21. Hey guys, I just got the X11SCA-F and put in an E-2146G. It came with bios version 1.4. I followed all the advice and directions in this thread and nothing seems to let me have ikvm and /dev/dri at the same time. And there is one specific change that locks me out of all video output (even bios) and forces me to clear cmos and start over. Perhaps this bios version is really buggy. Here are my general observations: By default, boot is set to "dual", which should allow both legacy and uefi. When boot is set to "dual" or "legacy", most everything else is also automatically set to legacy (including the onboard video oprom option mentioned in this thread). When boot is set to "uefi", most other options also switch to uefi automatically (including onboard video oprom) Here is a list of what happens with different settings: Boot set to "dual", trying to load unraid with legacy, it gets into a boot loop where it goes through all the steps of the boot process and when it's time to boot into unraid, it resets. When I tried to boot unraid in uefi with that, same thing happened unless I selected the boot option manually, in which case it booted fine. Something about the "dual" boot setting just doesn't seem to work. Boot set to "legacy", primary display in bios set to pci, primary pci set to onboard and internal graphics set to enable, unraid boots via legacy just fine. ikvm works right up until modprobe and then it drops (tried with and without monitor attached) Boot set to "uefi", primary display in bios set to pci and internal graphics set to enable, unraid boots via uefi just fine. ikvm works right up until modprobe and then it drops (tried with and without monitor attached). One interesting thing is that when boot is set to uefi, the options "primary pci" and "primary peg" disappear from graphics settings, very strange. Now if boot is set to legacy, and I follow this thread's advice and set onboard video oprom to uefi, I can see the boot process with the Supermicro background, but it goes to a black screen (sometimes green and sometimes red) when it tries to boot into unraid or bios. This I tried with and without a monitor attached, and the same thing happens. I can no longer go into the bios because hitting "Del" results in the same black screen. The process goes on in the background (because unraid web gui does come up if I wait long enough). But I have no display. I tried hdmi as well, which displays nothing. And vga displays a faulty signal (according to a monitor). The only solution to this is to clear cmos and start over. I eveb tried this without ever plugging a monitor in at all after resetting cmos, so that's not it. So in a nutshell, legacy booting with onboard video oprom set to uefi completely breaks vga display, requiring a cmos clear. Legacy booting with bios set to pci and, pci default set to onboard and onboard video enabled, ikvm works up until modprobe. Uefi booting with bios set to pci and onboard video enabled (no option for default pci), ikvm works right up until modprobe. So I'm going with the final option for now, at least I can see to boot process and get into bios, and utilize hw transcode. But, it irks me that with uefi boot, the option for default pci is not there. I'm not sure what will happen when I plug in another gpu for passthrough. It will perhaps switch to that for output and make me lose ikvm for boot process? Who knows. In any case, this board looks awesome on paper, but the bios and the settings (and the bugs) are incredibly annoying and time consuming to try and figure out. I wish there were more options for affordable server boards with ipmi/ikvm.