SSH | Blue screen instead of whiptail menu

[FabioEight]

Creating a bug report/issue

Required Information

root@DietPi3:~# cat /boot/dietpi/.version
#!/bin/bash
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=28
G_DIETPI_VERSION_RC=0
G_GITBRANCH='master'
G_GITOWNER='MichaIng
stretch
Linux DietPi3 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
RPi 3B+

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  2A
  Samsung HC 32gb

Launching dietpi-software, dietpi-update, dietpi-config results in a blue screen:

I've tried different SSH clients/devices, physical reboots, but the issue persists. The RPi was only running pi-hole and no changes have been made during the last weeks.

[Joulinar]

Hi,

many thanks for your report. Well it's not really a blue screen like a crash on Windows. this is more the background color 😉

If you try running dietpi-software, it will hang I guess. Are you able to open a 2nd SSH session and check what is running on the system? Maybe use htop? What SSH clients you are using?

[FabioEight]

Nope, it's not the background color:

I'm unable to launch htop too, after I launch it I see a black screen instead:


Sounds like something on the shell is suddently broken..

[Joulinar]

just a guess, can you check free space on your device?

df -h

[FabioEight]

Here we are

[Joulinar]

can you check journalctl for available error messages

[FabioEight]

can you check journalctl for available error messages

What I'm supposed to check?

Really strange, I was able to launch the commands reported above using Terminus on my iPad, while using SecureCRT, Putty or the SSH client different Windows 10 devices I'm still unable.

[Joulinar]

So using iPad all commands are working?

[FabioEight]

So using iPad all commands are working?

Yes, seems to be, but using another machine with W10, SecureCRT/Putty or the CLI ssh client, still doesn't work

[Joulinar]

Can you probably try to change SSH server on your DietPi system. Just go to dietpi-software and change SSH server preference. Once changed, hit install. I guess you need to use your iPad 😉

[FabioEight]

J

Just did, installed Dropbear, same issue on W10!
Could be something related to the terminal emulation or else?
I've another DietPi install on RPi 4, same setup, working properly on every device.

[Joulinar]

what do you mean by terminal emulation ?? Usually there shouldn't be any.

[FabioEight]

Maybe there's some misconfiguration on the shell used on the RPi 3B+? My SSH clients configurations are default, they're working with my DietPi on RPi4

[MichaIng]

@FabioEight
Very strange. The blue colour looks like it is from the whiptail dialog that should appear to show the dietpi-software or dietpi-update menu. But htop uses a totally different backend, libncurses instead of libnewt, so somehow the interactive console elements are broken all together 🤔.

Since it works from the iPad but on from Windows 10, it is not a general misconfiguration at least.

One thing is that SSH clients can pass a system locale to the server to be used. If this locale is not present/compiled on the server, it can lead to visual problems. But actually all DietPi scripts internally force en_GB.UTF-8 (C.UTF-8 since v6.29). With Dropbear the remote locale is accepted in every case, AFAIK, if non is passed, it is reverted to POSIX and the DietPi login scripts detect this and re-apply the locale that was chosen server side. OpenSSH has the AcceptEnv setting in /etc/ssh/sshd_config, but it should be commented/disabled by default on DietPi. So currently I do not see this playing a role here, but it does not hurt to check and play with the locales server and client side.

Another thing, PuTTY has a setting in Window > Translation > Remote character set, which should be UTF-8 to correctly show the UTF-8 characters from the server.

You could also test with a very different SSH client or reset PuTTY settings (backup + remove Computer\HKEY_CURRENT_USER\SOFTWARE\SimonTatham in regedit), but as you tried already three different ones, it seems to have nothing to do with the clients settings either.

Just in case, as Joulinar suggested, check for kernel errors on server: dmesg -l err,crit,alert,emerg

[Joulinar]

but strange that is is working on the RPi4 but not on RPi3. Images are same and software packages should behave similar as well. Maybe client software settings are different? Or some corruption on the RPi3?

[FabioEight]

@FabioEight
Very strange. The blue colour looks like it is from the whiptail dialog that should appear to show the dietpi-software or dietpi-update menu. But htop uses a totally different backend, libncurses instead of libnewt, so somehow the interactive console elements are broken all together 🤔.

