I need your help with a migration issue. I’m trying to migrate my three nodes, currently on 3 disks in an HP server, to a Raspberry Pi 4 equipped with a USB HDD dock to reduce power consumption.
On the HP server, I’m running Debian 12 and my nodes are running in a Docker container.
On the Raspberry Pi, I’m running Raspbian where I already have other Docker containers running without issues.
I have disconnected and reattached my disks to the Raspberry Pi – no problem accessing the files.
I have also copied the identity files to the correct folder.
However, when I try to launch the Docker container, I get the error below on a loop. Could this be because I’m moving from the x86 architecture of the HP server to the ARM architecture of the Raspberry Pi?
2024-10-13 16:08:00,704 WARN exited: storagenode-updater (exit status 127; not expected)
2024-10-13 16:08:01,705 INFO success: processes-exit-eventlistener entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-10-13 16:08:01,709 INFO spawned: 'storagenode' with pid 20
2024-10-13 16:08:01,713 INFO spawned: 'storagenode-updater' with pid 21
supervisor: couldn't exec /app/bin/storagenode: ENOEXEC
supervisor: child process was not spawned
2024-10-13 16:08:01,728 WARN exited: storagenode (exit status 127; not expected)
supervisor: couldn't exec /app/bin/storagenode-updater: ENOEXEC
supervisor: child process was not spawned
2024-10-13 16:08:01,730 WARN exited: storagenode-updater (exit status 127; not expected)
2024-10-13 16:08:03,736 INFO spawned: 'storagenode' with pid 22
2024-10-13 16:08:03,741 INFO spawned: 'storagenode-updater' with pid 23
supervisor: couldn't exec /app/bin/storagenode: ENOEXEC
supervisor: child process was not spawned
2024-10-13 16:08:03,754 WARN exited: storagenode (exit status 127; not expected)
supervisor: couldn't exec /app/bin/storagenode-updater: ENOEXEC
supervisor: child process was not spawned
2024-10-13 16:08:03,759 WARN exited: storagenode-updater (exit status 127; not expected)
2024-10-13 16:08:06,770 INFO spawned: 'storagenode' with pid 24
2024-10-13 16:08:06,778 INFO spawned: 'storagenode-updater' with pid 25
supervisor: couldn't exec /app/bin/storagenode: ENOEXEC
supervisor: child process was not spawned
2024-10-13 16:08:06,803 WARN exited: storagenode (exit status 127; not expected)
supervisor: couldn't exec /app/bin/storagenode-updater: ENOEXEC
supervisor: child process was not spawned
2024-10-13 16:08:06,807 INFO gave up: storagenode entered FATAL state, too many start retries too quickly
2024-10-13 16:08:06,812 WARN exited: storagenode-updater (exit status 127; not expected)
2024-10-13 16:08:07,814 INFO gave up: storagenode-updater entered FATAL state, too many start retries too quickly
2024-10-13 16:08:07,815 WARN received SIGQUIT indicating exit request
2024-10-13 16:08:07,815 INFO waiting for processes-exit-eventlistener to die
2024-10-13 16:08:09,821 WARN stopped: processes-exit-eventlistener (terminated by SIGTERM)
You need to remove the bin subfolder in the storage location of each disk and restart the container, it will re-download a correct binaries for your current platform.
Hmm yes, storage node disks (mounted under /app/config) used to be architecture independent until the recent changes.
Perhaps the binaries in /app/config/bin should have an architecture suffix so if a disk is migrated to a different architecture the current one is noted as missing, downloaded and copied to /app/bin (without a suffix).
I know moving architectures is done rarely, but probably often enough to be worth the extra robustness.
I disagree. Data shall be portable. It already is.
Now that executables were made part of data, they too shall be portable. Suffixes is just as good way to accomplish this as any.
However the better solution is not to store executables with data in the first place. There is no need. It’s sufficient to store last seen minimum version, in the text file, and have updater download storagenode of no older than that version.
This is much simpler soliton than having to copy files around and tying data to machine architecture — the very thing containers are supposed to abstract. (This approach was suggested before, but for some reason the inferior design of copying executables was selected).
Basically, now it’s broken, and needs to be fixed.
Error: Error opening database on storagenode: Cannot acquire directory lock on "config/storage/filestatcache". Another process is using this Badger database. error: resource temporarily unavailable
The first error was something like: txt … app/bin/ but I didn’t note it down, my fault, I thought it was related to the Bin subfolder, so I stopped the node, removed it, trashed the bin folder and recreated it. At this point the Badger error came out. I solved one problem by also trashing the Filesatecache folder, and after a search on the forum, I deleted revocations.db and it started normally.
Same procedure for the other node and it has started working again