robr

thanks itimpi.... dead port on the hp elitebook... I would never have found that otherwise. next step?

yes, I can figure that out from serial numbers

Hi Friendly Neighbourhood Unraid People, I'm stuck again - the array has been off for some time during house renovations, but when I've gone to restart I've lost all of my drives. I did some tinkering like last time, but it hasnt helped. I now have no drives accessible in my array, but I can see them in Historical devices - sdc, sdd, sde, sdf. Can I simply make them mount using automount in the settings? thez00-diagnostics-20241007-1541.zip

thanks - running now... lets see how it goes, fingers crossed.

Thanks for helping.... Disk 2 utilisation should have been very low... I think I just had the shares set up on fill up mode while I populate the array from other sources. So it could be it was effectively empty. No format... ever. No backups. No, not in unassigned.

Hmmm... not there yet.... I still have Parity disabled and Disk 2 disabled and emulated. Array not protected... not sure what to do next. Appreciate suggestions! thez00-smart-20230307-2043.zip thez00-diagnostics-20230307-2041.zip

Hi There Unraid Friends, So I have run the check with -L... see the log attached. Am I good to go? I am nervous about being a noob and killing it.... xfs_repair log

Hi There, Thanks for above. I ran the check and got the following per screen cap. How do I Mount the filesystem to replay the log? Thanks Rob

Hi Everyone, I did a rennovation and moved office. I shut my array down and it has been offline for a couple of months. Just gone and fired it up... I was in a world of pain initially as the system wouldn't boot - I was getting a "Kernal Panic" and system shutdown message. I've since replaced USB key and updated and now its booting but Parity 1 is disabled, Disk 2 is disabled. There have been no hardware changes - simply shutdown in storage. I have attached the diagnostic. Appreciate any help Cheers Rob thez00-diagnostics-20230228-1947.zip

Thanks Kilrah - found it. Yes, its nothing to do with Postgres, my github was blocked by odd DNS "change". Thanks for the suggestion.

Hi All, Trying to install Postgres14 and get following error. Appreciate suggestions on what I have going on here. Thanks

Luckily I am just transitioning across slowly, and learning as I go, so nothing totally lost, except my time. Once I get a new CPU to run the show (instead of the crappy old dell lappy) the plan was to set up a cache on an SSD, but that is for the future when time and $$ permit. (and a working UPS) In the meantime, if I run the procedure above will that get me back to square 1? Or is there more to do with the docker. (I dont run any VM). Thanks

Hi - just pre-empting next steps... is below appropriate from manual? Rebuilding a drive onto itself There can be cases where it is determined that the reason a disk was disabled is due to an external factor and the disk drive appears to be fine. In such a case you need to take a slightly modified process to cause Unraid to rebuild a 'disabled' drive back onto the same drive. Stop array Unassign disabled disk Start array so the missing disk is registered Important: If the drive to be rebuilt is a data drive then check that the emulated drive is showing the content you expect to be there as the rebuild process simply makes the physical drive match the emulated one. Is this is not the case then you may want to ask in forums for advice on the best way to proceed. Stop array Reassign disabled disk Start array to begin rebuild. If you start the array in Maintenance mode you will need to press the Sync button to start the rebuild.

Updated diagnostics and have re-run xfs_repair on disk 1 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 2147483777 bad CRC for inode 2147483777, will rewrite Bad mtime nsec 4182577976 on inode 2147483777, resetting to zero Bad ctime nsec 4182577976 on inode 2147483777, resetting to zero cleared inode 2147483777 - 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 = 1 - agno = 0 - agno = 2 - agno = 3 clearing reflink flag on inodes when possible 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 thez00-diagnostics-20220522-1356.zip

Thanks itimpi, I have attached the diagnostics. Yes I can see the expected content and can access the drives and content over my network. Appreciate your help! thez00-diagnostics-20220522-1133.zip