RikStigter

Arg, I missed the 'Tools > Registration' bit. Sorry about that!

Hi, I'm replacing my Flash-drive (reason: to small for an upgrade to 7.0.1 from 7.0.0). It seems the procedure from https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/ has changed, because folowing this procedure I'm asked to acquire a new license. It tells me there are multiple licenses on the new flash-drive. What is the correct procedure now? Sincerely, Rik Stigter

Interesting to note this happened again this morning on one of my servers after an update of said Plug-in. I've removed the Disk Location Plug-in and the dashboard reappeared. Will monitor this to see whether a newer version will solve this issue.

I've been having the same for a while now on my HP Microserver Gen10. Replacing the USB drive did not solve this. After I run chkdsk on a Windows system on this drive, it updates normally, although it doesn't find any problems with the drive. I'm curious to know if you have the same experience once you done that.

Changing the cable doesn't have any influence, the CRC errors keep mounting. Since this system (a HP Microserver gen10) doesn't have any spare ports left I'll try testing the combo on a different system to see whether I get CRC errors there as well. Done, no errors... Weird. Next I'll do a full 'surface' scan, but meanwhile I'm going to replace the drive cf. the instructions on-line and see what happens next. That will mean reinstalling the single docker (syncthing) I have running on this particular system, but that is easily done. I don't trust anything on this drive, so -recreating some shares on the cache drive etc. is probably wise anyway. It's a simple backup-server so that is no big hassle (I wouldn't recommend doing this on a more complex system). I've managed to save the backup-files to the array on the 'data' share, so this means I'll only have to recreate the appdata share. Done that. Server (so far) runs without errors on the cache drive (with new cable on same SATA-port). Will make new config's for all backups in syncthing and see what happens. Will update if and when new findings. 🙂 After an hour or two no errors on the SSD in use as cache. A surface scan of the old SSD doesn't find any problems. Gremlins?

I have a peculiar problem with my cache drive in one of my servers, a Crucial MX500 1 TB on latest firmware (as recommended): I get CRC-errors on this drive It also shows up as an 'unassigned device' I cannot write to it, 'Fix Common Problems' reports it's read-only I cannot stop the array unless I reboot (and then stop the array before it loads the services) On reboot it starts a parity check This all started after a firmware upgrade that succeeded uneventfully, or so it seemed. Diagnostics attached. I have a spare drive so I would replace it, but I'd rather know what's going on! citadelle-diagnostics-20230627-0920.zip

I can confirm the configuration was still there after upgrading NUT to SimonF's version. Easy upgrade therefore!

Ah, see there is a new version. I thought I was on te latest. II'll update ASAP. Thanx again!

Hello JorgeB Got back this: parent transid verify failed on 531043008512 wanted 616473 found 616472 parent transid verify failed on 531043008512 wanted 616473 found 616472 Couldn't setup log root tree Clearing log on /dev/sdf1, previous log_root 531043008512, level 0 After a reboot everything seems to be OK once again. Dockers are all back. Many thanks! Rik

Some additional info: I had copied some files to the cache and after 3 hours these normally get moved to the array. I'm not sure whether that has had any impact to this problem, but 'gut feeling' says it might. My gut might be wrong. The system is a HP Microserver gen8 (I think you'll be able to see that from the diagnostics file, but nevertheless...) I had already planned some maintenance so I did that this mornbing while I was testing the drive. So it now has a new fan, all dust cleared out (althought t never ran hot, but that is what maintenance is for) and all connectors have been re-inserted. The cache drive is visible to the system, but unformatted. The 'appsdata'-share is totally empty (ths is where the docker files would have resided) My second server (a HP Microsrver gen10) has no problems at all, but 'll check again after copying some fle to it's fle-system

Hi, After an upgrade to 6.12 my system worked fine, but several hours later my cache-disk became unreachable and all dockers failed. The cache-drive sits on a Crucial MX500 2TB, with latest firmware. After extracting it and testing it, it appears that the file-system has gone. I reinserted it in the server. Diagnostics attached. How to proceed from here? Should I erase the disk and rebuild the dockers (It's only three active dockers and they aren't to complex to reinstall)? tower-diagnostics-20230616-0718.zip

Thanks a lot!

LS. About three weeks ago I replaced my flash drive (with the flash tool on a somewhat older Toshiba 2GB USB2 drive that I had lying around) because I was getting errors (on the previously used Sandisk 32GB USB3.0 thumb-drive) while upgrading to 6.11. Now while I'm trying to upgrade to 6.11.1 my 'new' flash drive (The Toshiba/TransMemory drive that I had thoroughly checked before starting to use it) seems to fail again. System is a HP Micrcoserver Gen10. Message while upgrading is: *** bad sha256 on /boot/unRAIDServer/bzroot *** *** The upgrade failed, but no changes were made to your configuration. *** Your USB Flash is likely failing. *** plugin: run failed: /bin/bash Executing hook script: post_plugin_checks I have bought a new drive (a Transcend 4GB USB 2.0 drive) but cannot replace the flash drive before Tue 19 Sep 2023 03:38:24 PM CEST Sincerely yours, Rik Diagnostics attached citadelle-diagnostics-20221008-0828.zip

I have the same problem. Perhaps it is good to know that I already used the 'My Servers'-plugin on 6.9.2. On my other system I didn't have that particular plugin installed and on that one the upgrade went flawlessly. The system that I cannot access is a headless one, so it is a problem. All other aspects of the server (File-access, SSH, Dockers) are running without any problems.

Thanks for that! It fixed my problem accessing from 'outside'.