[SOLVED] Losing array config with every reboot.

[jguest]

In the past week each time I've rebooted my server it has completely lost the config. I have to reassign each drive and recreate parity. I thankfully don't lose any data or drives. I can't think of anything major that has changed. Only recent change I can think of is setting up CA Backup / Restore Appdata.

 

I'm not even sure how to run a report. I just enabled syslog logging now to the cache drive to be able to catch it next time. I did some digging on google but didn't find anything related to my issue.

[trurl]

Be sure to boot from USB2 port. 

 

Go to Tools-Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post 

[jguest]

Thanks for the reply. Here is the attached zip.

tower-diagnostics-20200702-1847.zip

[trurl]

It is unable to write your disk assignment configuration (config/super.dat) to the flash drive for some reason, but it isn't clear why. Do you have the flash drive write-protected?

 

Are you booting from a USB2 port?

 

 

 

 

[jguest]

I haven't touched the flash in about a year. This issue only started last week. It is on a USB2 port. The flash doesn't have a write-protection switch.

 

I see that super.da.CA_BACKUP is there. I also see there are many files that were last modified today and yesterday, so that should rule out write-protection.

 

There is a super.dat folder last modified 6-23

 

Thanks for your help.

 

[trurl]

Looks like maybe your flash drive isn't labelled UNRAID as required.

[jguest]

Odd, it never has been. I'll work on that now.

[jguest]

Just tried to stop the array and I'm getting:

 

Array Stopping•Retry unmounting disk share(s)...   And it just hangs.

 

I backed up my usb in order to relabel. Not sure if I'm just going to have to force shut since it's stuck hanging.

[trurl]

When you stop the array it tries to update config/super.dat to record the started/stopped status of the array. That is how it detects unclean shutdowns. Ironically, you may be forced into unclean shutdown, though it isn't clear whether config/super.dat will show the array was stopped or started when you reboot.

 

[jguest]

Would it hurt to delete the folder super.dat on the drive? Maybe clearing these entries will allow it to write next time?

 

Thankfully all my disks are good right now so I shouldn't lose any data.

[jguest]

I just confirmed the disk was labeled UNRAID

[trurl]

super.dat is a file, not a folder. It is the file where your disk assignments are stored. If you delete it Unraid will not remember your disk assignments, and you will have to assign them all again. Which I guess is what is happening anyway.

 

Here are the syslog lines that get repeated every time you start the array or assign disks:

 

Jul  2 13:15:44 Tower emhttpd: shcmd (1587): modprobe md-mod super=/boot/config/super.dat
Jul  2 13:15:44 Tower kernel: md: unRAID driver 2.9.13 installed
Jul  2 13:15:44 Tower kernel: read_file: read error 21
Jul  2 13:15:44 Tower kernel: md: could not read superblock from /boot/config/super.dat
Jul  2 13:15:44 Tower kernel: md: initializing superblock
Jul  2 13:15:44 Tower kernel: mdcmd (1): label 0951-1665-E51B-FE31E9768465
Jul  2 13:15:44 Tower kernel: write_file: error 21 opening /boot/config/super.dat
Jul  2 13:15:44 Tower kernel: md: could not write superblock file: /boot/config/super.dat

I don't know if that label is referring to the volume label or if it is maybe the GUID of your flash or what.

 

In any case, since it can't write super.dat it can't record your disk assignments.

 

Is this the same flash drive you have been using?

 

I don't know what else to suggest except recreating it and restoring the config folder from your backup.

[jguest]

So I had a folder under config called super.dat, but no file name super.dat.  I'm not sure why, I've never messed with it intentionally.

 

I let windows repair the drive, deleted the super.dat folder and restored using a backup.

 

It now just booted with the correct configuration. Thanks for your guidance.

[trurl]

👍