service fails badly on non target platform

Bug #1898160 reported by Christian Ehrhardt 
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
rpi-eeprom (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

If run on e.g. an arm64 container it now installs fine at least (thanks!).
But some issues are left that could be more graceful.

root@groovy-arm64:~# systemctl status rpi-eeprom-update.service
● rpi-eeprom-update.service - Check for Raspberry Pi EEPROM updates
     Loaded: loaded (/lib/systemd/system/rpi-eeprom-update.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2020-10-02 06:23:25 UTC; 15s ago
    Process: 488 ExecStart=/usr/bin/rpi-eeprom-update -a (code=exited, status=2)
   Main PID: 488 (code=exited, status=2)

Oct 02 06:23:25 groovy-arm64 systemd[1]: Starting Check for Raspberry Pi EEPROM updates...
Oct 02 06:23:25 groovy-arm64 rpi-eeprom-update[492]: od: /sys/firmware/devicetree/base/system/linux,revision: No such file or directory
Oct 02 06:23:25 groovy-arm64 rpi-eeprom-update[488]: /usr/bin/rpi-eeprom-update: 272: arithmetic expression: expecting ')': "(0x >> 23) & 1"
Oct 02 06:23:25 groovy-arm64 systemd[1]: rpi-eeprom-update.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Oct 02 06:23:25 groovy-arm64 systemd[1]: rpi-eeprom-update.service: Failed with result 'exit-code'.
Oct 02 06:23:25 groovy-arm64 systemd[1]: Failed to start Check for Raspberry Pi EEPROM updates.

Maybe a ConditionPathExists=/sys/firmware/devicetree/base/system/linux,revision or such would already help?

Revision history for this message
Dave Jones (waveform) wrote :

In the update to rpi-eeprom 10.3-1 (LP: #1906434), there's a bit more logic in rpi-eeprom-update that provides a fallback if /sys/firmware/devicetree/base/system/linux,revision doesn't exist (using /proc/cpuinfo or vcgencmd otp_dump as a last resort). For that reason, it's probably not ideal to include the ConditionPathExists suggested (it would potentially block rpi-eeprom-update from running even when it should).

I'm also not entirely convinced the service should "stay quiet" if installed on non-pi hardware. Wouldn't an admin who'd (presumably accidentally) installed this package on their arm64 non-pi hardware want to know there's a service attempting (and failing) to flash a non-existent EEPROM on their hardware?

Or is there a scenario I'm missing where installing this on arm64 non-pi hardware is expected, and leaving it installed is reasonable? If there is, I suspect something a bit more invasive may be required as /sys/.../linux,revision exists on quite a lot of arm64 non-pi hardware. What may be required is to add a Raspberry Pi specific check to /usr/bin/rpi-eeprom-update to have it exit successfully if it finds itself on such hardware (checking for a "Raspberry Pi" prefix in /sys/.../model should be sufficient).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rpi-eeprom - 12.4-1ubuntu2

---------------
rpi-eeprom (12.4-1ubuntu2) impish; urgency=medium

  * d/control: Remove redundant linux-firmware-raspi2 dependency
  * d/control: Demote libraspberrypi-bin dependency to recommendation; it's
    only required for querying the bootloader configuration on older firmwares
    which don't exist on impish

 -- Dave Jones <email address hidden> Wed, 23 Jun 2021 11:01:33 +0100

Changed in rpi-eeprom (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.