Trying to migration from on old HP server to a Raspberry Pi4

Node Operators FAQ
, , ,
1

Hello everyone,

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)

Thanks !

Aurelien

2

You seem to have mounted the disks with “noexec”.

What’s the output of mount and what’s the content of /etc/fstab?

3

Hello @Washu,
Welcome back!

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.

1 Like
4

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.

1 Like
5

I do not think that it’s worth it. Removing the folder or binaries out of it is a one time action.

6

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.

7

Thank you all,

Finaly I’ve solved my problem by deleting the bin directory and the container.

Everything looks ok and I’ve reduced my power consumption by 100W !
Let’s now see if the raspberry is stable over time.

2 Likes
8

It would probably make sense to have this step mentioned in this page.

2 Likes
9
1 Like