Since it works from the iPad but on from Windows 10, it is not a general misconfiguration at least.

One thing is that SSH clients can pass a system locale to the server to be used. If this locale is not present/compiled on the server, it can lead to visual problems. But actually all DietPi scripts internally force en_GB.UTF-8 (C.UTF-8 since v6.29). With Dropbear the remote locale is accepted in every case, AFAIK, if non is passed, it is reverted to POSIX and the DietPi login scripts detect this and re-apply the locale that was chosen server side. OpenSSH has the AcceptEnv setting in /etc/ssh/sshd_config, but it should be commented/disabled by default on DietPi. So currently I do not see this playing a role here, but it does not hurt to check and play with the locales server and client side.

Another thing, PuTTY has a setting in Window > Translation > Remote character set, which should be UTF-8 to correctly show the UTF-8 characters from the server.

You could also test with a very different SSH client or reset PuTTY settings (backup + remove Computer\HKEY_CURRENT_USER\SOFTWARE\SimonTatham in regedit), but as you tried already three different ones, it seems to have nothing to do with the clients settings either.

Just in case, as Joulinar suggested, check for kernel errors on server: dmesg -l err,crit,alert,emerg

Just performed a clean install, same issue, I’m unable to install pihole from my iPad too this time. So doesn’t seems client related at all.
Here is the output of dmesg:

root@DietPi3:~# dmesg -l err,crit,alert,emerg
[    0.574443] vc_vchi_sm_init: failed to open VCHI service (-1)
[    0.574446] [vc_sm_connected_init]: failed to initialize shared memory service
[    2.956370] vc_sm_cma_vchi_init: failed to open VCHI service (-1)
[    2.956386] [vc_sm_connected_init]: failed to initialize shared memory service
[    2.972382] sd 0:0:0:0: [sda] No Caching mode page found
[    2.972388] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    7.154894] sd 1:0:0:0: [sdb] No Caching mode page found
[    7.154901] sd 1:0:0:0: [sdb] Assuming drive cache: write through

[Joulinar]

so it happen as well on a fresh installation? Are you able to use a different windows box to verify that it is not something on the Win10 box you are using currently?

[FabioEight]

so it happen as well on a fresh installation? Are you able to use a different windows box to verify that it is not something on the Win10 box you are using currently?

Yes, tried 2 Windows 10 devices (2 clients) and iPad (Terminus) as well. Using these clients I’m able to SSH the DietPi on RPI4.

[Joulinar]

do you have a different SD card to try? Personally I'm using as well RPi3 and 4 without issues. So something special on your device. 🤔

[FabioEight]

Not in this moment. I don’t understand why it interfere with the SSH shell or particular screens only. Further, Etcher completes the validation of the card successfully.

[Joulinar]

ok you have 2 RPi's correct? Means 2 SD cards 😉

You could move the working SD card from RPi4 > RPi3. This should work and your system should boot up. Once done, you could flash a new image to the OLD SD card from RPi3 and place it into the RPi4. I know it's quite a lot of try and error but there is just 1 single image for all RPi's and they all run same config/settings if you flash them to SD card. So indeed quite strange that one of the devices is working while the other not.

[FabioEight]

Just performed a full format on my SD, reflashed DietPi and the situation seems stable. Though, here the dmesg:

root@DietPi3:~# dmesg -l err,crit,alert,emerg
[    0.570712] vc_vchi_sm_init: failed to open VCHI service (-1)
[    0.570715] [vc_sm_connected_init]: failed to initialize shared memory service
[    2.888137] vc_sm_cma_vchi_init: failed to open VCHI service (-1)
[    2.888144] [vc_sm_connected_init]: failed to initialize shared memory service
[    2.972920] sd 0:0:0:0: [sda] No Caching mode page found
[    2.972931] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    3.190071] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    3.433165] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    3.471662] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    7.161084] sd 1:0:0:0: [sdb] No Caching mode page found
[    7.161094] sd 1:0:0:0: [sdb] Assuming drive cache: write through

[FabioEight]

New SD card, fresh install.

[Joulinar]

still strange, I'm not able to reproduce this with my RPi3B+

