Gnur

Update: I switched the PCI express card slot with the QUad Ports NIC card.... that did the trick.... not sure why... but it is working...

OK, I removed the PCI express adaptor to my nvme cache and didn't help, then I removed my IBM 39Y6138 IBM PRO/1000 PT Quad Port Server Adapter LP PCI-E and the boot completed without a problem... Now that I have identified the Quad Port NIC as the culprit, any idea how to solve the issue?

Didn't help. I have disabled Intel vt-d and intel virtualization... Same behavior.

I have also tried to boot with a stock 6.12.2 usb, same result it got stuck, last post below: Jul 2 23:58:29 Tower kernel: pci 0000:09:00.1: PME# supported from D0 D3hot D3cold Help please...

I was comparing the 6.11.5 syslog messages to what I got from 6.12.2 and looks like it got stuck Jul 2 23:58:29 Tower kernel: pci 0000:09:00.1: PME# supported from D0 D3hot D3cold <------------- this is the last msg I see during boot time on 6.12.2, the next lines are from 6.11.5 Jul 2 23:58:29 Tower kernel: pci 0000:08:02.0: PCI bridge to [bus 09] Jul 2 23:58:29 Tower kernel: pci 0000:08:02.0: bridge window [io 0xa000-0xafff] Jul 2 23:58:29 Tower kernel: pci 0000:08:02.0: bridge window [mem 0xf7200000-0xf72fffff] IOMMU group 14:[111d:8018] 08:02.0 PCI bridge: Microsemi / PMC / IDT PES12N3A 12-lane 3-Port PCI Express Switch (rev 0e) [8086:10bc] 09:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) [8086:10bc] 09:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) IOMMU group 15:[111d:8018] 08:04.0 PCI bridge: Microsemi / PMC / IDT PES12N3A 12-lane 3-Port PCI Express Switch (rev 0e) [8086:10bc] 0a:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) [8086:10bc] 0a:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller (Copper) (rev 06) Best Regards,

Hi all, I need help since my server does not boot anymore after 6.11.5 -> 6.12.2 upgrade, it looks like it's crashing. I have reverted to 6.11.5 for now... Any help is appreciated. Best regards, IMG_0759 (1).mov

Hi, since I have upgraded to 6.9.2 my unraid keeps crashing due to kernel panic every 3 or 4 days. My syslog is attached, I really appreciate any help. Best regards, André Rung syslog-192.168.0.175.log

Nope, there is no lost+found on /mnt/disk4

Nope, how do I do that? I checked /mnt/disk4 and I didn't find anything... should I put it back in maint mode?

OK, thank you. I'll keep an eye on the syslog. Best regards, André Rung

Array started, any other check or should I just wait for the next kernel panic and keep checking the filesystems? Best regards, André Rung

OK... done... Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 bad CRC for inode 2263658379 bad CRC for inode 2263658379, will rewrite cleared inode 2263658379 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Should I start the array now? Best regards, André Rung

Ok, filesystem checked with -n flag: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 bad CRC for inode 2263658379 bad CRC for inode 2263658379, would rewrite would have cleared inode 2263658379 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 2 bad CRC for inode 2263658379, would rewrite would have cleared inode 2263658379 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... Metadata corruption detected at 0x469ae8, inode 0x86ecaf8b dinode couldn't map inode 2263658379, err = 117 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 2263658380, would move to lost+found Phase 7 - verify link counts... Metadata corruption detected at 0x469ae8, inode 0x86ecaf8b dinode couldn't map inode 2263658379, err = 117, can't compare link counts No modify flag set, skipping filesystem flush and exiting. What now? Should I run it again with a different check? Best Regards, André

