[PROBLEM] No more display after in-place update

[romain]

Hello,

I've already had the same problem after in-place update from 8.3.4 to 8.3.5 and now it's the same from 8.3.5 to 8.3.6 ; the screen stays black and on without displaying anything and never goes to sleep mode. 

I could only fix the problem with a fresh install.

my working config.txt: 

Code:

[cm4]
otg_mode=1

[pi4]
hdmi_force_hotplug:0=1
hdmi_force_hotplug:1=1

[all]
disable_splash=1
disable_overscan=1
hdmi_drive=1
hdmi_blanking=1
hdmi_force_edid_audio=1
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=audio=on
dtoverlay=disable-wifi
#dtoverlay=disable-bt

Did I miss something ?

Thanks,
Romain

[Nutul]

Hello,

I've already had the same problem after in-place update from 8.3.4 to 8.3.5 and now it's the same from 8.3.5 to 8.3.6 ; the screen stays black and on without displaying anything and never goes to sleep mode. 

I could only fix the problem with a fresh install.

my working config.txt: 

Code:

[cm4]
otg_mode=1

[pi4]
hdmi_force_hotplug:0=1
hdmi_force_hotplug:1=1

[all]
disable_splash=1
disable_overscan=1
hdmi_drive=1
hdmi_blanking=1
hdmi_force_edid_audio=1
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=audio=on
dtoverlay=disable-wifi
#dtoverlay=disable-bt

Did I miss something ?

Thanks,
Romain

Did the update yesterday night, everything is fine. Only thing it always happens, though, it shows the mouse pointer so that I always have to cycle-switch; and occasionally does not remember the OSK was set to on...
But it works normally.

[TheOldPresbyope]

@romain 

You gave no details of your setup so we're pretty much in the dark here. Physical details (like what kind of display are you using), software settings (like moodeutl -s output), all grist for our mill when we're trying to diagnose problems remotely.

In my case, I just brought up a fresh moOde 8.3.5 player (64-bit) on an RPi3B+ which has an official Raspberry Pi 7" Screen installed. The local display was set "on"; the mouse cursor was set "off"; the popup keyboard (aka on-screen keyboard or OSK) was set "on". Result: local display works fine.

Then I did an in-place software update to 8.3.6.

When the dust had settled, I saw the same thing @Nutul saw. My local display came back up but with the mouse cursor "on" despite the System Config options saying it was still "off". A simple on-off cycle in the options fixed that.

In my case the popup keyboard was restored but perhaps I didn't trigger something @Nutul did.

Result: Local display on my updated 8.3.6 player is working fine.

Regards,
Kent

[romain]

@romain 

You gave no details of your setup so we're pretty much in the dark here. Physical details (like what kind of display are you using), software settings (like moodeutl -s output), all grist for our mill when we're trying to diagnose problems remotely.

In my case, I just brought up a fresh moOde 8.3.5 player (64-bit) on an RPi3B+ which has an official Raspberry Pi 7" Screen installed. The local display was set "on"; the mouse cursor was set "off"; the popup keyboard (aka on-screen keyboard or OSK)  was set "on". Result: local display works fine.

Then I did an in-place software update to 8.3.6.

When the dust had settled, I saw the same thing  @Nutul saw. My local display came back up but with the mouse cursor "on" despite the System Config options saying it was still "off". A simple on-off cycle in the options fixed that.

In my case the popup keyboard was restored but perhaps I didn't trigger something @Nutul did.

Result: Local display on my updated 8.3.6 player is working fine.

Regards,
Kent

Kent, it appears to be a problem with chromium because output of

Code:

systemctl status localui.service

is :

Code:

● localui.service - Start Chromium Browser
     Loaded: loaded (/lib/systemd/system/localui.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2023-09-09 12:34:53 CEST; 27s ago
    Process: 1401 ExecStart=/usr/bin/xinit (code=exited, status=217/USER)
   Main PID: 1401 (code=exited, status=217/USER)
        CPU: 0

When I try to restart localui.service I get this in syslog:

Code:

Sep  9 12:48:48 salon systemd[1]: Started Session 3 of user root.
Sep  9 12:48:57 salon systemd[1]: Configuration file /lib/systemd/system/localui.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Sep  9 12:48:57 salon systemd[1]: Configuration file /lib/systemd/system/localui.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Sep  9 12:48:58 salon systemd[1758]: localui.service: Failed to determine user credentials: No such process
Sep  9 12:48:58 salon systemd[1758]: localui.service: Failed at step USER spawning /usr/bin/xinit: No such process
Sep  9 12:48:58 salon systemd[1]: Started Start Chromium Browser.
Sep  9 12:48:58 salon systemd[1]: localui.service: Main process exited, code=exited, status=217/USER
Sep  9 12:48:58 salon systemd[1]: localui.service: Failed with result 'exit-code'.

Thanks for your help,
Romain

[romain]

I got it fixed finally.

Into the localui service definition file, the user was still "pi" whereas my user is named "tux".

After changing the name I did a systemctl daemon-reload and systemctl restart localui.service and that worked.

Thanks,
Romain

[TheOldPresbyope]

@romain Nice catch.

@Tim Curtis - just a poke to be sure you see this thread.

Regards,
Kent

[Tim Curtis]

When moOde starts up (worker.php) there is the line of code below that replaces the userid in the service file with whatever userid is reported in the "System" section of the startup log (moodeutl -l).

Code:

// Start LocalUI
sysCmd("sed -i '/User=/c \User=" . $_SESSION['user_id'] . "' /lib/systemd/system/localui.service");

[TheOldPresbyope]

Interesting. Not sure, then, where the OP's system is going crosswise. I suppose I can try once again to repro, this time with username other than pi.

@romain - when/where did you change the username?

Regards,
Kent

[Tim Curtis]

The code that fetches the userid is below. It assumes that only one userid exists on the system and thus simply uses the first entry in the output of ls /home/

Code:

function getUserID() {
    $result = sysCmd('ls /home/');
    return $result[0];
}

[TheOldPresbyope]

It assumes that only one userid exists on the system and thus simply uses the first entry in the output of ls /home/

I'm going to make a wild guess that the OP's player has a /home/pi directory (for one reason or another) and that the default username he chose (in rpi-imager or elsewise) sorts higher than "pi".

ETA: I have often created other directories in //home while testing ideas. I could easily have run into the same issue had I done it on a player with local display enabled.

Maybe choose username with uid=1000 instead? (He says, knowing full well there's probably a scenario in which this doesn't work either!)

Regards,
Kent