[Raspberry Pi OS] platform.js does not recognise later versions of Raspberry Pi OS

[flatsiedatsie]

This code in platform.js does not work on Raspberry Pi OS versions above Buster:

// Check lsb_release for the name of a Linux distribution
  const proc = child_process.spawnSync('lsb_release', ['-i', '-s']);
  if (proc.status === 0) {
    const lsb_release = proc.stdout.toString().trim();
    switch (lsb_release) {
      case 'Arch':
        return 'linux-arch';
      case 'Debian':
        return 'linux-debian';
      case 'Raspbian':
        return 'linux-raspbian';
      case 'Ubuntu':
        return 'linux-ubuntu';
      default:
        return 'linux-unknown';
    }
  } else {
    return 'linux-unknown';
  }
}

as it results in, for example:

lsb_release -i -r
No LSB modules are available.
Distributor ID:	Debian
Release:	12

My hack to fix this has been to do an earlier check if raspi-config exists first:

const raspi = child_process.spawnSync('which', ['raspi-config']);
  if (raspi.status === 0) {
    const raspi_string = raspi.stdout.toString().trim();
    if(raspi_string.indexOf('raspi-config') != -1){
      return 'linux-raspbian';
    }
  }
  
  // Check lsb_release for the name of a Linux distribution
  const proc = child_process.spawnSync('lsb_release', ['-i', '-s']);
  if (proc.status === 0) {
    const lsb_release = proc.stdout.toString().trim();
    switch (lsb_release) {
      case 'Arch':
        return 'linux-arch';
      case 'Debian':
        return 'linux-debian';
      case 'Raspbian':
        return 'linux-raspbian';
      case 'Ubuntu':
        return 'linux-ubuntu';
      default:
        return 'linux-unknown';
    }
  } else {
    return 'linux-unknown';
  }
}

But there might be a more elegant solution. For example, this is one way to find the Raspberry Pi OS version:

cat /etc/os-release

[flatsiedatsie]

It could be that on later versions of Raspberry Pi OS it's not necessary to make it a special case. I'll investigate.

[benfrancis]

Hi @flatsiedatsie, thanks for reporting this.

As I understand it the 32-bit version of Raspberry Pi OS was based on the original Raspbian project so /etc/os-release reports ID=raspbian, but the 64-bit version was built directly on top of Debian so reports ID=Debian.

I note that there are a few features of linux-raspbian.ts which currently use the raspi-config utility which only comes with Raspberry Pi OS:

• getSshServerStatus()
• setSshServerStatus()
• setTimezone()
• getWirelessCountry()

Presumably if the OS gets detected as being Debian these features will no longer work.

To get these features working again we could either try to find a way to implement these features on vanilla Debian, or try to detect the presence of raspi-config as you've done above.

---

Just FYI, my current focus is on releasing WebThings Gateway 2.0 as a Docker image (and possibly a new balenaOS-based OS image). I currently have no plans to ship a Raspberry Pi OS-based image for WebThings Gateway 2.0, but if you wanted to work on that you would be welcome. Either way it unfortunately won't be possible to automatically upgrade existing users of the Raspbian-based image to 2.0 because Buster doesn't support Node.js 20 and we have no way to automatically dist-upgrade people to a newer Debian.

[flatsiedatsie]

Presumably if the OS gets detected as being Debian these features will no longer work.

Good point.

I ended up making a version that combines the raspi-config dependent features as well as the new async NetworkManager functions. Since they don't overlap, I could basically just combine them:

https://github.com/createcandle/candle-controller/blob/master/src/platforms/linux-raspbian.ts

Not everything is working yet though. Connecting to WiFi through the UI isn't stored. I'm looking into that. It's probably that instead of editing wpa_supplicant.conf this should now be handled by calling nmcli.

Just FYI, my current focus is on releasing WebThings Gateway 2.0 as a Docker image

I noticed. Cool to see these developments.

if you wanted to work on that you would be welcome.

Thank you.

I've been attempting to incorporate the changes of Gateway into Candle Controller, so that the two projects remain as closely aligned as possible. I ran into issues in my attempt, but I might try again later. Especially the new ability to get all devices through the root_api looks very tasty, and would aid in integrating many spread out controllers into one cohesive experience.

Either way it unfortunately won't be possible to automatically upgrade existing users

Yes, that has proven difficult.

With Candle the disk image is split into a read-only system partition, and a RW user data partition that is mounted at ~/.webthings. Some system settings locations are also moved over to that user partition through fstab. For example for bluetooth and wireless connections.

Then to upgrade the system, the system partition is replaced through an A/B update process. At least, that's the goal for the next version (3). Which means that new Candle disk images will have to start from scratch again because now there need to be to large system partitions..

Candle also has a backup-and-restore upgrade path that basically copies settings and configurations files only. Luckily, this 'fallback' works well, and in practice has been how an upgrade to the new A/B upgrade partition version will have to go.