Hello, no luck... kernel panic again this morning. Apr 6 02:00:14 Tower emhttpd: read SMART /dev/sdi Apr 6 02:00:20 Tower emhttpd: read SMART /dev/sdh Apr 6 02:00:27 Tower emhttpd: read SMART /dev/sdk Apr 6 02:00:33 Tower emhttpd: read SMART /dev/sdd Apr 6 02:00:42 Tower emhttpd: read SMART /dev/sde Apr 6 02:00:49 Tower emhttpd: read SMART /dev/sdf Apr 6 02:16:16 Tower emhttpd: spinning down /dev/sde Apr 6 02:16:18 Tower emhttpd: spinning down /dev/sdd Apr 6 02:16:18 Tower emhttpd: spinning down /dev/sdf Apr 6 02:26:51 Tower emhttpd: spinning down /dev/sdk Apr 6 02:28:42 Tower emhttpd: spinning down /dev/sdi Apr 6 02:28:43 Tower emhttpd: spinning down /dev/sdh Apr 6 02:58:10 Tower emhttpd: read SMART /dev/sdf Apr 6 03:13:11 Tower emhttpd: spinning down /dev/sdf Apr 6 03:31:07 Tower emhttpd: read SMART /dev/sdd Apr 6 03:31:15 Tower kernel: XFS (md4): Metadata corruption detected at xfs_dinode_verify+0xa3/0x581 [xfs], inode 0x86ecaf8b dinode Apr 6 03:31:15 Tower kernel: XFS (md4): Unmount and run xfs_repair Apr 6 03:31:15 Tower kernel: XFS (md4): First 128 bytes of corrupted metadata buffer: Apr 6 03:31:15 Tower kernel: 00000000: 49 4e 41 f8 03 01 00 00 00 00 00 63 00 00 00 64 INA........c...d Apr 6 03:31:15 Tower kernel: 00000010: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 6 03:31:15 Tower kernel: 00000020: 60 63 d6 e8 0e 05 5a fa 60 63 d6 e8 0e 33 21 ed `c....Z.`c...3!. Apr 6 03:31:15 Tower kernel: 00000030: 60 63 d6 e8 0e 33 21 ed 00 00 00 00 00 00 00 1b `c...3!......... Apr 6 03:31:15 Tower kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 6 03:31:15 Tower kernel: 00000050: 00 00 00 02 00 00 00 00 00 00 00 00 a5 a7 6c 21 ..............l! Apr 6 03:31:15 Tower kernel: 00000060: ff ff ff ff 0a 41 8c 46 00 00 00 00 00 00 00 04 .....A.F........ Apr 6 03:31:15 Tower kernel: 00000070: 00 00 00 1b 00 1a f3 e3 00 00 00 00 00 00 00 00 ................ Apr 6 03:31:15 Tower kernel: XFS (md4): Metadata corruption detected at xfs_dinode_verify+0xa3/0x581 [xfs], inode 0x86ecaf8b dinode Apr 6 03:31:15 Tower kernel: XFS (md4): Unmount and run xfs_repair Apr 6 03:31:15 Tower kernel: XFS (md4): First 128 bytes of corrupted metadata buffer: Apr 6 03:31:15 Tower kernel: 00000000: 49 4e 41 f8 03 01 00 00 00 00 00 63 00 00 00 64 INA........c...d Apr 6 03:31:15 Tower kernel: 00000010: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 6 03:31:15 Tower kernel: 00000020: 60 63 d6 e8 0e 05 5a fa 60 63 d6 e8 0e 33 21 ed `c....Z.`c...3!. Apr 6 03:31:15 Tower kernel: 00000030: 60 63 d6 e8 0e 33 21 ed 00 00 00 00 00 00 00 1b `c...3!......... Apr 6 03:31:15 Tower kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 6 03:31:15 Tower kernel: 00000050: 00 00 00 02 00 00 00 00 00 00 00 00 a5 a7 6c 21 ..............l! Apr 6 03:31:15 Tower kernel: 00000060: ff ff ff ff 0a 41 8c 46 00 00 00 00 00 00 00 04 .....A.F........ Apr 6 03:31:15 Tower kernel: 00000070: 00 00 00 1b 00 1a f3 e3 00 00 00 00 00 00 00 00 ................ Apr 6 03:31:15 Tower emhttpd: read SMART /dev/sde Apr 6 03:32:05 Tower emhttpd: read SMART /dev/sdi Apr 6 03:32:11 Tower emhttpd: read SMART /dev/sdf Apr 6 03:32:20 Tower emhttpd: read SMART /dev/sdj Apr 6 03:32:22 Tower emhttpd: read SMART /dev/sdg Apr 6 03:34:28 Tower emhttpd: read SMART /dev/sdh Apr 6 03:40:09 Tower crond[1835]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Apr 6 03:46:16 Tower emhttpd: spinning down /dev/sdd Apr 6 03:46:16 Tower emhttpd: spinning down /dev/sde Apr 6 03:47:12 Tower emhttpd: spinning down /dev/sdf Apr 6 03:56:41 Tower emhttpd: spinning down /dev/sdi Apr 6 03:56:55 Tower emhttpd: spinning down /dev/sdj Apr 6 03:56:55 Tower emhttpd: spinning down /dev/sdh Apr 6 03:56:55 Tower emhttpd: spinning down /dev/sdg Apr 6 10:20:24 Tower root: Delaying execution of fix common problems scan for 10 minutes Anyway I can workaround this issue? Best regards, André Rung

Ok, I have switched to option (5). Let's see if it does any difference. Thank you, André Rung