Storj node lost video

Shortly after I started my V3 node (1nMf1zdGZLC2yf6vpZduRyBfiWRpP4TiGfmoBrXz2izW38XEXa) my Nvidia 440.26 driver stopping working. This is a headless Linux Mint 19.2 computer. Storj seems to be working well. I’ve completely removed my Nvidia graphics driver and reinstalled it. Every time I remote into the computer I get a warning that there is no video driver & should the Driver Manager be opened. I cannot use my GPU and need to get it back. I don’t know if Storj caused this but it’s the only time I’ve ever seen this happen and I’ve run dozens of computers in my calc cluster for years. If nothing else how can I preserve my Storj Node and rebuild my computer from scratch to get my GPU back???
nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running. sudo inxi -v 3
System: Host: Rig-01 Kernel: 4.15.0-70-generic x86_64 bits: 64 compiler: gcc v: 7.4.0
Desktop: Cinnamon 4.2.4 Distro: Linux Mint 19.2 Tina base: Ubuntu 18.04 bionic
Machine: Type: Desktop System: ASUS product: All Series v: N/A serial: N/A
Mobo: ASUSTeK model: X99-E v: Rev 1.xx serial: 170501556900092
UEFI: American Megatrends v: 2101 date: 07/10/2019
CPU: Topology: 18-Core model: Intel Xeon E5-2686 v4 bits: 64 type: MT MCP
arch: Broadwell rev: 1 L2 cache: 45.0 MiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 165494
Speed: 2598 MHz min/max: 1200/3000 MHz Core speeds (MHz): 1: 2598 2: 2598 3: 2598
4: 2598 5: 2598 6: 2598 7: 2598 8: 2598 9: 2598 10: 2598 11: 2598 12: 2598 13: 2598
14: 2598 15: 2598 16: 2598 17: 2598 18: 2598 19: 2598 20: 2598 21: 2598 22: 2598
23: 2598 24: 2598 25: 2598 26: 2598 27: 2598 28: 2598 29: 2598 30: 2598 31: 2598
32: 2598 33: 2598 34: 2598 35: 2598 36: 2598
Graphics: Device-1: NVIDIA GP102 [GeForce GTX 1080 Ti] vendor: driver: N/A
bus ID: 01:00.0
Display: server: X.Org 1.19.6 driver: fbdev,nouveau unloaded: modesetting,vesa
resolution: 800x600~75Hz
OpenGL: renderer: llvmpipe (LLVM 8.0 256 bits) v: 3.3 Mesa 19.0.8
direct render: Yes
Network: Device-1: Intel Ethernet I218-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k
port: f000 bus ID: 00:19.0
IF: eno1 state: up speed: 1000 Mbps duplex: full mac: 88:d7:f6:e2:58:3a
IF-ID-1: docker0 state: up speed: N/A duplex: N/A mac: 02:42:40:4d:64:0b
IF-ID-2: vethb76e424 state: up speed: 10000 Mbps duplex: full
mac: 86:3c:db:78:6d:ab
IF-ID-3: vethf66e577 state: up speed: 10000 Mbps duplex: full
mac: fe:3c:27:30:7f:6c
Drives: Local Storage: total: 931.51 GiB used: 1.35 TiB (148.8%)
Info: Processes: 539 Uptime: 7d 14h 33m Memory: 31.32 GiB used: 21.90 GiB (69.9%)
Init: systemd runlevel: 5 Compilers: gcc: 7.4.0 Shell: bash v: 4.4.20 inxi: 3.0.32

I am lost here. Can you please elaborate how used is more than total ?

Yea, me too. I first saw that after Storj made a huge deposit. When I installed V3 I specified 70% of my SSD. I know of no way to change that now. Disks says:
1000 GB — 239 GB free (76.1% full)

Storage Node Dashboard ( Node Version: v0.26.2 )

ID 1nMf1zdGZLC2yf6vpZduRyBfiWRpP4TiGfmoBrXz2izW38XEXa
Last Contact ONLINE
Uptime 3m42s
Available Used Egress Ingress
Bandwidth 37.0 TB 21.4 GB 21.3 GB 22.1 MB (since Nov 1)
Disk 256 B 0.7 TB

  1. I highly doubt that storj is to blame for your problem
  2. Why do you care about a graphics driver on a headless PC?
  3. to change the allocated storage, stop the container, remove it and run your docker start command with the adjusted value

As I said in the first post it’s part of a calc cluster. The GPU is idle now & I need it back to work.
Well that’s your opinion but it’s strange how none of my other 40 computers have never reported Used being greater than Total disk capacity.
If it wasn’t for being a Storj node and I only get one node now, unlike V1 & V2, I’d just rebuild the computer from scratch. Is there a way I can reformat my drive and reinstall my Storj node???

There shouldn’t be a problem with that as long you stop your node properly first… and it’s a good idea to complete the data transfer and rebuilding within a 5 hour window, even though the uptime disqualification parameter is currently ignored.

Make sure you’ve copied all data as well as the database files and your identity files… If miss any data at all, your node will mostly likely eventually be disqualified for that lost data.