BlitzTUI issues on master/current Debian Image

[frennkie]

I'm having issues activating the touchscreen feature on the current master. This is either caused by one of the PRs or the upgrade to a newer Buster Image.

[openoms]

Found the same: https://github.com/rootzoll/raspiblitz/issues/889

[rootzoll]

Please test/fix on v1.4 branch

[rootzoll]

Searching for similar errors on other projects:

This sounds similar "I upgraded a jessie to buster 6 weeks ago and after reboot was left with the black screen and blinking cursor." --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879624

[rootzoll]

Maybe interesting Tesresult: I took the v1.3 image, updated the v1.4 branch scripts into it and after recovery (blockchain had errors, but ignored that) activated the Touchscreen. Result: Instead of seeing a "black screen with a blinking cursor" I got a "black screen with a mouse cursor" on the LCD that I was able to move by touch.

[frennkie]

I think I found one issue. The /etc/lightdm/lightdm.conf file contains this line:

display-setup-script=/usr/share/dispsetup.sh

But on my machine there is no file dispsetup.sh.

I currently have this change applied that I think fixes this issue:

if grep -Eq "^display-setup-script=" /etc/lightdm/lightdm.conf; then
    sed -i -E 's/^(display-setup-script=.*)/#\1/' /etc/lightdm/lightdm.conf
fi

[frennkie]

For me this is solved with #930. But let's keep an eye on it in the v1.4 RC.

[openoms]

I got to the touchscreen with mouse pointer, but only on a black screen.

Will continue to test.

[frennkie]

Mouse pointer in the center of the screen, right?

[openoms]

Mouse pointer in the center of the screen, right?

yes, responsive to touch also, but on a black screen.

[frennkie]

I was having an issue that a blank cursor was blinking in the top left corner.

Did you do a clean build for v1.4?

If yes, can you check the logs for any hints:

