Raspberry PI 4 blank screen after splash screen

Hi,

I wanted to give OSMC a try on my RPI 4 (4GB) again and did a fresh install with the latest image. Downloaded today, so it’s the one that should officially support RPI 4.
Unfortunately, after the (obviously) installation and the reboot, right after the splash screen, my screen is blank.
I tried two different TVs and a Dell monitor.
I tried two different power supplies (both original from RPI 4).
I tried two different SD cards, one of them is completely new.
I tried some settings in the config.txt but all without success. (like hdmi_mode=2, gpu_mem_… and so on).
I use an official RPI HDMI-cable. Tried it also with both HDMI ports.
Raspbian works with the same PI, so it shouldn’t be a hardware issue.

Now I don’t know what to do…

Any ideas? How can I get logs to investigate further? Can I create an ssh file after the setup to activate it?

Thanks in advance,
Viktor

Please show a screenshot of the SD card so we can check if it was imaged correctly.

SSH is enabled out of the box – so you could attach an Ethernet cable and see if you can connect.

This is what the boot looks like

There’s a second partition but I can’t read it on windows. Is it important, too?

Thanks

See my post for a very raw workaround After August 2021.1 update no hdmi output whatsoever - #23 by darwindesign

If, what is happening, is the same that’s happening to me on my Pi3, ssh is not reachable, it just stalls after trying to log in and then timeouts.
This is just after a brand new installation with osmc-installer.

ssh osmc@192.168.1.6
The authenticity of host '192.168.1.6 (192.168.1.6)' can't be established.
ECDSA key fingerprint is SHA256:OUeH9YCuhh/kByce4JCmT2j3UhlIP8NkZqfBtns22to.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.6' (ECDSA) to the list of known hosts.
osmc@192.168.1.6's password:

After a few minutes the ssh session just dies without getting a shell.

I’m having the same issue. Was a GitHub issue created?

@sam_nazarko I’m seeing something very similar on a Pi3 that’s I’m running headless.

After the upgrade to the new kernel, I was unable to SSH to the box. Even with -v I could see that ssh was going through the usual handshake motions and would then freeze, so the OS was working, at least partly.

  • So I assumed a broken installation and reinstalled from a fresh image. Same problem.
  • I connected it to a TV and keyboard and all worked just fine. Enabled wifi, so I could try that if ethernet wasn’t working.
  • Rebooted without either TV or ethernet connected and WiFi no longer even pingable.
  • Reconnect ethernet and WiFi becomes pingable, (as well as ethernet). SSH logon still hangs:
user@disp2144:~$ ssh -v osmc@192.168.8.33
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.8.33 [192.168.8.33] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.8.33:22 as 'osmc'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:7CZ89Q7S3yYzuzPKKF9eCRluzzHUSLMo5oShNHIlu+s
debug1: Host '192.168.8.33' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:4
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: user@vault RSA SHA256:mLLo3R1XBLYh71/getqT8eVGyhz6q30oPI3FHE4ISXI agent
debug1: Will attempt key: /home/user/.ssh/id_rsa 
debug1: Will attempt key: /home/user/.ssh/id_dsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
debug1: Will attempt key: /home/user/.ssh/id_ed25519 
debug1: Will attempt key: /home/user/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: user@vault RSA SHA256:mLLo3R1XBLYh71/getqT8eVGyhz6q30oPI3FHE4ISXI agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_xmss
debug1: Next authentication method: password
osmc@192.168.8.33's password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.8.33 ([192.168.8.33]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

(There’s quite a delay after the “pledge network” line.)

So, in my case, it seems to be something to do with the lack of TV or HDMI connection. It’s also a bit difficult to debug.

Update: A few more data points:

  • Disconnecting ethernet causes wireless to become unpingable.
  • Disabling/stopping mediacenter (via TV/keyboard/command line) also stops the logon screen appearing on the TV at reboot.
  • I can only SSH when connected to the TV, even when mediacenter isn’t running.
  • If I pull the HDMI cable and reboot, SSH gives a “connection refused” error. Reconnect HDMI, power-pull and SSH again works.

