(SOLVED) boot device failing or is it a different issue?

[spyd4r]

6.5.1

 

System reboots fine and starts array (all docker and VMs as well) then shortly after starts throwing errors into system log and then the array and boot device stop showing up in the GUI. It will clean itself up if i manage to stop and the array and restart it. then it comes back a short time later.. basically "root: error: /webGui/include/DeviceList.php: uninitialized csrf_token" repeats every 3 seconds.. 

 

I have tried safe mode with no plugins, but it still occurs.

 

if i am on command line, all commands still work.. I see all drives still mounted. seems specifically related to the GUI

 

I can only view Syslog, I can't grab the diagnostics.. clicking the download button does nothing in this state.

 

 

 

syslog.txt

Edited May 3, 2018 by spyd4r

[trurl]

 

6 minutes ago, spyd4r said:

Sorry for the pasted massive wall of text. Anywhere there are ... a lot of repeating messages have been deleted. I can only view the Syslogs, I can't grab the diagnostics.. clicking the download button does nothing in this state.

 

Can you get to the command line? See this "sticky" near the top of this same subforum:

 

https://lime-technology.com/forums/topic/37579-need-help-read-me-first/

 

[spyd4r]

Thanks, original post updated.

[spyd4r]

i believe i found the issue.. rootfs is full.. that would be a problem... not sure what would have been writing there.

 

rootfs          7.7G  7.7G     0 100% /
tmpfs            32M  904K   32M   3% /run
devtmpfs        7.8G     0  7.8G   0% /dev
tmpfs           7.8G     0  7.8G   0% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M  524K  128M   1% /var/log
/dev/sda1        15G  604M   14G   5% /boot
/dev/loop0      7.5M  7.5M     0 100% /lib/modules
/dev/loop1      4.5M  4.5M     0 100% /lib/firmware
/dev/md1        2.8T  2.2T  545G  81% /mnt/disk1
/dev/md2        1.9T  403G  1.5T  22% /mnt/disk2
/dev/md3        932G  983M  931G   1% /mnt/disk3
shfs            5.5T  2.6T  2.9T  48% /mnt/user
/dev/loop2       20G  5.4G   13G  30% /var/lib/docker
shm              64M     0   64M   0% /var/lib/docker/containers/257f2c0990a83681e4f5b727c1b4e869bb6e0585f1d5f7aa472ecbdc3f60c661/shm
shm              64M     0   64M   0% /var/lib/docker/containers/2c9bbf718dc7511d87bfe16ccc3d897b36ca00ab187ca029bfab49fd70c2ab47/shm
shm              64M     0   64M   0% /var/lib/docker/containers/3b79fbf05ec93b80f5b197615e28a3d4932ba2af044bad3b81492ad615cf88de/shm
shm              64M     0   64M   0% /var/lib/docker/containers/59ffcc298cea597ea692586c0e76e19a4ef0cf0f2eee39292ec9207dde4a689f/shm
shm              64M     0   64M   0% /var/lib/docker/containers/43c9fd068766213347e74357f858fe24b66f109076211725c2e1a17ec58a02f8/shm
shm              64M   16K   64M   1% /var/lib/docker/containers/07f17fc577d18809748b1b5c1071483bca58b75234a27d235a1476b89510e0a0/shm
shm              64M  8.0K   64M   1% /var/lib/docker/containers/c1c38f118da8ab78955e92da2644db3d59664bf1a9b4b853bcb9701a70781086/shm
shm              64M     0   64M   0% /var/lib/docker/containers/126ab033bdd99436f2c312f6ce203d938ffe292e6e26ca7c879748b6ff9e0f85/shm
shm              64M     0   64M   0% /var/lib/docker/containers/476690dff7345aa128198e46f35bd562654c86eaaa5436b5ac944e5b13811c75/shm
shm              64M     0   64M   0% /var/lib/docker/containers/29cae680dd61579e942b1040aba9fcc7bf3f14e9df62c700f780af6fc3ef7017/shm
shm              64M     0   64M   0% /var/lib/docker/containers/151be2a6eeb867e220da3e3988ec55d59f0e42b19a96b8e00577371381b5d765/shm
shm              64M     0   64M   0% /var/lib/docker/containers/389684805aa2c18d6c80d745c31a3a0a0d3dec985a924423267cf7e0eaac863a/shm
shm              64M     0   64M   0% /var/lib/docker/containers/5bf7caa000ddd1299bc434e3835366b4b1cbb4353dfecfec6cbc74f691cfffab/shm
/dev/loop3      1.0G   18M  904M   2% /etc/libvirt

 

[spyd4r]

found the culprit

 

jshridha/motioneye:latest was writing locally. yikes..