brimur
17 September 2026 11:30
1
Hi all,
My Vero 4K is currently on 2024.04-1 and when I go to My OSMC → Updates → Manual check it says there are no updates available. I’m guessing this has something to do with the outdated version is the APT sources? Can someone provide an update for the sources.list that I can apply to bring my 4K up to date?
Thanks
brimur
17 September 2026 15:14
2
Nevermind, I see the 4K is EOL so Im guessing there are not new updates
The last version for the 4K is 2025.03-1. If the updater in the My OSMC add-on isn’t working you could try ssh and…
sudo apt-get update && sudo apt-get dist-upgrade
1 Like
j0hn26
17 September 2026 19:23
4
hola, me puedes decir paso a paso para actualizar por comandos , gracias
brimur
18 September 2026 09:42
5
root@osmc:~# sudo apt-get update && sudo apt-get dist-upgrade
Hit:1 http://archive.debian.org/debian buster InRelease
Hit:2 http://archive.debian.org/debian-security buster/updates InRelease
Hit:3 https://ftp.fau.de/osmc/osmc/apt buster InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@osmc:~#
1 Like
brimur
18 September 2026 09:43
6
root@osmc:~# sudo apt-get update && sudo apt-get dist-upgrade
Hit:1 http://archive.debian.org/debian buster InRelease
Hit:2 http://archive.debian.org/debian-security buster/updates InRelease
Hit:3 https://ftp.fau.de/osmc/osmc/apt buster InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@osmc:~#
It says there are no updates. I feel like my Sources.list is wrong or somthing like that. When I do it from the Kodi GUI it also says no updates available
1 Like
j0hn26
18 September 2026 12:59
7
hola, gracias por la respuesta anterior… mi version osmc es del 2025.03-1 es la ultima o me falta actualizar ?, tambien tengo otro problema cuando le doy mucho trabajo abriendo addons, me pone la tipica carita triste y vuelve a reiniciar, estoy apunto de devolver este dispositivo, que puedo hacer para configurar… gracias amigo
brimur
20 September 2026 09:43
9
Thanks @sam_nazarko , I ran the hotfix, confirmed yes, but It doent give me any feedback in he GUI. Should it say it found a hotfix and ran it and it was now complete? You mentioned in the post about doing it via SSH but did you mean running the hotfix or doing the hotfix steps manually? I didnt see the commands for either in the post. Sorry if I missed it.
Could you just let me know what state my sources.list should be in at the end of hte process and I will paste that in. Thanks again
Hi, there will be no further messages after applying the hotfix in the GUI. Afterwards the apt sources.list should show
deb https://deb.debian.org/debian bullseye main contrib non-free
deb https://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb https://apt.osmc.tv bullseye main
deb https://apt.osmc.tv bullseye-security main
1 Like
No, there is no indicator that it succeeded.
Which is a bit dumb. We could send a Kodi toast (but that would assume defaults).
It’s something that I am working on in a future update, but it’s not landed yet, and it won’t until you can update again yet..
See:
committed 11:24PM - 20 Sep 26 UTC
A HotFix gave no indication of whether it had worked. The dialog closed and the
… user was left to guess, which is the most common complaint about the mechanism
since updates2026fix was published.
apply_instruction() now returns the command that stopped the run, or None if
every command returned zero. It could not report before because it did not track
this: a successful run and a run that died on its first command both came back
as the same list of output lines. The caller shows "HotFix complete" or "HotFix
failed", the latter naming the command that stopped so a forum report can say
which step broke.
stderr is folded into the captured output. apt writes its warnings and most of
its errors there, so the saved and uploaded output previously omitted exactly
the part needed to diagnose a failure.
A HotFix that needs a restart now touches /tmp/reboot_needed_hotfix and the user
is asked once the run has finished. Rebooting from inside a HotFix would kill
its own remaining commands, and a fixed header field could not express "restart
only if something actually changed". The user is asked rather than counted down:
these devices run recordings and are used by people other than whoever applied
the HotFix, so a timer that fires into an empty room is worse than a prompt that
waits. Declining hands the request to /tmp/reboot-needed, which the updater
already watches, so it is not lost. A failed HotFix never offers a restart and
leaves the flag untouched.
The SAVE resolution is removed. It copied command output to /boot, which on a
Raspberry Pi is the small FAT partition the device boots from. The output is
already in the Kodi log and at /var/tmp/uploadHotFixOutput.txt, both of which
grab-logs collects, so nothing is lost by not writing it there. The same applies
to the prompt offered when an upload failed: an upload failure means no network,
and a device with no network could not have fetched the HotFix in the first
place, so it pointed at /boot for a case that barely exists. It now says where
the output already is.
parse_hotfix() gains '#' comments. Without them every line is a command, so a
HotFix cannot explain itself and a template cannot document its own fields --
'# do X' would be split to ['#', 'do', 'X'] and executed. Nothing legitimate
begins a command with '#', so no existing HotFix changes behaviour; the
published updates2026fix payload still parses to the same six instructions.
The RESOLUTION splitter is rewritten. It tried each separator in turn and split
on the first one present, so every natural way of writing more than one action
was broken: 'UPLOAD, LOG' split on the space into 'UPLOAD,' and 'LOG', and the
malformed half was discarded without a word, so the output was never uploaded;
'UPLOAD | LOG' left a bare '|'; and 'UPLOAD;LOG' did not split at all because
the docstring offered a semi-colon that was never in the separator list. Only
'UPLOAD LOG' and 'UPLOAD,LOG' worked, and nothing reported the difference. It
now splits on any run of separators, so all twelve forms tested behave the same.
HOTFIX-TEMPLATE.txt is a working HotFix that exercises every feature of the
format and documents each in its own comments: DESCRIPTION, comments both flush
and indented, blank lines, the optional INSTRUCTION: prefix, multi-action
RESOLUTION, sh -c for the pipes and tests that have no shell to run in, single
quoting so backslashes survive, cp -n so a second run cannot overwrite the
backup with the already-modified file, a grep -c step that turns
stop-on-first-failure into a guard against a sed that matched nothing, and the
conditional restart flag. It sits at the package root and is not shipped in the
.deb.
Also corrects a path in service_entry.action_list_complete(), which tested
'fname/var/run/reboot-required' -- a relative path that never exists, so that
branch only ever fired on /tmp/reboot-needed. It now calls
check_if_reboot_required(), which holds the correct list.
Checking for updates again under My OSMC → Updates → Manual Controls should suffice. A reboot isn’t needed.
Best,
Sam
1 Like
brimur
21 September 2026 08:44
12
Thanks @JimKnopf and @sam_nazarko for the assist. I updated my sources.list and then in the gui ran the updater but now it says the version is 2026,05-2. Will that be ok?
The last supported version for Vero 4K/4K+ is 2025.03-1.
You are running an unsupported version of OSMC by manually updating via SSH.
1 Like
Trying to come to grips on this. I want to repurpose my old 4k as a docker host. Will there be a way to upgrade to Debian 13?
thanks
Not via OSMC. Updates for this device have ended.
But you can still run a modern version of docker and as such modern containers.