Hello Balena Team,
Are there any plans to update the balenaOS kernel version and/or yocto release for beaglebone?
Thanks.
Hi. What update are you looking for more specifically? Do you need just a newer kernel? And why if yes?
Hi, yes I currently have a custom board with the ti-sdk 5.4 kernel. I’m specifically using the DSA subsystem to control a SJA1105 switch.
I started looking at backporting the SJA1105 stuff into 4.14, but there are a lot of changes - phylink, etc.
Is there a specific 5.4 patch version you are looking for?
No, I think I’m on the ti2020.00 release currently - 5.4.28.
Ok. Will take a look and come back to you in the following days
Is there anything I can try or do to assist?
Unfortunately not currently. We mainly need to validate if upgrading to the that version of the kernel will not break things or expected interfaces for other users using the beaglebone boards. Often when upgrading the kernel things like overlays and some drivers stop working, so we try stick to the latest that is shipped on debian for on beaglebone
In any case I have created an issue on the BBB repo to track this: https://github.com/balena-os/balena-beaglebone/issues/228
Hi guys,
I realised that really, the only thing in common with beaglebone is the SoC! I tried using the 5.4 kernel with the beaglebone rootfs but udev wasn’t happy - waiting 4 minutes on init.
So I just created a new set of layers at the latest warrior version of meta-balena, with my own machine layer in. It all boots up nicely at the moment, further testing this weekend!
Thanks.
Thanks for letting us know, looking forward to your test results.
So when I try to join my device to the cloud, I’m not allowed because I’ve changed the board type.
What’s the recommendation - just pretend it’s a beaglebone? Or am I missing something about support for custom boards?
Thanks
I also see some of these overlayfs messages similar to: rosettaathome : PI 4 overlayfs warnings
Are they a problem?
Hi there – I’m not sure I understand how you have changed the board type – can you give a bit more detail on how you’ve done that? And are you able to post the overlayfs messages you’re seeing?
Thanks,
Hugh
Hi Hugh,
I have a custom board that I’ve built BalenaOS for from the base layers. It’s not a beaglebone (only really sharing the same processor family), so I made a coffee file for it and gave it my yocto machine name in the slug.
I was hoping that I could add in this new type to my OpenBalena instance, but that seems to check on an AWS bucket for the list of supported types. For now I’ve just tweaked the json file on the board to make it pretend it’s a beaglebone-green and I was able to join successfully to my OpenBalena and to the cloud. But was wondering whats the correct way to approach this?
I’ll grab those logs later today.
Thanks.
Hi,
Glad you got it working! Balena device types describe the type of system-on-a-chip you’re running, so setting yours to match the beaglebone-green (on which your system is based) is a reasonable workaround. Here’s some more information on device types and their architectures: https://www.balena.io/docs/reference/hardware/versioning/#device-types. More info on custom board support.
John
1 Like
Here’s a snippet from the journal with the overlayfs errors:
Jul 01 17:54:26 balena a9f4f2d8e403[801]: [debug] delta([bacnet] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Applying balena delta...
Jul 01 17:54:26 balena resin-supervisor[1729]: [debug] delta([bacnet] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Applying balena delta...
Jul 01 17:54:26 balena resin-supervisor[1729]: [debug] delta([bacnet] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Using registry auth token
Jul 01 17:54:26 balena a9f4f2d8e403[801]: [debug] delta([bacnet] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Using registry auth token
Jul 01 17:54:26 balena a9f4f2d8e403[801]: [debug] delta([python-connect] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Applying balena delta...
Jul 01 17:54:26 balena a9f4f2d8e403[801]: [debug] delta([python-connect] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Using registry auth token
Jul 01 17:54:26 balena resin-supervisor[1729]: [debug] delta([python-connect] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Applying balena delta...
Jul 01 17:54:26 balena resin-supervisor[1729]: [debug] delta([python-connect] registry2.balena-cloud.com/v2/74e79bf38a267116206ef61e7231e204@sha256:4bb2acd5ffa6aa336f284d404e21af6ccdcc024aa3c255b230b0a4166289c7d1): Using registry auth token
Jul 01 17:54:27 balena balenad[801]: time="2020-07-01T17:54:27.071516645Z" level=info msg="shim balena-engine-containerd-shim started" address=/containerd-shim/moby/744cc0b44cded23ed0b0e7c0e911e547258d618a6fb96334cd82f8614f5a6a5c/shim.sock debug=false pid=2495
Jul 01 17:54:35 balena kernel: eth0: renamed from veth4221608
Jul 01 17:54:36 balena kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth4bbf849: link becomes ready
Jul 01 17:54:36 balena kernel: br-b11982802003: port 1(veth4bbf849) entered blocking state
Jul 01 17:54:36 balena kernel: br-b11982802003: port 1(veth4bbf849) entered forwarding state
Jul 01 17:54:36 balena NetworkManager[783]: <info> [1593626076.2527] device (veth4bbf849): carrier: link connected
Jul 01 17:54:37 balena avahi-daemon[774]: Joining mDNS multicast group on interface veth4bbf849.IPv6 with address fe80::3c3e:71ff:fe04:2b46.
Jul 01 17:54:37 balena avahi-daemon[774]: New relevant interface veth4bbf849.IPv6 for mDNS.
Jul 01 17:54:37 balena avahi-daemon[774]: Registering new address record for fe80::3c3e:71ff:fe04:2b46 on veth4bbf849.*.
Jul 01 17:54:39 balena kernel: overlayfs: lowerdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.
Jul 01 17:54:39 balena kernel: overlayfs: lowerdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.
Jul 01 17:54:39 balena kernel: overlayfs: lowerdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.
Jul 01 17:54:41 balena 744cc0b44cde[801]: [21B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [37B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [152B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [158B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [158B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [148B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [148B blob data]
Jul 01 17:54:41 balena 744cc0b44cde[801]: [148B blob data]
There only seems to be one overlay entry in mount:
root@localhost:~# mount | grep overlay
overlay on / type overlay (ro,relatime,lowerdir=/balena/overlay2/l/W4POQEUDWXJFNV2ZTWE6D4SEIP,upperdir=/balena/overlay2/d3309a5b902b897cd54926ba7f98eed5cf97d4729b94226929627b0de436c627/diff,workdir=/balena/overlay2/d3309a5b902b897cd54926ba7f98eed5cf97d4729b94226929627b0de436c627/work)Hi, I’d like to let you know that we’ve upgraded the kernel to 5.4.28. Could you please give it a try and let us know how it works for you?
Thanks,
Georgia
Thanks for the message, building now…
Hi Seimon, did you get the chance to test this?