Hi, after a lock up and a forced reeboot I have encountered REBOOT AND SELECT PROPER BOOT DEVICE.

I have checked the BIOS priorities and I am not able to get it to boot even when the USB is the primary option.

Please advise.

I am running 6.9 I think

Try recreating the flash drive, first backup the current one, then recreate it using the USB tool, confirm the flash drive boots with the stock install, and if yes, restore only the /config folder from the backup overwriting any existing files.

Does it matter which version I create? I'm not 100% sure which I was running but I know that it was not the latest.....

Also this is the usb I was using - it appears to no longer have a GUID?

Edited June 3Jun 3 by folic86

You can try and ignore the missing GUID message, and manually recreate the flash drive.

You can ignore that message.

OK so this worked but it has now got a failed parity drive and is wopr-diagnostics-20260603-1709.zipocking up/becoming unreachable from the network..... how screwed am I?

Edited June 3Jun 3 by folic86

First thing, this disk appears to be having power/connection issues:

Device Model: ST18000NM000J-2TV103

Serial Number: ZR53Z3RQ

Check/replace its cables and post new diags.

I have now resolved the disk connection issues but still have a failed parity drive - any suggestions? Can't believe how expensive hdds are right now! wopr-diagnostics-20260828-2022.zip

55 minutes ago, folic86 said:

I have now resolved the disk connection issues but still have a failed parity drive - any suggestions? Can't believe how expensive hdds are right now! wopr-diagnostics-20260828-2022.zip

I didnt see any obvious issues with disk health in the SMART report (no reallocated/pending sectors or offline uncorrectable errors) so what I suggest doing is:

Tools, New config, preserve ALL slots, then check "parity is valid" and start the array then run a correcting parity check. This will update parity2 bits that are out of alignment with the rest of the array

however before running this, maybe wait for @JorgeB to confirm this is the proper way forward.

Edited August 28Aug 28 by MowMdown

Thanks for the suggestion, I'm rebuilding the unattached drive and then will proceed if advised that is the right way

Is disk5 finished rebuilding?

currently at 96.8% but disk 11 is showing over 1,000,000 errors and has unmounted!

wopr-diagnostics-20260830-1633.zip

1 hour ago, folic86 said:

disk 11 is showing over 1,000,000 errors and has unmounted

Not unmounted, disconnected. Different concepts.Those errors have filled syslog, and if disk5 weren't invalid and parity2 weren't already disabled I'm sure disk11 would have been disabled.

Since parity2 is disabled and disk5 rebuild hasn't completed I don't see how you can finish disk5 rebuild since you are now missing disk11 from the parity calculation. Stop, shutdown, check connections, reboot and post new diagnostics with the array started in Normal (not Maintenance) mode.

3 hours ago, trurl said:

Not unmounted, disconnected. Different concepts.Those errors have filled syslog, and if disk5 weren't invalid and parity2 weren't already disabled I'm sure disk11 would have been disabled.

Since parity2 is disabled and disk5 rebuild hasn't completed I don't see how you can finish disk5 rebuild since you are now missing disk11 from the parity calculation. Stop, shutdown, check connections, reboot and post new diagnostics with the array started in Normal (not Maintenance) mode.

The rebuild completed before I got to it to shutdown. Can you advise? Still shutdown and check connections?wopr-diagnostics-20260830-2127.zip

wopr-diagnostics-20260830-2240.zipUpdated diags after a reboot.

All disks mounted, including now disabled/emulated disk11. But syslog indicates some corruption on disk11.

Did you check any of your connections before rebooting?

9 hours ago, trurl said:

All disks mounted, including now disabled/emulated disk11. But syslog indicates some corruption on disk11.

Did you check any of your connections before rebooting?

I did but I can try again?

Check filesystem on emulated disk11 from the webUI and post the output.

it had corruption so I ran a fix on the XFS drive

now says

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
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 2
        - agno = 7
        - agno = 11
        - agno = 6
        - agno = 3
        - agno = 1
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 4
        - agno = 5
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

Note that was just a check - not an actual fix. As you can see at the end you had the ‘no modify’ flag set. Were you offered a ‘Fix’ button after the check completed? If not there was probably nothing to fix.

I was, yes. It moved some files to lost+found. I then rechecked and got no fix option

wopr-diagnostics-20261007-1657.zip

10 minutes ago, folic86 said:

I was, yes. It moved some files to lost+found. I then rechecked and got no fix option

wopr-diagnostics-20261007-1657.zip

That makes sense. The first run fixed what it found and the second one then found no new errors.

Files ending up in lost+found means that the repair process could not find the directory entry to give them their correct path/filename. These, unfortunately, typically end up with cryptic numeric names and need manual inspection to work out what they are to then correct the path/name. The Linux ‘file’ command can at least tell you what type of content is in a file which can help the manual process.

Having said that if you have decent backups it is probably easier to restore any missing files from them and then delete the lost+found folder and irs contents.

the drive sadly still shows as emulated?

20 hours ago, folic86 said:

the drive sadly still shows as emulated?

The emulated disk was repaired, but it still needs to rebuild the repaired contents to the physical disk.

Since repair resulted in some lost+found, it might be worth seeing if the physical disk can be mounted with Unassigned Devices and decide if the physical contents are better than the repaired emulated disk contents.