RPI4 octodash Failed to connect to the bus

[cara]

Hey everybody, unfortunately, I'm not able to get octodash running... I'm using a 3,5 touch screen with a RPI 4.

octodash [83:0424/170030.645110:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

Already changed the docker to get the dbus recognized

octodash:
    restart: always
    build: ./octodash
    privileged: true
    environment:
     - UDEV=1
     - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
    depends_on:
     - octoprint
    labels:
      io.balena.features.dbus: '1'

Anybody else has expierenced this issue and any suggestion for an solution?

Thank you in advance!

[MatthewCroughan]

I'm so sorry I didn't see this issue open up sooner, my notifications have failed me.

Do I need to have the screen connected in order to reproduce this error on a Pi4, or do you think this is reproducible without access to the hardware?

I'm really not sure about why this occurs, can you provide more information about why you need dbus? I'm not too familiar with these 3.5" displays.

[MatthewCroughan]

Maybe this has something to do with the following issues in Octodash? https://github.com/UnchartedBull/OctoDash/issues/562 https://github.com/UnchartedBull/OctoDash/issues/199

We can try updating Octoscreen and see if this issue goes away. This argument uses a git commit hash to determine where the build occurs from. So if you want the latest version of Octodash, you just need to modify this line to be the latest git commit hash, which at the time of writing would be 258d8de8a64e7fabbab260a9beaa7119298ca939

The commit hash for Version 1.5 of Octodash is af4aad373ead42d49bdd5b161485fc474de0c134

https://github.com/MatthewCroughan/octobalena/blob/1699c1a94abb5e829a8b75053dce549331d29534/octodash/Dockerfile.template#L5

[MatthewCroughan]

@cara

Also, is it possible you could share your app with me via the Balena dashboard? That way I can troubleshoot this, without actually having the hardware. My username on Balena is gh_matthewcroughan.

[Bucknalla]

@MatthewCroughan I'm also hitting this with an RPi 3B+ and an RPi 7in screen clone, struggling pin down where it's coming from. I tried using newer versions of Octodash with no success.

[MatthewCroughan]

@Bucknalla This is likely due to the fact that the Octoprint container in this project is not based on a Balena image, which means there is no access to DBUS, since I have not configured that to be the case. The reason I've done this is because I'd like to have this project in a state wherein it can be ran both on Balena and on Raspbian with Docker-Compose, so that it is docker-native and also happens to work on Balena.

This is looking more and more impossible to achieve each day, as Balena images have features that expose functionality on the host via labels, such as io.balena.features.dbus: '1' which allows the guest to access DBUS.

The way this would be done in Docker, generically, would be a bind mount. Bind mounts are disallowed by Balena, so I don't think it's possible to do this in one Dockerfile based on generic alpine, since there is no method of exposing DBUS other than this label on Balena, which means I'm going to have to maintain two separate configurations rather than one, which is quite disappointing and I see that a lot in Balena, since it has forked and failed to keep up to date with Docker, (Multi-arch images) and because of arbitrary limitations on functionality such as bind mounts like this

I'll work on this, as it's becoming an issue as I think of more features to add. Though I'll have to duplicate effort if I want this to work with generic Docker also. Expect a fix in a day or two.

[MatthewCroughan]

Actually, no. This is not the case. Shows you how much I understand my own project hah.

My former comments are a slight issue that applies to things I've been attempting to do with Balena, but are not relevant in this case.

The Octodash container is separate and it is based upon a Balena image in this case, so all the expected functionality is present, so it'll probably just be a case of adding the following to the docker-compose.yml underneath the octodash service.

    environment:
      - 'DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket'
    labels:
      io.balena.features.dbus: '1'

[MatthewCroughan]

Regarding my previous comments about basing Octoprint on a Balena image moving forward, the main reason for this is because there actually are issues present in discovering USB devices caused by the fact that I'm using an old method of initializing UDEV provided by the Balena docs which requires privilege if done without labels on a balena base image, since no bind mounts are available. You may also see a random /dev/ttyS0 that exists for reasons I'm not sure about, but probably wouldn't show up if I did it the Balena way with labels.

[Bucknalla]

@MatthewCroughan the first thing I did was enable the dbus label and envar but I'm still hitting this issue unfortunately! It's very likely still a dbus issue but I'm not sure if it's looking for something from x11 and it can't find it.

[MatthewCroughan]

Interesting. I may have some 3.5" displays somewhere that I can test this with later, but if you find the issue first then do submit a PR!

[Bucknalla]

To clarify, I'm using a clone 7in RPi Screen based off of the official screen, which works fine under other electron examples like balena dash, etc.

[MatthewCroughan]

I'm not the most knowledgeable when it comes to the procedure to compile, package and run Electron based applications, maybe there is a missing dependency for xorg that allows your display to work, whereas mine does not require it? Does running dmesg show anything interesting relating to the display?

https://github.com/MatthewCroughan/octobalena/blob/1699c1a94abb5e829a8b75053dce549331d29534/octodash/Dockerfile.template#L51-L54

[MatthewCroughan]

@Bucknalla Just to be clear, you are saying that your display doesn't start at all? I have been presuming that the displays work, but that the touch input does not.

[Bucknalla]

@MatthewCroughan screen works fine including touch, noticing now that I run into this error:

[MatthewCroughan]

@Bucknalla Yeah, I've noticed that too on recent builds. It's because the app fails to build deterministically when checked out to the commit hash I've provided. It did work at some point in the past, but no longer works. I thought the point of git, npm, etc was to create reproducible builds, but maybe I've made some wrong assumptions.

What commit hash are you using to build OctoDash from?

[Bucknalla]

@MatthewCroughan I was using your commit hash but I'm trying the latest octodash release to see if there are any improvements on that front now

[Bucknalla]

@MatthewCroughan so I was looking at this last night and I think I may need to do a bit of a rework for the RPi 4 but in doing so I'll try to PR some more generic fixes for 64bit OS; basically there are a lot of things not working on the RPi 4 :sweat_smile:

[MatthewCroughan]

@Bucknalla That's great investigative work that will prove incredibly useful in making this work in more cases, since I won't be using a Pi4 in my personal setup any time soon!

[MatthewCroughan]

@Bucknalla https://github.com/MatthewCroughan/octobalena/commit/a736008cd2e8c5891efc69b2cdc5a6a92f23368b proves that you and I were building from master, which is why builds were inconsistent, because of the lack of one character, amazing.

[Bucknalla]

@MatthewCroughan good catch haha it might also be better to fix the balena image to build from a specific version of node rather than latest as I was able to get the master to run under v12 but not v14.

[MatthewCroughan]

@Bucknalla I'm having other troubles with building properly, so I'm opting to simply install via the binaries provided by Octodash's release page, whilst keeping the Dockerfile with the full build instructions for later, it's too difficult to get working on the Balena build servers since actually figuring out why interactively is a nightmare. Besides, if this gets any traction, we don't want people waiting 11 minutes to build it via the Balena build servers anyway, so it's best left until we can figure out the proper method of building.

https://github.com/MatthewCroughan/octobalena/commit/ddff60f5b7812d9edea896bce5fffd04d5259236 https://github.com/UnchartedBull/OctoDash/issues/760

[MatthewCroughan]

Additionally, the image is 600~MB lighter for utilising the binary build, since I'm probably building it completely incorrectly, but it was the only way it worked out, since I run into issues with NPM relating to the number of open files (ulimits) and architecture when running it on the build server, just not worth it hah.

[Bucknalla]

@MatthewCroughan all sound like good justifications to me. Another note, do you have an RPi camera working? I'm also struggling to gain access to /dev/video0 from the octoprint container

[MatthewCroughan]

@Bucknalla I do not have a Pi Camera to test, but I'd look at https://github.com/balenalabs/balena-cam and see what is being done there that is not being done here, and if you can access it via that. Perhaps it's

                labels:
                        io.balena.features.kernel-modules: '1'

[MatthewCroughan]

The following lines also imply that you would need that label to load a kernel module to make it work. https://github.com/balenalabs/balena-cam/blob/409c8816daf599d759c2ad1908c55768387d5efd/balena-cam/Dockerfile.template#L30-L35

[Bucknalla]

@MatthewCroughan I've been through and done a load of modifications for loading kernel drivers; leave this one with me I'll work it out and open a PR.

[MatthewCroughan]

I have some PRs of my own to merge, so sorry I end up creating merge conflicts!