Support for Raspberry Pi based (armhf) gateways

[shawaj]

We are keen to building support for armhf (Raspberry Pi) based gateways via balenaCloud

Would your preference be for us to add a PR for a new package for armhf here? And can we package that release as a .deb instead of .ipk to save having to compile opkg for armhf. I guess it is pretty simple to convert .ipk to .deb in any case.

And then we can just add a dockerfile and balena.yml for auto-deployment using deploy with balena.

[shawaj]

cc @ryanteck

[abhay]

Definitely open to ideas on how to make this work on armhf. Trying to decide if it's better to ship as a deb or as a docker container. Open to either, I think.

[ryanteck]

I don't see why a IPK can't possibly be compiled for armhf. From the best I can tell they're just packages with the pre-compiled binary

However the only question I have is for all the packages, wasn't IPKs superceeded by OPKs?

[madninja]

I don't see why a IPK can't possibly be compiled for armhf. From the best I can tell they're just packages with the pre-compiled binary

However the only question I have is for all the packages, wasn't IPKs superceeded by OPKs?

I wish it was! Perhaps on the Pi IPK was superseded but most low end gateways I'v looked at so far are openWRT based and use opkg to manage package lifecycles.

PRs definitely welcome! The goal is to have self-updating gateways, which can really be packaged in any way that achieves that purpose for the target platform

[ryanteck]

A docker container could be the better route for easily updated archives on the RPi.

I thought OpenWRT had changed to opks but I might be wrong, been a while since I used OpenWRT.

Edit Yep I'm wrong, I think IPKs can work on the Pi as well. Or the docker route could be better.

[madninja]

A docker container could be the better route for easily updated archives on the RPi.

For balena, sure! and it'd be cool to see that support in the repo.. A new cargo make profile with a "package" include for make rules for the "balena" profile should be able to support this quite easily.

I'm not going to argue which one is better :-) One is lighter weight than the other, and some installations might prefer one over the other.. all good

I thought OpenWRT had changed to opks but I might be wrong, been a while since I used OpenWRT.

ipk and opk are the same thing afaict

[shawaj]

Yep @madninja is correct on ipk and opk one is just a forked version of the other.

And both are essentially the same as .deb just that one uses ar and the other tar...

@abhay I think docker containers would be nicer, but then I do work at balena so I would say that 😉

[madninja]

Yep @madninja is correct on ipk and opk one is just a forked version of the other.

And both are essentially the same as .deb just that one uses ar and the other tar...

Yup

@abhay I think docker containers would be nicer, but then I do work at balena so I would say that 😉

heh, naturally! A docker option would be nice for some. Unfortunately, I can't run docker on any of the current gateways I'm working with.. the footprint just doesn't allow it. It'll be a mix of packaged up installation options

[ryanteck]

A deb package could be the best route, but for the easy adaptability to be there some Deb server needs to be setup to be used as a route of updating.

[madninja]

A deb package could be the best route, but for the easy adaptability to be there some Deb server needs to be setup to be used as a route of updating.

yeah, and that's assuming a Deb server is what's needed? openwrt has it's own package stream /server which I shied away from in favor of a self-updater based on GitHub releases for now. opkg self updating still requires something to actually run the updates and it doesn't handle alpha/beta release streams very well. Open to other suggestions that are portable across platforms though

[ryanteck]

IRC for Debain based distros packages that are distributed via deb repos yes. The only application I use that I know doesn't run a Deb server requires me to download the new DEB package each time and install it. It could possibly be automated with a script but not the ideal route.

A deb however I suspect would cover the Raspberry Pi + Most other SBCs as it's quite rare for an SBC or variant to not have some Debian based port.

[madninja]

Sure.. I wish we could be consistent across all targets, but at least it's all IPK for openWRT targets and all debs for more modern Debian distros.

[ryanteck]

IPKs might work, the issue is it's common for packages to have to be compiled for many architectures?

The thing is if a IPK has to be packaged for each architecture then it's not fully consistent. From what I can tell the compile steps are the same but it's just the packaging which varies?

[madninja]

IPKs might work, the issue is it's common for packages to have to be compiled for many architectures?

There aren't that many cpu architectures to support and yes it's common for more targeted embedded linux uses (like openWRT)

The thing is if a IPK has to be packaged for each architecture then it's not fully consistent. From what I can tell the compile steps are the same but it's just the packaging which varies?

The CPU architecture is likely shared between multiple platforms. The packaging details vary per platform. The current design has each platform (called profile in the cargo make world) as a combination of cpu target triplet and a packaging setup. armhf/docker is really just another combination of that in my current thinking

[ryanteck]

For the Raspberry Pi there's actually ARMV6 & ARMV7,

Weather the package compiled for the Kerlink ARmv7 for the ARMV7 pis it might work. However the ArmV6 is also often used for earlier Models.

