rynojvr

Hello, I was attempting to upgrade my Unraid to a newer version, then had issues with it not shutting down for over 40 minutes, then messed up by hard shutting down, causing the flash drive to break. Was able to get a new flash drive working, but the only config was from a couple months ago, and a previous layout of disks. Between then and now, I'd upgraded the parity drive and moved it into the rotation of disks; now, the disk with data on it was assigned to be the parity (as it was in the old days), and because of an oversight, I started the array. Not too long after, I noticed there was an unassigned drive (the one that held the current parity data, but the old config wasn't aware of), and immediately recognized my mistake. Now, I'm unable to mount that drive at all. Based on some of the errors, I'm hoping the data is relatively intact in the middle of the drive/blocks, and it's mainly the headers that are broken. For debugging, it is `/dev/sde`, the 6 TB drive that is the one failing to mount. dmesg when mounting: [140844.853987] XFS (sde1): Failed to read root inode 0x80, error 117 [140868.791678] XFS (sde1): Mounting V5 Filesystem [140868.891545] XFS (sde1): Metadata corruption detected at xfs_dir2_sf_verify+0xbf/0x1d8 [xfs], inode 0x80 data fork [140868.892386] XFS (sde1): Unmount and run xfs_repair [140868.893073] XFS (sde1): First 117 bytes of corrupted metadata buffer: [140868.893752] 00000000: 0a 04 00 00 00 00 00 00 00 80 05 00 60 4d 65 64 ............`Med [140868.894404] 00000010: 69 61 02 00 00 00 00 00 00 00 83 04 00 78 52 79 ia...........xRy [140868.895125] 00000020: 6e 6f 02 00 00 00 02 06 74 5c 4d 05 00 88 47 61 no......t\M...Ga [140868.895825] 00000030: 6d 65 73 02 00 00 00 01 8b 36 02 a4 03 00 a0 76 mes......6.....v [140868.896536] 00000040: 6d 73 02 00 00 00 02 8f 90 aa 48 11 00 b0 72 65 ms........H...re [140868.897228] 00000050: 73 69 6c 69 6f 5f 64 6f 77 6e 6c 6f 61 64 73 02 silio_downloads. [140868.897927] 00000060: 00 00 00 01 01 e1 9b 07 00 00 00 00 00 00 00 00 ................ [140868.898632] 00000070: 00 00 00 00 00 ..... [140868.899342] XFS (sde1): Failed to read root inode 0x80, error 117 The final output of running `xfs_repair` on the drive: .......................................................................................................................................................................Sorry, could not find valid secondary superblock Exiting now. If there are any other actions/logs I need to attach/run please let me know. vault-diagnostics-20231123-1111.zip

Yeah, it feels like it's not loading the networking OS component. The onboard NIC isn't even registering a signal on the wire. The clue about networking is in the ifconfig output; the br0 interface has 169.254.0.0/16, where it should have a 192.168.0.0/24. I'm surmising there's a deeper issue, likely related the the SQUASHFS errors you were referring to, which at the end of the day resulted in the symptom of non-networking. In the mean time, I'll see if I can migrate to a different boot USB.

Here's the diagnostic info. tower-diagnostics-20210906-1059.zip

Additionally, is there a way to verify the authenticity/veracity of my Boot USB? I'll be making a backup as soon as the fan has been cleared of feces.

After a recent reboot, Unraid no longer is able to see the network at all; when booting, no activity lights from the network port, and on-screen, it gives a 169.254.0.0/16 address. While concerning, I was able to get it limping along after booting into "Safe Mode", (no plugins enabled). Rebooting from that (via the UI & safe), I am now no longer able to boot even in safe mode; the non-network issue now encompasses Safe Mode as well. I can log in with keyboard & monitor, viewing syslog has mentions of the USB being invalid, but I can't tell if that's a non-network connectivity issue, or a deeper situation to be investigated. Has anyone heard of such a situation, and, diagnostically, which data would help in finding a solution?