• /home/pi/blitz-tui.log
• /var/log/lightdm/* ..

[openoms]

I had the cursor blinking on the top left.

After the #930 the mouse pointer appeared.

I did a clean SDcard build every time, last from the current state of the v1.4 branch.

[rootzoll]

Same here - with the v1.4 RC1 I get to a "Back Screen with a mousepointer" instead of "Back Screen with blinking Cursor".

[frennkie]

I could imagine that this issue is related to something missing/wrong/unexpected on the HDD in your cases. In PR #934 I added three log lines which will end up in /home/pi/blitz-tui.log.

Could you include them when testing? (Upgrade to 0.42.0 can be done with /home/admin/python3-env-lnd/bin/python -m pip install -U BlitzTUI)

[openoms]

This is what I get on the RC1: https://pastebin.com/raw/yCdALTQn

This already shows some missing module:

modprobe: FATAL: Module g2d_23 not found in directory /lib/modules/4.19.75-v7l+

Since just installed the touchscreen I am already on the blitzTUI 0.42.0, so the upgrade does nothing more.

[frennkie]

modprobe: FATAL: Module g2d_23 not found in directory /lib/modules/4.19.75-v7l+

I get this too even when it's working fine... so I'm pretty sure this can be ignored (see also: https://www.raspberrypi.org/forums/viewtopic.php?t=67334).

Sorry, I mixed up the logs... this one should give us the right pointers to where blitz-tui fails:

/home/pi/.cache/lxsession/LXDE-pi/run.log

Can you check/post it please?

[frennkie]

I'm currently thinking that you both have settings in the config files which blitz-tui is unable to load/parse. It's actually possible to run the parser standalone:

/home/admin/python3-env-lnd/bin/python
from blitztui import config
config.main()

My output:

admin@raspiblitz:~ $ /home/admin/python3-env-lnd/bin/python
Python 3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from blitztui import config
2019-12-25 22:07:35,528 - root - INFO - __init__:9 - Starting BlitzTUI v0.42.0
>>> config.main()
=======
= LND =
=======
rpc_list:               0.0.0.0:10009
rpc_list_host:          0.0.0.0
rpc_list_port:          10009

====================
= RaspiBlitzConfig =
====================
auto_nat_discovery:             False
auto_pilot:                     False
auto_unlock:                    True
[...]

[frennkie]

I just tried on another pi and can reproduce it. Checking /home/pi/.cache/lxsession/LXDE-pi/run.log I get:

configparser.DuplicateOptionError: While reading from '<string>' [line 20]: option 'loop' in section 'DEFAULT' already exists

So one fix is the remove the duplicate line in /mnt/hdd/raspiblitz.conf (there are two loop lines).

[openoms]

Second attempt at installing the TUI worked on 1.4 RC2.

I did reinstall NodeJS and RTL + added BTC-RPC-Explorer since the last attempt to so new entries have been made to the raspiblitz.conf since the the first (failed) install attempt of the TUI.

# RASPIBLITZ CONFIG FILE
raspiBlitzVersion='1.4'
network=bitcoin
chain=main
hostname=TestRPi4
publicIP='X.X.X.X'
runBehindTor=on
autoPilot=off
autoNatDiscovery=off
rtlWebinterface=on
setnetworkname=0
lndPort='9735'
lndAddress=''
touchscreen=1
nodeJS=on
BTCRPCexplorer=on

https://github.com/rootzoll/raspiblitz/issues/969#issuecomment-573293859

[openoms]

Diplay is on with the status screen and the cursor is working with touch, but the buttons are not functional now: sudo cat /home/pi/.cache/lxsession/LXDE-pi/run.log | nc termbin.com 9999 : https://termbin.com/hh8x8

[frennkie]

This is the relevant part

2020-01-11 09:38:27,081 - blitztui.client - WARNING - client:229 - an unknown RpcError occurred
2020-01-11 09:38:27,082 - blitztui.client - WARNING - client:230 - <_InactiveRpcError of RPC that terminated with:
    status = StatusCode.UNAVAILABLE
    details = "failed to connect to all addresses"
    debug_error_string = "{"created":"@1578735507.081412769","description":"Failed to pick subchannel","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":3941,"referenced_errors":[{"created":"@1578735507.081406843","description":"failed to connect to all addresses","file":"src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc","file_line":393,"grpc_status":14}]}"
>

So my Python code can't access LND over the gRPC API (port 10009). Is the dashboard working normally as expected? Maybe a TLS.cert issue..? Or something with macaroons. Last idea: Ip/localhost.

[rootzoll]

I saw some problems during activating the TUI service not getting the macaroons - I will look into that. In general I would not recommend copying the macroons over the pi user .. there are too many places where macaroons get updated and then the TUI sticks with the old one. I would maybe think about linking some directories and setting some relaxed file permissions on the macaroons - at least for invoice & read-macaroon, this should be no problem.

[rootzoll]

OK first that linking of the macarioons seemed to work - but then the user pi had no permission to read the macaroon anymore - I really dont know why. I was even setting all permissions on that file and the directories ... but still permission to read denied?!?

Maybe that is realted to the BTRFS HDD I was testing ... will test again on the EXT4 setup later. If that also not works - fallback to make copy ... but that can be really hard to keep in sync.

[rootzoll]

OK did a fall back to the copy solution - but now the bootstrap script make sure that on every boot tls/invoice/readonly macaraoons are fresh in the pi users .lnd dir - wether touchcreen is on or not. So now touchscreen is working on my test machine. Still rotation is off - but thats part of noter ticket, I think.

What else do we need to get this ticket closed?

[rootzoll]

OK .. did another test with a fresh setup and still the macaroon was not readable - even tho that it was copied to the pi directory and all permissions were set. To fix this I needed to replace the copy command thru a "cat and pipe into new file". Now its working. It was only with the macaroons - the tls was readable for pi user with normal copy. I dont know exactly what was the prob - some file property seems to be attached to the macaroons (also when they are copied within the same system) that just allows root and bitcoin user to read them. Its fixed now with my workaround, but if anybody can enlighten me what was the cause - please let me know.

[rootzoll]

Closing this issue for v.14 release.