Plus I believe some are shifting to 64 Bit for the latest Pi Models, so that's potentially 3 different archiectures for the Raspberry Pi.

[madninja]

Sure! that should all be possible, no?

I guess I'm losing the point of this discussion? If you want to have a docker based setup for a single build setup to support a docker based build, the current setup will support it just fine. My point is that we can't use it across the board because not everyone is running on a capable enough machine to support it.

[ryanteck]

Sure, what I meant was that it's common for software to get automatically compiled for different archiectures and different packaging formats so I didn't see why the requirement of ideally keeping with IPK is an issue.

The argument of having a package that runs across the board being an IPK is invalid as an IPK doesnt' run across the board. So there's going to be the requirement of a few different packages. (At least say IPK & DEB).?

[madninja]

Sure, what I meant was that it's common for software to get automatically compiled for different archiectures and different packaging formats so I didn't see why the requirement of ideally keeping with IPK is an issue.

The argument of having a package that runs across the board being an IPK is invalid as an IPK doesnt' run across the board. So there's going to be the requirement of a few different packages. (At least say IPK & DEB).?

ah ok, I never said or intended for IPK to be the only packaging format. Anything that makes it work for the target platform is fair game.

[ryanteck]

Ahh ok, yeah some confusion indeed!

I think Deb could be the best route for RPi based gateways as I don't see why it wouldn't then be for those wanting to use Docker a case of just installing the deb into the docker image. So it covers that base as well.

Plus it then should support most ARM Based SOCs that run a varaint of Debian. And I think that would cover 99% of gateways.

[madninja]

Unclear about that 99% but otherwise fully agree

[shawaj]

@madninja is your thought to have auto updates every boot / every day or something like that?

@ryanteck Can .deb support auto updates each time a new release is available?

[shawaj]

By the way, yesterday I managed to use an .ipk to install on Debian by just using tar to unpack and ar to repack and then dpkg / gdebi. Not the kerlink one here but the package is very similar to deb and to all extents and purposes is the same.

The only thing being as you say @ryanteck is that for a lot of gateways it would be a single arch in each .ipk

And I like the idea of GitHub releases. Seems nice and clean. And yeah for deploy with balena or other docker usage can just have a docker file that just installs the .deb or whatever

[ryanteck]

@shawaj Debs cannot update automatically without being pushed to a deb server to the best of my knowledge.

I don't think that's possible with IPKs either, I'm not sure. Whenever I've had to install IPKs on devices they've either had a server they've downloaded from as a source or something like that.

[madninja]

Yeah.. the self-updater can be turned of in settings.toml if an alternate self update path is used, like in balena's case

[madninja]

@shawaj Debs cannot update automatically without being pushed to a deb server to the best of my knowledge.

I don't think that's possible with IPKs either, I'm not sure. Whenever I've had to install IPKs on devices they've either had a server they've downloaded from as a source or something like that.

I can confirm that the self updater actually works with ipks. No server/source required. The self updater checks for a release on GH, downloads it to temp storage and then invokes an install_update script, which by and large just calls opkg install. And I'm pretty sure debs can be installed manually without a server too :-)

[ryanteck]

So it's not actually the IPK nor OPKG that does the updating, it's a script that is running as part of the software that checks?

[madninja]

So it's not actually the IPK nor OPKG that does the updating, it's a script that is running as part of the software that checks?

Yep.. most of these openWRT package streams are all over the place and many not up to date at all. There's a built-in updater that checks GH releases periodically and then invokes the local package installer.

Again this is not how it has to work for more modern distros at all, just the hoops to jump through for the low end

[shawaj]

So we can just use that, check for a new .deb periodically and then use gdebi to install or dpkg or whatever

Or turn it off and use Balena or whatever

[ryanteck]

So to be correct, it's not the IPK format that enables the self updating. It's a script checking for new releases and essentially automating the steps of manually updating it. So I am correct in saying IPKs do not automatically update.

You could do the same with a DEB. However ideally the best route would be to get it on an apt server to do it properly and securely.

[madninja]

So to be correct, it's not the IPK format that enables the self updating. It's a script checking for new releases and essentially automating the steps of manually updating it. So I am correct in saying IPKs do not automatically update.

You are definitely correct.. nothing in IPK/OPK or DEB for that matter automatically updates anything. You'd have to run something to check for updates.

You could do the same with a DEB. However ideally the best route would be to get it on an apt server to do it properly and securely.

yeah.. and if there was a way to do the same cleanly with OPK release servers the update code could check that instead.. I just didn't see a way that would really help any of it to be more proper or secure for that part of the distro world (yet).

[shawaj]

@ryanteck might be an interesting play with the TPM in that we could send signed packages and verify they are legitimate using the TPM and PKI / CSR. Maybe not that trivial but would be a nice to have

[madninja]

Swerving off-topic a bit. I'll close this discussion issue.

[shawaj]

@madninja thanks for your help 👍

[shawaj]

For anyone finding this later see #17