I’m a new user to BalenaCloud and am having trouble right from the start. I have managed to get a simple and generic Intel x64 MiniITX installed with BalenaOS, but the actual target I need to use is a SeeedStudio reComputerJ4012. I download the OS image provided on the Cloud Dashboard for the right platform, if I use 6.1.24 then the OS boots, but stops straight away with this showing on the serial console:
ˇ·Starting version 250.5+
zramctl: /dev/zram1: failed to set algorithm: Invalid argument
zramctl: /dev/zram1: failed to set algorithm: Invalid argument
zramctl: /dev/zram1: failed to set algorithm: Invalid argument
/init.d/12-zram: line 56: fail: command not found
If I try any of the older versions then they just fail to boot. Images are being written to USB sticks on macOS using BalenaEtcher.
How can I work around this to get the OS installed on my J4012? Any insight would be appreciated.
No, the install from the USB stick never happens, the NVMe storage in the J4012 doesn’t get touched and the installer doesn’t do anything after giving the error message in my first post. It’s still running now, hours later, doing nothing. Pushing Caps Lock changes the LED on the keyboard and pushing Enter on the serial console gives a carriage return, so it hasn’t crashed, it’s just stopped running the scripts it probably ought to be running to perform the install.
I’ve tried about 4 different older versions of the installer and they do variations on the same thing, or they don’t even boot at all.
I just tried provisioning a J4012 with 6.1.24 and observed the same behavior as well, even with placing the unit in forced recovery mode before flashing. I will confer with our OS engineers to see if perhaps a step is missing from the instructions and we will get back to you here.
Hello, for balenaOS versions v6.1.16 and newer, your device needs to be running UEFI firmware version 36.3. You can see how to check the firmware version and update it if necessary on this page: Provisioning Jetson Orin | balena
(This step will be added to the instructions.) Let us know if this helps!
Jetson UEFI firmware (version 4.1-33958178 built on 2023-08-01T19:34:02+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
** WARNING: Test Key is used. **
…
NVIDIA Orin NX Developer Kit
Not Specified 2.00 GHz
4.1-33958178 16138 MB RAM
I guess it’s very far behind if it’s version 4 instead of 36. I’ll update it as far up as I can and try BalenaOS again. Thank you!
I started working on the same machine right now. Flashing worked and the I/O seemed to work fine.
However, I struggled with getting a “proper” browser to run on that machine at all. Even a non-accelerated Chromium inside a container didn’t show up, and when trying with Xorg + NVIDIA drivers I kept hitting errors like failed to load driver: nvidia-drm and AddScreen/ScreenInit failed.
So my main questions are:
Has anyone managed to get Chromium (or any other browser) running on Jetson inside a container — either accelerated or not?
What’s the correct way to set up the NVIDIA/Xorg driver stack for containers? Do I need to bring in parts of JetPack, or is there a known clean setup?
Are there any recommended alternatives to Chromium for kiosk-style setups on Jetson (lightweight and ideally GPU accelerated)?
At this point I’m not sure if I’m missing something obvious in the driver/display setup or if this is simply not supported out of the box. Any hints or working examples would be really appreciated!
I’ve had it running by building the block from balenalib/%%BALENA_MACHINE_NAME%%-node:20-bookworm-run, running the service privileged with /dev/dri available, and dropping a simple /etc/X11/xorg.conf.d/20-tegra-fbdev.conf that uses the framebuffer driver (fbdev → /dev/fb0). The example XFCE container from balena-io-examples/jetson-orin helped confirm HDMI and Xorg first, though it’s also software-rendered.
With those tweaks Chromium starts and displays the kiosk URL, but chrome://gpu still shows “Software only / hardware acceleration unavailable”. I haven’t yet found a clean way to expose the Jetson NVIDIA EGL/GLES stack to the container, so if anyone has Chromium (or another kiosk browser) working with GPU acceleration inside a container on a Jetson, I’d love to hear how.
Built the balena browser block on top of balenalib/jetson-orin-nx-seeed-j4012-node:20-bookworm-run, pulling our custom Chromium (~3 GB) at runtime into /mnt/data and wiring Xorg (startx) with a fallback fbdev config. With /dev/dri mapped and the usual X packages installed, the kiosk comes up reliably.
That gets us to the same place as before though: chrome://gpu is still “Software only”. On our Orin NX dev kit running stock Ubuntu + JetPack 5.1.3 the exact same Chromium build reports full HW acceleration, so the binary itself is fine.
Digging through the balena hostapp we can’t find the Tegra EGL/GLES stack at all (libEGL.so, libGLESv2.so, libnvidia-egl-wayland.so, etc.), so the container only sees Mesa stubs. Until we can source those NVIDIA userspace libraries (and the matching /dev/nvhost-* nodes) inside the container, Chromium will stay in software mode.
If anyone has guidance on the “official” way to surface the Jetson EGL/GLES libs on balena, whether via bind mounts from the hostapp or a recommended BSP layer, that would unblock the next step. Happy to test any suggestions.
@Ben1 just checking in to see if you made any progress on these libraries? One of my colleagues had this suggestion:
The Nvidia libraries are a bit scattered between the BSP archive, rootfs archive, but they might be in the apt repository as well. I could trace some of the specific libraries you mentioned in the Nvidia L4T BSP archive in these packages:
libnvidia-egl-wayland.so -> Linux_for_Tegra/nv_tegra/l4t_deb_packages/nvidia-l4t-wayland_36.4.3...._arm64.deb
libEGL_nvidia.so.0 (did not find libEGL.so in these particular debs in the BSP archive) -> Linux_for_Tegra/nv_tegra/l4t_deb_packages/nvidia-l4t-3d-core_36.4.3_..._arm64.deb/usr/lib/aarch64-linux-gnu/tegra/egl/
libGLESv2_nvidia (it's _nvidia in these debs though) -> Linux_for_Tegra/nv_tegra/l4t_deb_packages/nvidia-l4t-3d-core_36.4.3_..._arm64.deb/usr/lib/aarch64-linux-gnu/tegra/egl/
The way I used to search for the parent packages usually was to install the reference Nvidia Ubuntu image, then do dpkg -S /path/to/library/in/ubuntu to find out the package name which provides it, then use apt-get install or search for the deb in the Ubuntu rootfs or L4T archive.
