Forum › Forums › Official Releases › antiX-26 “Stephen Kapos” › It appears live-kernel-updater option disappears from CC after upgrade
- This topic has 13 replies, 3 voices, and was last updated Apr 25-2:23 pm by Robin.
-
AuthorPosts
-
April 23, 2026 at 3:10 am #202387
olsztyn
MemberIt seems live-kernel-updater icon disappears from the antiX Control Centre after yesterday’s update.
CLI mode seems to still work.Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersApril 25, 2026 at 7:09 am #202615olsztyn
MemberJusr a gentle reminder about this issue. Live kernel updater, update was intended to intended to include extending initrd function, if I am not mistaken. It would be good to still have it in the Control Center. In my testing this icon disappears after upgrade.
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersApril 25, 2026 at 7:45 am #202620Robin
MemberThanks for the reminder @Olsztyn
Obviously somebody had the crazy idea to move the position of the executable around in file system without any real need, so its presence is no longer recognised by antiX Control Centre. Why?
Hotfix:
Open /usr/local/bin/antixcc.sh in geany with root permission.
Head for lines 440 and 443Change in both lines
/usr/local/bin/live-kernel-updater
to ↓↓↓
/usr/bin/live-kernel-updaterand save script back to disk.
@anticapitalista : This asks for a package update of antiXcc. Do you prefer me sending a merge request for the fix, or can you insert the needed simple path adaption yourself directly?
Windows is like a submarine. Open a window and serious problems will start.
April 25, 2026 at 8:30 am #202627olsztyn
MemberObviously somebody had the crazy idea to move the position of the executable around in file system without any real need, so its presence is no longer recognised by antiX Control Centre. Why?
Thank you @Robin for attention to this issue…
As a general question regarding the Control Centre: Is it possible to make the Control Centre not so much sensitive to such change of location, so it would work even if a programmer updating an element decides to change location?
So, e.g. some time in the past (a few months ago) I was trying to update the same live-kernel-updater from the MX repository, which had a higher version than on antiX. In result the same thing was happening – icon disappeard from the antiX CC. I did not reported it at that time because it was an MX version, a part of MX 25 freshly published, so before antiX 26 was released. A difference in version continued however even after antiX 26 was officially released.
It would be great (not sure it is easy or possible at all) if antiX Control Centre was more resilient to such changes of location…- This reply was modified 5 months ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersApril 25, 2026 at 10:33 am #202652
anticapitalistaForum AdminDid you not get the update to the control centre?
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
April 25, 2026 at 11:09 am #202655Robin
MemberDid you not get the update to the control centre?
No idea. I have knitted the above hotfix without being on antiX 26, by downloading, extracting and inspecting the antiX 26 live-kernel-updater package from within antiX 23. Will check once back at my antiX 26 notebook.
Windows is like a submarine. Open a window and serious problems will start.
April 25, 2026 at 11:35 am #202657Robin
Member@anticapitalista Same issue on antiX 23 :
$ apt-cache policy control-centre-antix control-centre-antix: Installiert: 1.3.1 Installationskandidat: 1.3.1 Versionstabelle: *** 1.3.1 500 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/bookworm bookworm/main amd64 Packages 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/bookworm bookworm/main i386 Packages 100 /var/lib/dpkg/status $ apt-cache policy live-kernel-updater live-kernel-updater: Installiert: 0.2.24 Installationskandidat: 0.3.0 Versionstabelle: 0.3.0 500 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/bookworm bookworm/main amd64 Packages 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/bookworm bookworm/main i386 Packages *** 0.2.24 100 100 /var/lib/dpkg/status$ which live-kernel-updater /usr/local/bin/live-kernel-updater $ sudo apt-get install live-kernel-updater … $ which live-kernel-updater /usr/bin/live-kernel-updaterAfter full system apt upgrade the entry has disappeared from control centre in antiX 23 (64 bit) also.
Windows is like a submarine. Open a window and serious problems will start.
April 25, 2026 at 12:08 pm #202666
anticapitalistaForum AdminThis is the version in trixie
http://repo.antixlinux.com/trixie/pool/main/c/control-centre-antix/
I’ll update the deb in bookworm too.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
April 25, 2026 at 12:32 pm #202672Robin
MemberIs it possible to make the Control Centre not so much sensitive to such change of location
Yes, this is possible generally. Some entries are equipped with “which” instead of “test” against a hard coded path. But I’m pretty sure applying this to all entries will slow down startup time noticeably, while not sure about that (how to measure that?). There must be a reason why all the original/ancient control centre entries use test instead of which. If this is not a showstopper slowdown, we can easily replace all the test lines to use which instead of a hard coded path.
I’ll update the deb in bookworm too.
Many thanks!
Windows is like a submarine. Open a window and serious problems will start.
April 25, 2026 at 1:24 pm #202683Robin
MemberDid you not get the update to the control centre?
Confirmed that in antiX 26 (32 bit) everything was fine already. No issue here with missing kernel-updater entry.
$ apt-cache policy control-centre-antix control-centre-antix: Installiert: 1.4.4 Installationskandidat: 1.4.4 Versionstabelle: *** 1.4.4 500 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/trixie trixie/main i386 Packages 100 /var/lib/dpkg/status 0.8.8 500 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/trixie trixie/nosystemd i386 Packages $ apt-cache policy live-kernel-updater live-kernel-updater: Installiert: 0.3.0 Installationskandidat: 0.3.0 Versionstabelle: *** 0.3.0 500 500 http://ftp.halifax.rwth-aachen.de/mxlinux/packages/antix/trixie trixie/main i386 Packages 100 /var/lib/dpkg/status $ which live-kernel-updater /usr/bin/live-kernel-updater $ grep -n 'live-kernel-updater' /usr/local/bin/antixcc.sh 441:livekernel_prog=/usr/bin/live-kernel-updater 444: "desktop-defaults-run -t sudo /usr/bin/live-kernel-updater --pause &" \And that’s the simple explanation what’s going on. Found in current antixcc.sh header:
# 23 April 2026 by anticapitalista slowly move scripts from /usr/local/bin to /usr/binWindows is like a submarine. Open a window and serious problems will start.
April 25, 2026 at 1:28 pm #202684olsztyn
MemberDid you not get the update to the control centre?
If this was a question also to me (In English ‘you’ singular and ‘you’ plural forms are the same, so not distinguished) then my answer is that I did not update the CC before updating live-kernel-updater. Who would have thought there is such dependency on live tool…
Yes, this is possible generally. Some entries are equipped with “which” instead of “test” against a hard coded path. But I’m pretty sure applying this to all entries will slow down startup time noticeably, while not sure about that (how to measure that?). There must be a reason why all the original/ancient control centre entries use test instead of which. If this is not a showstopper slowdown, we can easily replace all the test lines to use which instead of a hard coded path.
Thank you @Robin for this analysis. I was only thinking of resiliency of the Control Center to ensure integrity and reduce dependency on changes to individual tools. Just as example I was thinking of the equivalent MX Control Center (it is called differently but it is immaterial to essence), I did not notice such sensitivity and dependency on changes to individual tools…
I am not trying to be critical of the way antiX Control Centre is coded, as I am appreciating antiX design as it is. I was just asking out of consideration whether further improvements to enhance resilience would be possible. Control Centre is a critical part of antiX after all…
Thanks again and best regards.Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersApril 25, 2026 at 1:35 pm #202685
anticapitalistaForum AdminThe new control centre in antiX-26 trixie repos fixes this issue.
Do you (both) not see it?Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
April 25, 2026 at 2:02 pm #202687olsztyn
MemberThe new control centre in antiX-26 trixie repos fixes this issue.
Do you (both) not see it?Just updated. I do see. It is fixed.
Thank you @anticapitalista!Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersApril 25, 2026 at 2:23 pm #202692Robin
MemberDo you (both) not see it?
↓↓↓
Confirmed that in antiX 26 (32 bit) everything was fine already.
Windows is like a submarine. Open a window and serious problems will start.
-
AuthorPosts
- You must be logged in to reply to this topic.