No, it didn’t run on my board - kernel didn’t boot but it was like 13MB instead of ~4. Didn’t get a chance to get to the bottom of it yet. Ordered a BBGreen to try that.
Cool, let us know when you have more results about that and we’ll be happy to assist.
Hi, got my BBGreen today and the image built seems to work just fine on it 
Went back to looking into the issues I was having with this build on my board.
Can’t seem to get the kernel running at all - just reboots after Uncompressing…
As I mentioned, I wasn’t sure anymore that using the kernel from github/beaglebone is the right path for me. Looking at the layers, there seems to be a requirement that using kernel 5.x is using a later balena release, which I think means that it is currently not compatible with OpenBalena?
Really the only issues I was seeing with my version was the overlayfs errors: overlayfs: lowerdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.
Any thoughts on this? It looks like the new version is still using aufs - is there a reason that this is preferred on BB?
I think I’ll try to override the kernel-resin.bbclass to support 5.x kernels when applying the aufs patches.
Hi, indeed 2.53.8 is using kernel 5.4.47-ti-r13. And that is still on aufs. We need to keep using aufs to be compatible with already deployed beaglebones that are on aufs (people will update the hostOS on these so we can’t break it for them). We have a plan to migrate all boards to overlayfs eventually but we need to do some sort of migration from aufs to overlayfs and we don’t have that yet.
As for your problem, can you make sure you have the correct serial defined for your board? I suspect that you are not getting any serial output after u-boot starts up the kernel and you are not able to see why the board reboots.
I see, thanks for the explanation. So on my custom board, there’s no reason not to go with overlayfs; apart from the strange messages in klog?
Regarding the serial, in my machine.conf I have:
SERIAL_CONSOLES = "115200;ttyS0"
SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
and my bootargs sets:
console=ttyS0,115200n8
And is ttyS0 the serial console your board actually uses? Did your board work with older releases of balenaOS?
For a quick workaround, you could just revert the kernel upgrade commit since you’re building it yourself.
Sorry, I think perhaps we are heading down a path I’m not sure we should! 
I tried to mention in this post that I moved away from the beaglebone specific version, and just created my own meta-balena-beaglebone equivalent layer. That seems to work fine at Balena v2.48.0 (because of OpenBalena restriction), and linux-ti-staging kernel 5.4.28 (which was the latest ti version back when I started the layer!).
I guess the only issue I had with that was those overlayfs messages.
So I promised to try the new build, it feels like it would be better in a way to be more close to the beaglebone version. But now I’m not sure if it is useful to continue to try to boot it on my custom am3351 based board. Grateful for your input.
Thanks.
Can you check as per https://github.com/moby/moby/issues/34672#issuecomment-347994879 if you have CONFIG_OVERLAY_FS_INDEX set to yes?
It may take more time and effort to figure out why the latest kernel does not boot on your custom board so I would personally stick with the 5.4.28 version
Still rebuilding the kernel but the .config in my build shows:
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
CONFIG_OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW=y
# CONFIG_OVERLAY_FS_INDEX is not set
# CONFIG_OVERLAY_FS_XINO_AUTO is not set
# CONFIG_OVERLAY_FS_METACOPY is not set
I’ll try updating to a newer kernel version and see if it has an effect.
Thanks.
Unless you are seeing an issue which is addressed by a newer kernel I would say you don’t spend time on trying to compile newer versions.
Yeah, it doesn’t look too easy as the newer meta-ti (2020.01) seems to depend on meta-arm which is only compatible with >=dunfell 
So, do you think that the overlayfs messages are not a real problem?
I guess I could enable overlayfs on my BBGreen build to see if they also appear there.
Can you check if your kernel version has this patch? https://lore.kernel.org/stable/20190919214823.578495152@linuxfoundation.org/
If not, then you should apply it
Yeah, it looks like the patch is in already.
I’ll try out the bbg+overlay tomorrow and let you know.
If that patch is applied then I would say the warning is not to be worried about.
1 Like
No Overlay messages on the BBG+Overlay.
I think the issue may be down to insufficient RAM, I’ve upgraded the DRAM chip on my custom board and now the message no longer appears.
Thanks again for you assistance.