did you tried moving SD card (without changing anything) from RPi4 to your RPi3 and boot it up?

[FabioEight]

still strange, I'm not able to reproduce this with my RPi3B+

did you tried moving SD card (without changing anything) from RPi4 to your RPi3 and boot it up?

Not yet, it will be the next step.
Meanwhile, I've flashed Raspbian on a different SD, performed an apt-get update/upgrade and then reflashed DietPi.
Again, same blue screen on my SecurreCRT/Putty.
Trying to install Pi-Hole using my iPad (Terminus). Let's see how is going to proceed.

[FabioEight]

Unable to open htop too.
There's anyway to perform some kind of troubleshooting to exclude issues on the RPi board itself?

[Joulinar]

Just a question. SecurreCRT/Putty is this a special version of Putty? Because I'm using plain Putty without anything else.

To check that all is working on the board it selves you can move the SD card from RPi4. As we know this is working.

[FabioEight]

No no, I was using different clients, Putty, SecureCRT and OpenSSH client (on W10 Powershell).

[Joulinar]

Hmm I had something like this once on my life. But this was related to a VPN connection. Always I tried to connect using the VPN line, my SSH session get stuck exactly like yours. However I assume this is a direct local network and not applicable.

[MichaIng]

The dmesg output btw is fine, the errors you see are expected. Reminds me that I wanted to suggest disabling the VC shared memory in device tree when having <32 MiB GPU memory share. Seems kinda unnecessary overhead and confusion to have the kernel attempt to load it while it's failure is expected in the first place. Other topic...

@FabioEight
Did you try to SSH into Raspbian to check whether the issue is the same there? I have still no clue honestly, and since htop is affected as well it is at least not something with our scripts to have a look it. Did you verify that PuTTY (and the other Windows 10 SSH clients) use UTF-8 charset, as suggested above?

[Joulinar]

I still would like to see what happen if SD card from RPi4 is simply placed into RPi3

[FabioEight]

I've replaced my RPi 3B+ with a new RPi 4B (due to different reasons), I've moved the SD card used on the RPi 3B+ to my new 4B and everything seems nominal.
Now, I'm experiencing the same behavior on the original RPi 4B+ which was working properly until few days ago:

[MichaIng]

@FabioEight
That becomes more and more strange 😅. Did you do any DietPi or APT updates on the newly failing RPi4 meanwhile?

And just to verify:

• It is not possible to get a console prompt by hitting return or ctrl+c?
• Typing (blindly) printf "\e[0mTEST" and hitting return does not print anything to the console?

[FabioEight]

@FabioEight
That becomes more and more strange 😅. Did you do any DietPi or APT updates on the newly failing RPi4 meanwhile?

And just to verify:

• It is not possible to get a console prompt by hitting return or ctrl+c?

Nope, I'm unable to get a console prompt hitting return or CTRL+C.
I've just performed the upgrade to the last DietPi version (consider that the issue was present on a clean install on RPi 3B+).

• Typing (blindly) printf "\e[0mTEST" and hitting return does not print anything to the console?

Nope, still blue screen.

[MichaIng]

@FabioEight
That is very strange. Just to rule impact of DietPi scripts. Please try the following when connecting locally or from Mac:

mv /etc/bashrc.d/dietpi.bash{,_bak}

This disables the login banner and DietPi-Globals (G_* functions and dietpi-* aliases), so you'll have a pure Debian login.

[FabioEight]

@FabioEight
That is very strange. Just to rule impact of DietPi scripts. Please try the following when connecting locally or from Mac:

mv /etc/bashrc.d/dietpi.bash{,_bak}

This disables the login banner and DietPi-Globals (G_* functions and dietpi-* aliases), so you'll have a pure Debian login.

Nope again, here's my htop after running the command and relogged:

[MichaIng]

@FabioEight
Strange thing, I am out of ideas currently, honestly 🤔.

[Joulinar]

Just for my understanding. The SD card from not working RPi3 was moved into the new RPi4 and working out of the box. I guess it was just a physical move from one device to another. So nothing new installed or flashed? Right?

[MichaIng]

I mark this as closed. Feel free to reopen if required.

[21oramaster]

loopback network problem...