I did a little looking into this last night as I am having the same problem. Here’s what I came up with. It looks like some of the jessie backports have been moved to:
I couldn’t find where in the docker build these pointers occur. If the references were changed, that me be a quick if albeit temporary fix just so devices can get back up. I’m not a terrific coder. I couldn’t find where in the original repo this occurs.
@Qwipt probably the best is to moving to a stretch image, instead of jessie, as it seems lot of the packages are missing as well, and the quick fix aboce might not be much use.
No arguments there. I would like to move over to something that isn’t being deprecated, of course. My only reason for looking for a quick fix is that it would complete a tutorial that I have followed here:
My reason for holding on to this tutorial, is that for me personally to move to stretch…I don’t know how I’d make that change and integrate it with the rest of the setup that looks like it has integrations outside of a standard debian build.
I’m just not that good of a programmer. I tried to find where the pointers were in the original repos being used as I thought if I could find them, I could point them towards the couple places where they’ve been moved to in the archives. Alas, I couldn’t find those places.
Do you know of a tutorial, or a basic starting place to get a RAK831 up and going with a stretch build?
Thanks for the input. I know helping someone less experienced such as myself isn’t your top priority, so when I say I appreciate you joining the conversation, I mean it.
Looking at this a little better, it seem like resin/raspberrypi3-debian:latest points to a Jessie image. Shouldn’t latest point to the latest version of Debian, ie. Stretch?
Or as a workaround, you can add this line in your jessie based image before any kind of apt-get call, to fix things up:
I’m wondering what the “official” recommended approach would be? I have ~30 devices in the field that can’t be updated at the moment. I’m fine with using the “workaround”, but I’m wondering if that is the best long-term approach? I haven’t used sed so I’m not familiar with the syntax to understand exactly what the workaround command is doing (I image just replacing some references to jessie?).
I’m open to migrating to the balenaLib images, jessie or stretch, though I think we’d prefer jessie just to ensure we don’t introduce any regressions / bugs into our production devices inadvertently.
Appreciate any feedback / insight!
P.S. I see this note:
probably the best is to moving to a stretch image, instead of jessie , as it seems lot of the packages are missing as well, and the quick fix aboce might not be much use.
But it’s unclear if that applies to everyone in general or a specific user based on specific use-cases.
@jpmeijers all resin/* base images are now deprecated and will no longer be updated, and so the latest tag will continue to point to jessie and will not be updated. If you use the balenalib images the latest tag will point to stretch.
@nathan it’s recommended to update to stretch if you can because jessie security supported ended in 2018 and LTS will end completely in 2020. However if you move to the balenalib images and use jessie you’ll no longer encounter the problem and not have to use the sed workaround, see this issue as posted above: https://github.com/balena-io-library/base-images/issues/532
Our “official” line is to start using the balenalib base images as soon as you can, even if you continue to use jessie