I have occasionally done remuxing on Raspberry Pi 2–4, and no, it doesn’t take very long, because remuxing (unlike reencoding) is limited only by disk-write speed. In any event, I’m just pointing out one example package from the several that OSMC power users will have become accustomed to, since OSMC was Debian under the hood.
1 Like
We already started the transition to Debian 13.
1 Like
I just noticed that my Vero V doesn’t have any updates through the GUI, but it had quite some through CLI, but it seems it doesn’t want to update openjdk, could this be caused by Debian 11 being EOL?
osmc@verov:~$ sudo apt dist-upgrade
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following packages will be upgraded:
openjdk-11-jre openjdk-11-jre-headless
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 34.1 MB of archives.
After this operation, 18.4 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Err:1 https://security.debian.org bullseye-security/main armhf openjdk-11-jre armhf 11.0.32.1+1-1~deb11u1
404 Not Found [IP: 151.101.194.132 443]
Err:2 https://security.debian.org bullseye-security/main armhf openjdk-11-jre-headless armhf 11.0.32.1+1-1~deb11u1
404 Not Found [IP: 151.101.194.132 443]
E: Failed to fetch https://security.debian.org/pool/updates/main/o/openjdk-11/openjdk-11-jre_11.0.32.1%2B1-1~deb11u1_armhf.deb 404 Not Found [IP: 151.101.194.132 443]
E: Failed to fetch https://security.debian.org/pool/updates/main/o/openjdk-11/openjdk-11-jre-headless_11.0.32.1%2B1-1~deb11u1_armhf.deb 404 Not Found [IP: 151.101.194.132 443]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
You can use the archive URLs
I have something smoother planned if you can wait a day or two.
We don’t ship JDK by default, so guess you’ve been trying out BD-J menu support.
Sam
1 Like
Kodi v22 is in b2: https://kodi.tv/article/kodi-22-piers-beta-2/
OK, but Beta 2 appeared more than two months after Beta 1. I hope you aren’t going to let your users suffer from broken systems and lack of security updates for non-OSMC-supplied packages for weeks or months until 22 Final appears. And if you didn’t know that this was going to happen as soon as Bullseye went EOL, how much can users trust your skills to keep their systems safe?
Trixie isn’t dependent on the release of Kodi v22.
I don’t know why you would think that is the case.
I have indeed, in the archive URLs only older versions, guess I will remove them then
I was just bitten by the debian-security situation on my Vero V. There’s a debian bug discussing the bullseye debs disappearing while the metadata did not disappear. In the interim, based on a reply in that issue, I made the following change to /etc/apt/sources.list on my Vero:
#deb https://security.debian.org/ bullseye-security main contrib non-free
deb https://snapshot.debian.org/archive/debian-security/20260903T220410Z/ bullseye-security main contrib non-free
The debs are all available in that snapshot, but apt won’t want to use the repo metadata due to signature expiration. You can bypass the relevant check like this
apt-get -o Acquire::Check-Valid-Until=false update
apt-get -o Acquire::Check-Valid-Until=false dist-upgrade
That got the last debian-security updates installed for me. You can likely use this “trick” to install new packages with debian-security dependencies as well. If you won’t be installing new packages, it would likely be best, after getting your updates installed, to revert sources.list to the default url, otherwise you may see warnings during automated update checks. Obviously this is duct tape on the actual issue, hopefully we won’t be on bullseye much longer.
Better to do this OSMC update issues solution
I’d not recommend you do this.
I don’t know how long the snapshot repository will stay up, it’s a single box and has limited connectivity and availability.
You won’t need to do that. Debian started re-signing the security repository, which is why apt-get update started working again; but the actual URLs give 404s because the security repository is no longer actually serving packages.
As Graham has suggested, it’s better to follow the solution I’ve made available.
Sam