Good morning everyone,

Unfortunately, last night both my USB flash drive and my cache SSD seem to have stopped working. I noticed the problem only tonight because I couldn't access it. Disconnecting the USB, my computer reads it without problems, but I can't copy the "docker.cfg" file. Could that be the issue?

Tomorrow I'll get a new USB drive. I have 3 data disks and 1 parity disk (it just finished parity yesterday morning). I hope not to lose anything, but at worst, I hope to at least keep the data on the disks. Unfortunately, I can't turn off the array or extract diagnostics. Below is an excerpt of the errors I've seen repeating throughout the syslog.

Quote

 

Dec 10 22:22:08 Tower kernel: fat__get_entry: 1382166 callbacks suppressed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29616) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29617) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29618) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29619) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29620) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29621) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29622) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29623) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29624) failed
Dec 10 22:22:08 Tower kernel: FAT-fs (sda1): Directory bread(block 29625) failed
Dec 10 22:22:13 Tower kernel: fat__get_entry: 1861014 callbacks suppressed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29616) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29617) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29618) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29619) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29620) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29621) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29622) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29623) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29624) failed
Dec 10 22:22:13 Tower kernel: FAT-fs (sda1): Directory bread(block 29625) failed
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [103e44d8]
Dec 10 22:22:14 Tower kernel: SQUASHFS error: Unable to read page, block 103e44d8, size 809c

 

 

 

 

Sorry if this isn't useful information, but unfortunately, my knowledge is limited in this area. Currently, my Unraid is ON, but not being able to read the USB, I can do practically nothing. I fear that if I try a restart, it might not boot from the USB...

Trying to recover the key tells me success but error at the same time (?) see attached photo.

Thanks to everyone who will write me advice; it's my post on this forum that has saved me more than once in the past.

 

 

Do you have a backup of that boot drive?  (Even an old one)

 

Get screenshots of all of the setup screens that have settings that you might need if you have to start from scratch.  (Especially the   MAIN   Tab!) 

 

Do you remember the E-mail address that you used when you request your original license?

 

If you can't not find a copy of the     xxxxxxx.KEY    file, you will have to contact support   (<---- Click on the link embedded in that phase.)  and provide them with the details of your problem.  

 

Leave everything as it is for now and other folks may have some other thoughts about a solution.  Take a few deep breaths and relax as much as possible.  (I have observed that actions taken when one is in a panic mode causes even bigger problems than the initial problem...)

Edited December 11, 20232 yr by Frank1940

Thanks for the reply! the fact that this thing is still on has made me feel calmer. I managed to make a copy from Windows Explorer of the contents of the stick currently connected to the unraid, including the Basic.key, is that the file with the license? however, I know the email from which it was purchased.
in theory I had made a flash backup months ago but I can't find it and I can't access "/boot/config" from my unraid... can i recover my configuration using any this files? 

 

1 hour ago, DottorFranky said:

the Basic.key, is that the file with the license?

Yes.  That file is the license!

9 hours ago, DottorFranky said:

can i recover my configuration using any this files? 

The super.dat file is the one that contains your drive configuration.

 

The .cfg files are reasonably obvious and are human readable text if you want to check them.  If you find any that do not contain text they will be corrupt and should be discarded so their contents can be recreated with default settings.

2 hours ago, itimpi said:

The .cfg files are reasonably obvious and are human readable text if you want to check them.  I

This is true but there is one problem, there are a few of them that use the Linux character (LF) rather than the Windows (CR LF) for the end of a line of text.  So you must use an editor that is aware of this.  Windows Notepad now appears to be aware of this situation but does so in the background.  (In this recent past, it was not aware and the text while 'readable' had obvious formatting issues.  IF you fixed the formatting issues that Windows Notepad had with a Linux file, then the file was not usable by Linux!)  

 

If you have problems, look for a simple text editor that can deal with this situation.  (I have used EditPad Lite as my default text editor for years as it handles all three line endings cleanly.  MacOS uses (CR) for its line Ending character. to make things totally confusing!)  Google will be your friend if you want to find other editors that can handle the line ending issue more gracefully than, say, Notepad does.

 

As a matter of information,  This whole thing goes back to the Teletype machines being developed beginning in the 1920's and really became main stream in WWII.   The <CR> character (carriage return) returned the print head to the ending of the line.  The <LF> character (line feed) moved the paper up to allow for a new line of text.  Even further back. you can also think of a Manual typewriter where the carriage return lever first returns the 'carriage' back to the stop on the left side of the paper and then advances the paper for the start of new line of text.  When printers were first developed for use with computers, these concepts of the <CR>  and <LF> being separate operations was carried forward.  But it was confusing and, thus, in the initial setup of printers for use, one told the printer what action the printer did when it got one of these characters.  (There was an advantage to having this generation of printer technology just return back to the beginning of a the line.  You could then reprinted the entire line of text creating a "bold text" appearance!)