Cannot get pi-hole running on balena cloud - not being able to access public url

Give my fork a shot:

I removed some the other services, and included some code to fix sudo issues I kept encountering.

Which services did you remove?

Put everything in, app is working, PADD is not. Cannot see the out put on the screen.

I’m following this part here…

@hax which repo are you using now? @wwalker has removed the required software for the PiTFT screen in their repo (likely because it wasn’t needed!) so that won’t work.

If you’re still using the repo from our guide (klutchell's one) you do need to set all of the variables in the PiTFT guide - can you double check to make sure you’ve got them all set up and matching? Also note that the PiTFT ones are device variables rather than service ones as they apply to the hardware. Any little mistake here or missing variable could quite easily stop the display from working.

Edit: I’ve just had a look at your device and can see everything looks correct. Could you let me know what the display is doing? Is it just full white or black, or are you seeing the balenaOS logo, or a terminal?

@chrisys Just getting a white screen, I am using klutchell repo mentioned in the balena writeup.

I triple checked everything, it should be running, but I am not getting anything but a white screen. App is running, only thing I don’t have is pass word set yet.

@hax hmm OK that’s a strange one, you should at least get the balenaOS logo. Is your PiTFT a known good and working unit? I’ve had problems like that where the display has become disconnected from the PCB and additionally when the timing on the dtoverlay was wrong.

When I looked at your app yesterday your timing was set to exactly the same as mine, so should be OK, but from what I can find online there are variations between displays. There are references to speeds of 32000000 as well as 20000000, so you could try either of those to see if it helps; the lower is more likely to work. You would try these by replacing where it says 25000000 in the RESIN_HOST_CONFIG_dtoverlay configuration variable.

@chrisys Works great, can see the operating system when its on an other pi, haven’t had any problems when I was just running an os.

This is the one, that I similarly put on it.

I can try changing the timings later when I get home and see if It changes anything on there.

@hax ok that’s great, as it’s not an Adafruit one the settings are likely to be a bit different and additionally it may require some additional driver software to get it to work. The link mentions a driver download, in which case they might be providing you with a different dtoverlay which you’d need to copy to your SD card separately to get it to work.

@chrisys I will try installing some drivers, I didn’t think they were need since there were none installed with the pi-hole installation. (maybe theres some drivers included in the pi-hole install that I don’t know about?)

Do you know if needs to be installed in the host os or the pi-hole? I’m doing some research currently but have come up inconclusive at the moment

@chrisys Tried to install a driver with no avail, tried to get the apt-get stuff and I guess a lot of the drivers that raspbian has don’t work with this image.

This is what I am using…

Tried to do it on host os, but I can’t get git on it with apt-get, so I tried on pi-hole sector and that didn’t work either.

Will need to do some more research on how to get more os packages installed.

@hax I can take a look if you don’t mind, can you enable support access and share your device URL?

@hax sorry I missed your first post; it works without a driver in the default configuration because the PiTFT is supported natively and the driver is included in the default distribution. By setting dtoverlay=pitft35-resistive you’re loading the driver for that screen. As yours is different that driver isn’t working and we need to get you running a different one; one of the ones they’ve provided on GitHub.

Just so you’re aware, the pitft35-resistive relates to the .dtbo file that lives in /mnt/boot/overlays. If you look in the GitHub repo at what those install scripts are doing, they’re copying a .dtbo file and setting some configuration variables. You can try copying the file that relates to your screen (I am guessing it’s tft35a-overlay.dtb into the /mnt/boot/overlays folder and renaming it tft35a-overlay.dtbo as is happening on line 5 in this file; assuming that’s the correct one for your screen. You would do this on the host OS.

Hope this helps!

Everything is enabled for a week, should be able to login in and check

I just checked the host ios, doesn’t contain any files at all. I ls the host ios and theres nothing there, I might be doing something wrong.

dnscriptproxy contains mnt but its empty also

@hax I can no longer access your device to take a look, but there is some useful information regarding adding the overlay in this thread: Unable To Use TFT ILI9341 With Pi And Resin

@chrisys Reset, I will check the writeup and see if I can try to implement something from it

@hax I have copied the overlay from the GitHub repo you linked into /mnt/boot/overlays (tft35a.dtbo). You could now try updating your RESIN_HOST_CONFIG_dtoverlay to tft35a

@hax check out this thread: 3.5" TFT with RaspberryPi

@branchespark is using the piscreen overlay with a display from Amazon that looks similar to yours; maybe yours will work with these settings too.

@chrisys and @hax - yes, they look the same.

Assuming you’re using the WPE project, or another project with udev rules, then it really should be as simple as adding a few parameters and creating a new udev rule.

Let me know how you get on.

Hey Guys, sorry for the delay. Things have been a bit crazy. I will be looking into the pi and see whats going on. Will be taking your advice and see if I can get the screen working.