BalenaOS Boot Behavior Inconsistent

I’m working on adding support for the AMD v1000 processor just like this post here: Adding AMD v1000 BSP Support to balenaOS

I’ve followed the instructions in the thread and have been able to get a successful build for my board. I’ve successfully flashed and booted BalenaOS 4.21 onto the board.

When I boot the system, I see the system status spit out, it fails a couple of steps but most things pass with success and then the Balena splash image comes up.

Here’s a list of the errors that I see:
error: “exec “auplink” executable file not found in $PATH"stoage-driver=aufs”
[FAILED] Failed to start ‘Commit a transient machine-id on disk’

If I press ESC or an arrow key, I’m able to switch between the splash screen and the system status output, however this only seems to work soemtimes. It’s 50/50 whether pressing an arrow key results in the switching of screens (keyboard verified good).

This is also a development build so I do get access to tty1 console and am able to log in using ‘root’ as the user with no password. However, to get to the point of logging in seems to be random. If I power on the board and observe the monitor, it’ll eventually go to an empty black screen with a cursor at the top left corner. It seems by providing random input (arrow keys, ESC, alphabet chars) will eventually bring up the login prompt.

Even after logging in, it does seem to be finicky in that my keyboard input seems to only work 50% of the time, just like switching screens and I’m not sure what’s causing this behavior. I’ve also noted that it’s still possible to get back to the information debugging screen or the Balena splash image by pressing arrow keys or ESC. This causes the tty1 to stop inputting \r\n whenever I press enter so everything spits out on one line.

Given that this is not a supported processor, I expect to see some issues but I’m not quite sure where these issues are derived from. Does anyone have insight on what would be normal dev build boot behavior? Is it just as finicky as I’m observing or is this behavior out of norm?


If the system is booting sometimes, then it would be great to hop onto the machine via SSH (port 22222, user is root) and dump the dmesg output. If you put that dump somewhere public (I expect it to be quite long, perhaps use a GitHub gist) then share it here, we can take a look and see what stands out.


balena_os_dmesg.log (49.3 KB)

Here’s the dmesg dump.


I will make some of our balenaOS engineers aware and see if they can comment on the messages :+1:

Great progress!

The dropped keyboard input sounds like plymouth. See for more detail.

Can remove plymouth from the image itself… Or I can time characters by slowly typing and sometimes get to the point of logging in using root and then running plymouth quit

Then the input becomes sane.

if NetworkManager and ethernet are working, you should be able to ssh root@ip-of-device -p 22222 for the dev image.

I was able to SSH into the device. SSH seems to work just fine, not lost input or anything. I’ll experiment with removing plymouth from the image but it’ll be some time before I get around to it. Will post an update once I do.

After removing the ‘plymouth’ dependency, everything seems to be working just fine. Keyboard input is working consistently w/o any hiccups.

Thank you