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

[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.

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

Did you patch worker.php before first boot?

// Check for Linux startup complete
.
.

Change 
if ($result[0] == 'running') {

To
if ($result[0] == 'running' || $result[0] == 'degraded') {

[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

Did you patch worker.php before first boot?

// Check for Linux startup complete
.
.

Change 
if ($result[0] == 'running') {

To
if ($result[0] == 'running' || $result[0] == 'degraded') {

Oops. No

[yage2046]

This forum post I found says haveged is unnecessary if you have rng-tools / rngd (which moOde does).

https://forums.raspberrypi.com/viewtopic.php?t=246534

[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

Did you patch worker.php before first boot?

// Check for Linux startup complete
.
.

Change 
if ($result[0] == 'running') {

To
if ($result[0] == 'running' || $result[0] == 'degraded') {

Oops. No

Okay, made that patch and all is well other than the odd reintroduction of haveged, which as @yannig points out, is unnecessary. Now that I see his hint I vaguely remember a discussion of this problem before but maybe that was on a different forum.

systemctl status rng-tools shows the rng service is running.

Sorry for throwing in a red herring.

Regards,
Kent

[Tim Curtis]

This forum post I found says haveged is unnecessary if you have rng-tools / rngd (which moOde does).

https://forums.raspberrypi.com/viewtopic.php?t=246534

Right, it should not be necessary but I'll prolly leave it in upcoming 8.3.2 bugfix update because even though it fails to start on arm6 it doesn't seem to be doing any harm.

I also noticed there is rng-tools5 package available.

[demian.smith]

Just to chime in, I had the same issue. Moode reported the update, I downloaded / installed it, after the pop up "restart needed" i rebooted and got the "Linux startup failed to complete". I am using moode on a b03112 ( 4 Model B with 2 GB RAM). "sudo systemctl disable haveged" as mentioned followed by reboot fixed the issue for me as well.

[Tim Curtis]

Just to chime in, I had the same issue. Moode reported the update, I downloaded / installed it, after the pop up "restart needed" i rebooted and got the "Linux startup failed to complete". I am using moode on a b03112 ( 4 Model B with 2 GB RAM). "sudo systemctl disable haveged" as mentioned followed by reboot fixed the issue for me as well.

I've not seen this issue on anything other than arm6 Zero.

Are you running 32-bit or 64-bit moOde on the 4B?

[TheOldPresbyope]

@Tim Curtis 

A morning's perusal of the InterWeb™ regarding haveged and ARM has been instructive. Trouble is, more heat than light have been generated.

The root difficulty seems to be that haveged can look at lots of different system calls to help it "gather" entropy. Among other things, haveged apparently tries to get information about the CPU and somehow this triggers a call which isn't doesn't work in ARMv6 (and some others). Or something like that.

The most succinct solution I've seen which seems to work on moOde 8.3.1 running on ZeroW is the first offered by michalng at the end of haveged fails to start (systemd). --- Never mind that it is an Odroid/Armbian thread.

That is, add one more syscall to the filters (which were already specified in /lib/systemd/system/haveged.service)

Code:

mkdir -p /etc/systemd/system/haveged.service.d
echo -e '[Service]\nSystemCallFilter=uname' > /etc/systemd/system/haveged.service.d/syscall.conf

 
You'll find this solution suggested elsewhere also. One could, instead, just comment out the SystemCallFilter= lines in /lib/systemd/system/haveged.service but I prefer the indicated solution because it would seem less intrusive to the RPiOS distro and should be relatively immune to OS upgrades.

I didn't try his second solution which results in removing haveged (also upgrades to rng-tools5 but I'm not convinced that's required on a Pi). My reason: it gets into moOde's dependencies and held packages. You might try, though.

And, of course, I tested the patch both on moOde 8.3.1 Legacy booting on a Zero-W and on moOde 8.3.1 64bit booting on a Pi4B. No haveged-related error messages in dmesg or elsewhere and both systems appear to be working.

Regards,
Kent

[Tim Curtis]

@Tim Curtis 

A morning's perusal of the InterWeb™ regarding haveged and ARM has been instructive. Trouble is, more heat than light have been generated.

The root difficulty seems to be that haveged can look at lots of different system calls to help it "gather" entropy. Among other things, haveged apparently tries to get information about the CPU and somehow this triggers a call   which isn't doesn't work in ARMv6 (and some others). Or something like that.

The most succinct solution I've seen which seems to work on moOde 8.3.1 running on ZeroW is the first offered by michalng at the end of haveged fails to start (systemd). --- Never mind that it is an Odroid/Armbian thread.

That is, add one more syscall to the filters (which were already specified in /lib/systemd/system/haveged.service)

Code:

mkdir -p /etc/systemd/system/haveged.service.d
echo -e '[Service]\nSystemCallFilter=uname' > /etc/systemd/system/haveged.service.d/syscall.conf

 
You'll find this solution suggested elsewhere also. One could, instead, just comment out the SystemCallFilter= lines in /lib/systemd/system/haveged.service but I prefer the indicated solution because it would seem less intrusive to the RPiOS distro and should be relatively immune to OS upgrades.

I didn't try his second solution which results in removing haveged (also upgrades to rng-tools5 but I'm not convinced that's required on a Pi). My reason: it gets into moOde's dependencies and held packages. You might try, though.

And, of course, I tested the patch both on moOde 8.3.1 Legacy booting on a Zero-W and on moOde 8.3.1 64bit booting on a Pi4B. No haveged-related error messages in dmesg or elsewhere and both systems appear to be working.

Regards,
Kent

That could work.
I'll test adding the drop file.

[Tim Curtis]

@TheOldPresbyope,

The haveged drop file does in fact prevent the service fail on arm6 and has no side effects that I can see on arm6 or 7.
I'll add it to upcoming 8.3.2 bugfix release :-)