I just moved a storagenode from 64bit ubuntu onto 32bit raspian and on start up the storagenode would not go online.
It seems the db are not compatible.
Just a note of caution 
Edit to say changed title as it is suspected that 32bit is not the problem
I really doubt it, but wait for an answer from someone who knows for sure.
It’s maybe more a permission problem.
Is it starting?
If so, then use a standard Offline troubleshooting:
Could the db be corrupted if I missed the last rsync --delete step
i.e. if odd db.shm are still around?
Then you will see an error in the logs.
Do you see them?
Is the container restarting?
Most of the time when I was moving databases it was either that I missed the --delete option or they simply corrupted. Copying them again fixed the issue most of the time.
On a different occasion I had to vacuum all dbs which fixed the issue.
I would like to suggest to check all databases if you are not sure
but if you don’t do the delete step wouldn’t you end up with zombie data if the node has been running while doing the rsync…
the only thing the -delete step does is make sure the two folders are exactly the same… which it usually does and if there is something to much in the new folder the it will delete it.
usually one can go from 32 to 64 no trouble, however going back can usually be a problem… yet the storj image atleast in docker is what is running… so that shouldn’t be a problem
and well the data and the database… well that should really be the same… in the case of docker tho i would make sure you pulled the newest image and the correct arm32 image…
why do you think it’s 32bit anyways… do they even make 32bit cpus anymore…
the arm64 or amd64 can be easily interchanged… so make sure you a pulling the right one… amd32 or arm32 whatever…
this seems to be the last true 32bit arm cpu… announched in 2011, so yeah… you sure its a 32bit… because if you can do 64bit you want to do 64bit, some things are like 10 times faster
Yes, if the old db-wal files are still there you have duplicate data, these wal files are merged into the db files then the node is stopped. The --delete parameter on the last run while the node is stopped is not optional for this reason. So if you omitted it, that is likely what caused the corruption. If your node hasn’t run since, I recommend copying the db files manually, with the node stopped of course. That should fix it.
I updated the title as it now seemed misleading.
I’ve lost the bandwidth db but it is only 5$ missing in the dashboard as far as I can tell.
It’s still passing audits.
will most likely take time to update, from what i understand most of the data related to that is actually gotten from the satellites, so should correct itself…
lately my earned have been going backwards every time i reboot the node…
also the dashboard earning estimation is also still very new, so take it with a grain of salt…
don’t worry, be happy… 