Open chrisys opened 4 years ago
[chrisys] This issue has attached support thread https://jel.ly.fish/#/support-thread~2b02df83-15b7-44af-999d-a492c3dab194
Has this been resolved yet?
Using 2.47.01rev (supervisor: 10.6.27) and getting the white screen instead of correctly displayed PADD for pihole. Moreover, it seems that PADD in pihole does not even start:
13.04.20 17:16:35 (+0300) pihole /dev/fb1 not found. Disabling fbcp & PADD
Also, leaving this related discussion here: https://forums.balena.io/t/padd-from-balena-pihole-project-does-not-work-with-pitft-2-8/48049/13
That's unfortunate, that there was no activity on this issue (v2.51.1+rev1 still has this problem)
Can confirm still broken.
An easy workaround for this is to stop plymouth from the application before starting the graphical subsystem (X11, Wayland). This can be done by issuing the following d-bus command:
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"
@denisinla @drew-kun could you try this suggestion at let us know if it helps?
@denisinla @drew-kun could you try this suggestion at let us know if it helps?
Is this done in the Device Configuration section under "Custom Configuration Variables?"
@chrisys @denisinla @eiddor @alexgg Sorry, I may misunderstood how to do this in order to test the solution... This is what I have been trying to do:
Downloaded balena-cloud-pihole-dnscrypt-raspberrypi3-64-2.47.0+rev1-dev-v10.6.27.img and flushed it with Balena Etcher, Then added the new Custom Configuration Variable and test...
But adding the config var getting this:
Am I doing this wrong way? Any suggestions?
@denisinla @eiddor what I meant is that the application needs to instruct the OS to stop plymouth before launching a graphical subsystem. So this needs a change in the application entry script so that it uses dbus to send a command to the OS. On multicontainer applications they will need to set the io.balena.features.dbus
label on the docker-compose file for this to work. See the documentation at https://www.balena.io/docs/learn/develop/runtime/#dbus-communication-with-host-os
Then, the application needs to issue the following command early on:
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"
You can then check that the plymouth service in the OS is stopped.
The expected result is that if the graphical subsystem is launched after plymouth has been stopped it will work.
@alexgg Thanks for the extra details - I think I understand the process better, but I'm not versed enough in the balena/containerization process to test it.
Piecing everything together, though, it sounds like I'd have to do this (on a new image so that I can keep my working "machine" handy):
Add this to docker-compose.yml in the package:
version: '2'
services:
pihole:
environment:
- 'DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"'
labels:
io.balena.features.dbus: '1'
And add "dbus" to this in pihole/Dockerfile:
RUN install_packages cmake libraspberrypi-dev dbus
I know this is beyond the scope of the issue, so I appreciate the extra guidance.
Would the plymouth service need to be restarted again after the GUI loads?
I've applied this workaround here with success on two different screen overlays so far.
https://github.com/klutchell/balena-pihole/commit/6a8f4dcfa0acb8881e56ca622c9398586474e72f
@klutchell Whatever changed in your last update from a few days ago fixed everything for me without any extra workarounds. I'm running balenaOS 2.58.3+rev1 (Supervisor 11.14.0) and my display is working perfectly.
Somewhere between balenaOS 2.38 and 2.43, the use of fbcp has started blanking the display output on small PiTFT screens (using the pitft35 and pitft28 dtoverlays).
On 2.43, starting fbcp clears the balenaOS splash screen and does not provide any further output. On 2.38, starting fbcp does not clear the splash screen and correctly copies to the framebuffer.
We (+ @petrosagg) disabled Plymouth on 2.43 and although the splash screen was no longer displayed, fbcp then works correctly again.