[SOLVED] 8.3.1 Legacy on Pi Zero - failed upgrade.

[Nutul]

Yeah, the entropy is a thing but shouldn't be cropping up here.

By way of contrast to my Zero-W experience

1) fresh install of the 64bit moOde 8.3.1 on a Pi4B seems to have gone through without issue. No weirdness discovered yet.

2) attempt to update a 64bit moOde 8.3.0 on a Pi3A seemed to work but resulted in weirdness (updater claimed to install new kernel but moodeutl reported old one; the update check kept claiming there was an update available). I thought I'd rebooted after the update but it's possible I reboot the wrong player in the heat of the moment. Anyway, rebooting again seems to have cleared things up.

moodeutl still reports the missing file

Code:

Gathering info...
grep: /sys/class/leds/led0/trigger: No such file or directory
...

Regards,
Kent

My 64bit players (Pi4) both upgraded without an issue (one in place, one fresh install then restore from backup).
I too get that missing file report on both.

For what I can see there is no "led0" in /sys/class/leds/, everyting is a symlink to /sys/devices/platform/leds/leds/<something> or /sys/devices/virtual/leds/leds/<something>

Maybe the new kernel has given the leds some other name?

ETA

Also, I see the two errors in sysinfo.sh... It's better to have the "if" statemets as follows:

instead of

Code:

if [ $MODEL = 3 ]; then

use

Code:

if [ "x${MODEL}x" = "x3x" ]; then

so that an empty / not found variable won't break the syntax of the script - as the above at the moment evaluate as if it was written:

if [ = 3 ]; then

[the_bertrum]

I'll run my zero with the entropy service disabled for a while to see if anything goes wrong. Since it's for seeding encryption and so on, I can't see moOde relying on it too much...

[philrandal]

echo '0' | sudo tee -a /sys/class/leds/PWR/brightness > /dev/null
echo '255' | sudo tee -a /sys/class/leds/PWR/brightness > /dev/null

to turn power led off and on

Cheers,

Phil

[Tim Curtis]

Yeah, the entropy is a thing but shouldn't be cropping up here.

By way of contrast to my Zero-W experience

1) fresh install of the 64bit moOde 8.3.1 on a Pi4B seems to have gone through without issue. No weirdness discovered yet.

2) attempt to update a 64bit moOde 8.3.0 on a Pi3A seemed to work but resulted in weirdness (updater claimed to install new kernel but moodeutl reported old one; the update check kept claiming there was an update available). I thought I'd rebooted after the update but it's possible I reboot the wrong player in the heat of the moment. Anyway, rebooting again seems to have cleared things up.

moodeutl still reports the missing file

Code:

Gathering info...
grep: /sys/class/leds/led0/trigger: No such file or directory
...

Regards,
Kent

My 64bit players (Pi4) both upgraded without an issue (one in place, one fresh install then restore from backup).
I too get that missing file report on both.

For what I can see there is no "led0" in /sys/class/leds/, everyting is a symlink to /sys/devices/platform/leds/leds/<something> or /sys/devices/virtual/leds/leds/<something>

Maybe the new kernel has given the leds some other name?

ETA

Also, I see the two errors in sysinfo.sh... It's better to have the "if" statemets as follows:

instead of

Code:

if [ $MODEL = 3 ]; then

use

Code:

if [ "x${MODEL}x" = "x3x" ]; then

so that an empty / not found variable won't break the syntax of the script - as the above at the moment evaluate as if it was written:

if [ = 3 ]; then

- Right, quote the args.
- The names in /sys/class/leds/ appear to have changed at some point from led0 and led1 to ACT and PWR.

[Tim Curtis]

I'll run my zero with the entropy service disabled for a while to see if anything goes wrong.  Since it's for seeding encryption and so on, I can't see moOde relying on it too much...

I did find my Zero W and with the change to the is-system-running check in worker it booted up a fresh image without any issues.

According to the doc the is-system-running check returns "degraded" if any systemd unit fails to start and in this case it's the haveged unit. It won't start on my Zero W and apparently on your Zero as well. Maybe it's not liking the arm6? In any case not starting doesn't seem to do any harm and so it can prolly be left as-is but I'll have to do some more research to see if in fact its not really needed anymore and can be left out of future builds.

[Nutul]

- Right, quote the args.

Hi Tim,

actually, it's not just quoting, it is having something added to the variable, in order to not have an empty string on either side of the comparison:
I usually add an "x" before, and one after, the variable name (which needs then to be enclosed by curly braces in order to not change its name...).

Of course, the same has to be done with the literal string, hence the "x${MODEL}x" "x3x", so that in case $MODEL is empty, or undefined, the comparison still reads "xx" = "x3x", which will return false, of course, but won't confuse (ehm, crash) the bash parser.

Quoting is mandatory, of course.

[TheOldPresbyope]

- Right, quote the args.

Hi Tim,

actually, it's not just quoting, it is having something added to the variable, in order to not have an empty string on either side of the comparison:
I usually add an "x" before, and one after, the variable name (which needs then to be enclosed by curly braces in order to not change its name...).

Of course, the same has to be done with the literal string, hence the "x${MODEL}x" "x3x", so that in case $MODEL is empty, or undefined, the comparison still reads "xx" = "x3x", which will return false, of course, but won't confuse (ehm, crash) the bash parser.

Quoting is mandatory, of course.

This is essentially the shell script equivalent of a pattern which appears repeatedly in the php code where the very existence of a value is tested before testing whether it's equal to a specific value. Nice catch.

Regards,
Kent

[TheOldPresbyope]

I'll run my zero with the entropy service disabled for a while to see if anything goes wrong.  Since it's for seeding encryption and so on, I can't see moOde relying on it too much...

I did find my Zero W and with the change to the is-system-running check in worker it booted up a fresh image without any issues.

According to the doc the is-system-running check returns "degraded" if any systemd unit fails to start and in this case it's the haveged unit. It won't start on my Zero W and apparently on your Zero as well. Maybe it's not liking the arm6? In any case not starting doesn't seem to do any harm and so it can prolly be left as-is but I'll have to do some more research to see if in fact its not really needed anymore and can be left out of future builds.

Curious. I just tried flashing yet another 32-bit image (using RPi Imager to download it) and starting on my Zero W. I got the same kind of problematic result got before. Have to start digging.

Regards,
Kent

[Macdelf]

echo '0' | sudo tee -a /sys/class/leds/PWR/brightness > /dev/null
echo '255' | sudo tee -a /sys/class/leds/PWR/brightness > /dev/null

to turn power led off and on

Cheers,

Phil

Or...
In the old directory designations /sys/class/leds/led0/ /sys/class/leds/led1/ replace led0 with ACT and led1 with PWR and all works as before
os.system("sudo sh -c 'echo 0 > /sys/class/leds/PWR/brightness'")

os.system("sudo sh -c 'echo 0 > /sys/class/leds/ACT/brightness'")
turns all off in a python script. Echo1 turns all on

[Tim Curtis]

echo '0' | sudo tee -a /sys/class/leds/PWR/brightness > /dev/null
echo '255' | sudo tee -a /sys/class/leds/PWR/brightness > /dev/null

to turn power led off and on

Cheers,

Phil

Or...
In the old directory designations /sys/class/leds/led0/ /sys/class/leds/led1/ replace led0 with ACT and led1 with PWR and all works as before
os.system("sudo sh -c 'echo 0 > /sys/class/leds/PWR/brightness'")

os.system("sudo sh -c 'echo 0 > /sys/class/leds/ACT/brightness'")
turns all off in a python script. Echo1 turns all on

Confirmed.