RasPi Official Display

[myxxmikeyxx]

When I was testing this out, It worked great so far but one major problem I ran into is the official Raspberry Pi Display.
I made and img of the SD card and then did the shrink and tried doing the boot option.
This worked and the img booted. Then I went and tried to shutdown the booted img and it turned the raspberry pi official display off. Then when I tried launching it again the display didn't turn on. Next on the pi itself I did a reboot and the display turned back on. The weird part was that through VNC I could still see the desktop and everything but the official pi display was black.

https://drive.google.com/file/d/1hGUlwbbAMU27LAOQduHWGNhIlfA-Wq14/view?usp=sharing

[Botspot]

My hypothesis: You didn't properly shut down the virtual machine. When your Pi tried to shutdown, it took a long time to do so because a default shutdown under SystemD waits for 3 minutes before forcibly unmounting a disk.

My suggestion: Before shutting down your Pi, be sure to properly shut down the virtual machine first. There are several ways to do this:

• Shut it down from the VM's main menu: Menu -> Logout -> Shutdown
• From a terminal inside the VM: sudo shutdown now
• From the blue terminal: sudo shutdown now
• Alternative technique in the blue terminal: Ctrl+]+]+]

Improper ways to shutdown the virtual machine:

• Do nothing. (Leave it running and then attempt to shut down your Pi)
• Close the blue terminal. This effectively stops the virtual machine, but it doesn't have a chance to unmount the image/disk, which as you've noticed, can cause delays when you try to shutdown your Pi.

If you forget to properly shutdown vdesktop, it's no big deal. This has happened to me too. I just give my Pi a good 5 minutes to shutdown and it's usually finished by then.

[myxxmikeyxx]

I did it in the blue terminal. If you watch the video it shows that I type sudo shutdown now at about 0:46 mark. What I show after is my VNC connection to the main Pi still running and giving me display as the blue terminal shuts down.

[Botspot]

I did it in the blue terminal. If you watch the video...

I apologize for misunderstanding. Earlier I was unable to watch the video, but this time it played for me.
I now see what you experienced, and am very puzzled about it. From what I know about owning a RPi Display, it uses some GPIO pins, in addition to the "display" ribbon cable. Perhaps the virtual machine managed to control your Pi's GPIO to signal to the screen to shut down its backlight?

Unfortunately, I am unable to test this myself because I didn't bring a RPi display with me on this trip.

As I said, it seems like a /dev device is being mounted to the vm, that is capable of manipulating the GPIO. For others this may be a "feature", but for you it's turned out to be a bug. As I don't have my RPi display with me, I cannot narrow down which bind-mount is allowing this to happen. But you can.
All the mountpoint entries are stored in vdesktop's nspawn script. This is a bash script.

For starters, let's try disabling all kernel devices. Please replace the entire contents of the nspawn file with this:

#!/bin/bash
sudo "$1" -bD "$2" --volatile=no $3

Try booting your image again, then shut it down, and see if your RPi display still went black. If it did, then the problem lies elsewhere. But if your RPi display remains lit, then congratulations - we've located the proximity of the problem. You could stop here, or you could add back one kernel device mount at a time to figure out which one is causing the problem.

[myxxmikeyxx]

Not a problem. I just wanted to make sure I did it in the correct terminal. I will have to test that tomorrow or the next day at work. It could be the gpio are getting a turn off signal for an instant to turn the display off but I also wonder if the pi official display has a signal wire (like how some HDMI TV’s can be powered off from the receivers because of HDMI signal pin, for example my old TV could be turned off from my Roku using the TV off option on the Roku and not using the TV remote https://support.roku.com/article/360037934914).

CEC must be enabled on both devices. CEC, or Consumer Electronics Control, allows commands to be shared between devices over the same HDMI connection as audio and video, letting you control common functions of different devices without having to juggle remotes. In this case, CEC lets you use the 'TV Off' shortcut to easily turn your TV screen off.

This weird experience makes me wonder if the display cable could be just an HDMI but as a ribbon cable and has the ability to be turned off from a signal.

As I said before I’ll try it out tomorrow at work.

[myxxmikeyxx]

Replacing the file contents with:
#!/bin/bash sudo "$1" -bD "$2" --volatile=no $3

Did work!
The display did not turn off when I did
sudo shutdown now

Would you like me to try anything else to see if we can find the problem? I did backup the original nspawn file.

[Botspot]

Replacing the file contents with:
#!/bin/bash sudo "$1" -bD "$2" --volatile=no $3

Did work!

Excellent! I'm relieved that turned out to be the problem. Otherwise, I would have not known where else to look.

Would you like me to try anything else to see if we can find the problem? I did backup the original nspawn file.

Yes please. As-is, without any kernel devices being mounted, a lot of things won't work. For example, the browser, audio, usb devices, shared memory, and hardware acceleration will not work. It would be great if we could narrow down exactly which bind-mount is the troublemaker.

To do that, one line needs to be re-added to the file at a time. For convenience, the original nspawn script is located on Github here.

To save time, I suggest starting with this nspawn file:

#!/bin/bash

DIRECTORY="$(readlink -f $(dirname "$0"))"

#variable 1 is path to systemd-nspawn
#variable 2 is filesystem to boot
#variable 3 is additional nspawn flags.

sudo "$1" -bD "$2" --volatile=no $3 \
  --bind=/dev/shm \
  --property="DeviceAllow=/dev/shm rwm" \
  \
  --bind=/dev/snd \
  --property="DeviceAllow=/dev/snd rwm" \
  \
  --bind=/proc \
  --bind=/dev/input \
  --property="DeviceAllow=/dev/input rwm" \
  \
  --bind=/proc/asound \
  --bind=/proc/device-tree \
  \
  --bind=/dev/random \
  --bind=/dev/urandom \
  \
  --property="DeviceAllow=/dev/null rwm" \
  --property="DeviceAllow=/dev/zero rwm" \
  --property="DeviceAllow=/dev/full rwm" \
  --property="DeviceAllow=/dev/random rwm" \
  --property="DeviceAllow=/dev/urandom rwm" \
  --property="DeviceAllow=/dev/net/tun rwm" \
  \
  --property="DeviceAllow=char-usb_device rwm" \
  --property="DeviceAllow=char-input rwm" \
  --property="DeviceAllow=char-alsa rwm" \
  --property="DeviceAllow=char-drm rwm" \
  \
  --bind=/dev/loop-control \
  --property="DeviceAllow=/dev/loop-control rwm" \
  

I went through each entry and don't believe any of these entries are capable of manipulating the GPIO or the display cable.
Try going through the same shutdown procedure and see if it works. If your Pi display remains lit, then we've ruled out all of the above bind-mounts above. We can continue adding back one line at a time from the original nspawn file until the the problem returns.
At that point, whichever line was added previously is now confirmed to be the problem.

[myxxmikeyxx]

The script did not turn off the display. It did recognize it though.
I was able to quickly grab a picture before the screen kept scrolling with he shutdown:

I also found a blog post that might help:
https://www.raspberrypi.org/forums/viewtopic.php?t=120296
I haven't tried these commands yet but I wondered if this would help in finding the part that is turning off the display.

That's how you control it:
echo` 0 > /sys/class/backlight/rpi_backlight/bl_power
echo 1 > /sys/class/backlight/rpi_backlight/bl_power