Yup, that’s the same behavior I’m facing with my pi3b, except that I have a permanent connection vía HDMI to my tv.

If you use the -v flag with ssh, does it show the same output?

Yup. I’m currently not at home but next Thursday/Friday I could paste my logs.

1 Like

I have a USB-TTL cable I could use to try to debug the problem. Can you advise what needs to be enabled on OSMC to get it to work? (Of course, lots of instructions for RaspiOS available.)

I’m having the same problem, get a black screen, just after the splash screen on reboot.
Log shows that mine is a problem with Mesa. I get lines and lines of “mesa warning: failed to remap” then it hangs at loading the mediacenter.
Tried reinstalling, downloading the img multiple times. I’ve used 5 different SD cards and two Rpi4 units. Get the same errors every time.

I have the same problem, but I managed to ssh into the box.

doing a grep hdmi on dmesg gives:

$ dmesg |grep hdmi
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  smsc95xx.macaddr=DC:A6:32:85:29:60 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  root=/dev/mmcblk0p2 rootfstype=ext4 rootwait quiet osmcdev=rbp4
[    6.263422] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    6.265393] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.266754] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    6.274930] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[   10.575918] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   10.592009] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   10.592594] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   10.593539] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   10.594128] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   12.101063] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   12.118246] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   12.118840] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   12.121177] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   12.121782] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   13.627067] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   13.641916] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   13.642495] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   13.643543] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   13.644146] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   15.149424] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   15.164232] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   15.164815] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   15.165716] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   15.166275] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.671529] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.686387] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.686967] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.687913] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.688519] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19

I can provide additional logs if required.

I’m not sure this applies to you, since “the same problem” could cover several possible cases, but there was a partial workaround provided a few days ago for devices that aren’t connected to HDMI: Headless Pi boot failure - #3 by fzinken

It’s partial in the sense that it only works for (no-HDMI) headless devices where the Kodi GUI isn’t required.

Not sure if this reply was intended for me, but my pi4 is connected by HDMI to a monitor and is intended to be used always connected to a screen/TV. I can ssh to it, so would be happy to access it and paste any logs that are necessary to identify the problem.

Yes, it was for you. Since you can SSH to the box, please run grab-logs -A and post the URL it returns.

The generated log was about 37Mb because of a lot of repeated lines in the Kodi Old Log section. So I deleted about 30k repeating lines and uploaded it manually :
https://paste.osmc.tv/asoviwazux

[ the following section was repeated and I deleted the lines between Aug 25 and Aug 26:

2021-08-25 13:33:28.334 T:482      INFO <general>: CActiveAESink::OpenSink - initialize sink
2021-08-25 13:33:28.334 T:482     ERROR <general>: CActiveAESink::OpenSink - no sink was returned
2021-08-25 13:33:28.334 T:481     ERROR <general>: ActiveAE::InitSink - returned error
2021-08-26 08:47:26.645 T:482      INFO <general>: CActiveAESink::OpenSink - initialize sink
2021-08-26 08:47:26.645 T:482     ERROR <general>: CActiveAESink::OpenSink - no sink was returned
2021-08-26 08:47:26.645 T:481     ERROR <general>: ActiveAE::InitSink - returned error

]

TBH, the log shows no EDID information, so it’s probably the same issue as others have been seeing, though the use of a monitor has confused the issue a bit.

Sam has produced a kernel fix that you might wish to try out.

I’d suggest you wait a bit until the gateway 502 problem has been fixed.

This is fixed.

Still no hdmi output (I get a blue screen with the OSMC logo at boot and then everything goes blank. The monitor then complains of no signal on HDMI input).

Here are the new logs:
https://paste.osmc.tv/kiwojuquhe