KLV-Airedale-beta25 with Debian Kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC

[wiak]

Any bigger RAM load would suggest you had something new started up that wasn't started up previously. Certainly shouldn't be to do with merged filesystem disk size since that just gets mounted by default.

No idea why boot issue if using uuid method - that way shouldn't care about sdX, just aims for partition with provided UUID whatever the system calls it. Worth tracking down the reason though to see how sdX becomes involved

[geo_c]

....the whole system is merged to 01KLV.

Nice! Good experiment.

You can rename 01KLV to 07KLV so not to interfere with 00modules and 01firmware

Oh, I actually did not include 00modules and 01firmware within my install directory, I moved them to another folder and it still ran seemingly okay. Perhaps I should put those back. I wasn't sure if the initrd is looking for a particular name for the rootfs. Maybe you're saying it's looking for 01KLV or 07KLV.

Should I drop those modules back into the install directory and rename 01KLV? Wait... Looks like @fredx181 says that all was merged in the remaster.

[rockedge]

@geo_c If what you have is working as expected then no changes are needed. A boot stanza can be configured to find the module and firmware SFS in a separate location (I am pretty sure)
Otherwise all of the SFS's are merged into one 01KLV and there is then a lot of open room down the road for rows of XXupper_changes.

Interesting to see what would happen if the 01KLV.sfs was setup as a "frugal pseudo full install" and how well it would work. Another method then can be used to remaster or run it like it's a fully installed Linux but it's frugal

[geo_c]

Any bigger RAM load would suggest you had something new started up that wasn't started up previously. Certainly shouldn't be to do with merged filesystem disk size since that just gets mounted by default.

No idea why boot issue if using uuid method - that way shouldn't care about sdX, just aims for partition with provided UUID whatever the system calls it. Worth tracking down the reason though to see how sdX becomes involved

Yes you're right, looks like my unmerged system comes in at 840mb of ram on boot, and the merged was reading 920mb after using it for a few minutes, so probably they're about the same.

The boot from USB issue is bizarre, and like I say, on that computer, vanilladpup, fatdog, fossapup, and jackalpup all see the USB as sda1 and the computer's ssd drive as sdb1. However they all boot, and looking at these stanzas below, I think it may have to do with the fact they are able to use the pmedia=usbflash parameter.

Code: Select all

# Frugal installed Puppy

title jackalpup 0.0 (sdb2/jackal-frugal-LowLatency)
  find --set-root --ignore-floppies --ignore-cd /jackal-frugal-LowLatency/initrd.gz
  kernel /jackal-frugal-LowLatency/vmlinuz    psubdir=/jackal-frugal-LowLatency pmedia=usbflash pfix=fsck
  initrd /jackal-frugal-LowLatency/initrd.gz

title fossapup64 9.5 (sdb2/fossapup64)
  find --set-root --ignore-floppies --ignore-cd /fossapup64/initrd.gz
  kernel /fossapup64/vmlinuz    psubdir=/fossapup64 pmedia=usbflash pfix=fsck
  initrd /fossapup64/initrd.gz

title vanilladpup 9.2.17 (sdb2/vanilladpup-9.2.17)
  find --set-root --ignore-floppies --ignore-cd /vanilladpup-9.2.17/initrd.gz
  kernel /vanilladpup-9.2.17/vmlinuz    psubdir=/vanilladpup-9.2.17 pmedia=usbflash pfix=fsck
  initrd /vanilladpup-9.2.17/initrd.gz

title Fatdog64 (sdb2/Fatdog64-811)
  find --set-root --ignore-floppies --ignore-cd /Fatdog64-811/initrd
  kernel /Fatdog64-811/vmlinuz    psubdir=/Fatdog64-811 pmedia=usbflash pfix=fsck
  initrd /Fatdog64-811/initrd

# Full installed Linux
  
title Linux KLV-airedale20-2 (sdb2/KLV-airedale20-2-UUID)
  find --set-root uuid () 1b186e42-4f56-4cf3-bc41-863feab8ee43
  kernel /KLV-airedale20-2/vmlinuz w_bootfrom=UUID=1b186e42-4f56-4cf3-bc41-863feab8ee43=/KLV-airedale20-2 net.ifnames=0
  initrd /KLV-airedale20-2/initrd.gz  

title KLV-airedale20dev (sdb2/KLV-airedale20dev-UUID)
  find --set-root uuid () 1b186e42-4f56-4cf3-bc41-863feab8ee43
  kernel /KLV-airedale20dev/vmlinuz w_bootfrom=UUID=1b186e42-4f56-4cf3-bc41-863feab8ee43=/KLV-airedale20dev net.ifnames=0 
  initrd /KLV-airedale20dev/initrd.gz

[wiak]

The boot from USB issue is bizarre, and like I say, on that computer, vanilladpup, fatdog, fossapup, and jackalpup all see the USB as sda1 and the computer's ssd drive as sdb1. However they all boot, and looking at these stanzas below, I think it may have to do with the fact they are able to use the pmedia=usbflash parameter.

Well, it shouldn't really be needed but I left in a way to get a delay prior to beginning boot so maybe worth trying that:

Add the following option to the grub kernel line:

w_usbwait=15

will cause a delay of 15secs before system tries to continue boot.
If that works you can adjust the 15 to another value (smaller if possible) later.

[fredx181]

Well, I was thinking that the KLV-rootfs was loaded in ram

With Puppy loading the .sfs's in RAM is automatically done (unless you specify not pfix=nocopy, with KLV it's not, unless you specify copy2ram on the boot commandline.

[geo_c]

Well, it shouldn't really be needed but I left in a way to get a delay prior to beginning boot so maybe worth trying that:

Add the following option to the grub kernel line:

w_usbwait=15

will cause a delay of 15secs before system tries to continue boot.
If that works you can adjust the 15 to another value (smaller if possible) later.

I'll give that a try later, it probably has to do with the fact that this newer computer and USB stick use a fast USB3 port and my other machines are all USB2.

[wiak]

I'll give that a try later, it probably has to do with the fact that this newer computer and USB stick use a fast USB3 port and my other machines are all USB2.

Might help if you give full details of that newer computer. It may be something to do with the model needing special firmware or something else in which case w_usbwait=15 won't help.

[geo_c]

Maybe I should start a new topic, but I thought I'd put this here since I'm working out of beta25.

Fortunately, I've gotten good enough with manipulating upper_changes that I can break the system and revert with little effort. My remaster has been running well, and I've added a couple of numbered upper_changes directories after making tweaks. The nice thing about upper_changes as opposed to a save file, is you can document the incremental growth of the system a little more easily, and roll back to specific spots.

So my question or comment has to do with doing a system wide update yesterday.

I installed the Void updates which also updated lilypond and that seemed to break frescobaldi, the lilypond code editor. However after rolling back and breaking it again, then examining the terminal output of the xbps update, I'm more inclined to think frescobaldi broke due to python3.10.8 apparently updating to python3.11.0_1. And I notice from the output below that it byte compiles code for modules of python based applications like ranger.

Code: Select all

python3-3.11.0_1: configuring ...
Byte-compiling python code in usr/lib/python3.11...
Byte-compiling python3.11 code for module README.txt...
Updating ldconfig(8) cache...
python3-3.11.0_1: updated successfully.
python3-PyQt5-5.15.7_2: configuring ...
Byte-compiling python3.11 code for module PyQt5...
Updating ldconfig(8) cache...
python3-PyQt5-5.15.7_2: updated successfully.
python3-PyQt5-svg-5.15.7_2: configuring ...
Byte-compiling python3.11 code for module PyQt5...
Updating ldconfig(8) cache...
python3-PyQt5-svg-5.15.7_2: updated successfully.
python3-cairo-1.20.1_4: configuring ...
Byte-compiling python3.11 code for module cairo...
Updating ldconfig(8) cache...
python3-cairo-1.20.1_4: updated successfully.
python3-cups-2.0.1_4: configuring ...
python3-cups-2.0.1_4: updated successfully.
python3-gobject-3.42.2_2: configuring ...
Byte-compiling python3.11 code for module gi...
Byte-compiling python3.11 code for module pygtkcompat...
Updating ldconfig(8) cache...
python3-gobject-3.42.2_2: updated successfully.
python3-sip-PyQt5-12.11.0_2: configuring ...
Byte-compiling python3.11 code for module PyQt5...
Updating ldconfig(8) cache...
python3-sip-PyQt5-12.11.0_2: updated successfully.
ranger-1.9.3_4: configuring ...
Updating MIME database...
Byte-compiling python3.11 code for module ranger...
Updating ldconfig(8) cache...
ranger-1.9.3_4: updated successfully.

Running frescobaldi from the terminal gives me this error message below, which suggests since I installed it using @wiak's compiled package, perhaps it's not somehow being picked up by xbps and updated. Or maybe it's just incompatible with python3.11:

Code: Select all

root# frescobaldi
Traceback (most recent call last):
  File "/sbin/frescobaldi", line 31, in <module>
    from frescobaldi_app import toplevel
ModuleNotFoundError: No module named 'frescobaldi_app'

I checked the file /sbin/frescobaldi and line 31 says that it's looking for frescobali_app. I'm wondering how hard it would be to manually get the path correct, or the module built.

Or I might have to choose to ditch frescobaldi on KLV, or freeze my system updates at python3.10.8

OR, maybe I should just uninstall frescobaldi and reload the package? That sounds like it should work.

And maybe even a better idea is to roll back before updaing , and uninstall frescobaldi first, then update, then reload the package... am I getting warmer?

[rockedge]

And maybe even a better idea is to roll back before updaing , and uninstall frescobaldi first, then update, then reload the package... am I getting warmer?

I think this might work. Hold a backup in case of also trying the method of just putting the Python3 package on a xbps HOLD.

[geo_c]

And maybe even a better idea is to roll back before updaing , and uninstall frescobaldi first, then update, then reload the package... am I getting warmer?

I think this might work. Hold a backup in case of also trying the method of just putting the Python3 package on a xbps HOLD.

Well that was disappointing. I rolled back to upper_changes pre-system update, checked to see that frescobaldi was working. Used the xbps-remove frescobaldi-3.2_1 command. It seemed to go well. Then I uncompressed @wiak's package and ran the usual install commands that had worked in the past. The install looked normal, and it installed successfully, but then running from the terminal gave me the same error, frescobaldi_app module not found.

So I'm beginning to think that python3.11 is not going to play nice with frescobaldi.

[wiak]

I uploaded new v6.00 -rc2 initrd-latest.gz (along with matching winit-latest) to rockedge owncloud site. The usual get initrd-latest script should therefore fetch that new one automatically.

Only change is that minor addition (in w_init) of 'fuse' to the non-removed modules.

Sorry to hear frescobaldi not working again @geo_c. Alas, I expect whole thing needs re-created again for newer Python unless it has become official package in Void Linux repos. As you know that is a bit of a major undertaking and I don't have time just now since behind with other FirstRib build system matters I need to finish off. The details of how I got frescobaldi to work escape me now but it is all recorded in previous posts starting here: viewtopic.php?p=58811#p58811

Clearly a lot of bits and pieces were involved and not an easy job - problem is the issue likely to occur anytime new bits and pieces upgraded (Python for example). I would not put Python on HOLD though - too important to keep Python up-to-date. You should try going through how I made frescobaldi until you can manage and see if it can all be put step by step in an auto-build script; sorry I'm so short of time just now - maybe I'll have time in a few weeks to look into it if you don't manage.

I know it is huge, but a temporary way of dealing with this may be to install flatpak and frescobaldi via that? Afterall this is really the kind of situation when flatpak type packages are useful:

https://flatpak.org/setup/Void%20Linux

https://flathub.org/apps/search/frescobaldi

Else look here for alternative from tar.gz: https://frescobaldi.org/download (though maybe tried all that previously - I can't remember any more...)

[wiak]

I tried:

EDIT: You'd have to try it... I was using older KLV with older Python so below proves nothing... but worth a try - I have run out of time...

Code: Select all

flatpak install org.frescobaldi.Frescobaldi.flatpakref

once I had downlowded org.frescobaldi.Frescobaldi.flatpakref

That seemed to install, but no idea how to run it.

I then on same file tried:

Code: Select all

flatpak run org.frescobaldi.Frescobaldi.flatpakref

And the frescobaldi GUI popped up but errors in the terminal so no idea if working. May not be so simple...

The other build void linux package may turn out to be better, but knowing how to use flatpak might be helpful - I just don't know how to use it...

Also, I'm needing to update KLV-Airedale - I'm not sure which beta I'm using right now...

[wiak]

I tried:

EDIT: You'd have to try it... I was using older KLV with older Python so below proves nothing... but worth a try - I have run out of time...

Code: Select all

flatpak install org.frescobaldi.Frescobaldi.flatpakref

In case you missed by EDIT, see above... still needs tried on newer KLV...

It didn't work for me immediately after installing latest Python3 so not sure if I simply messed up or if even the flatpak will no longer work.

EDIT: I rebooted, found the desktop file and clicked on it and frescobaldi worked again and have python3 latest version 3.11.0 installed, so is possible. Need to sort out flatpak though to get that smoothly working on your desktop. Also should really try all above with latest KLV-airedale unlike the mess I made... Clearly, rebuilding the package from source (rather than needing huge flatpak) would be a good idea (and scripting the process... really, that is the main point of scripting - automating what we did manually, which is the really majority of how I created weedogit/firstribit script by the way... It is easier just to hack and manually do something as a one-off, but often worth the effort of putting the details into a script for re-use)

[geo_c]

EDIT: I rebooted, found the desktop file and clicked on it and frescobaldi worked again and have python3 latest version 3.11.0 installed, so is possible. Need to sort out flatpak though to get that smoothly working on your desktop. Also should really try all above with latest KLV-airedale unlike the mess I made... Clearly, rebuilding the package from source (rather than needing huge flatpak) would be a good idea (and scripting the process... really, that is the main point of scripting - automating what we did manually, which is the really majority of how I created weedogit/firstribit script by the way... It is easier just to hack and manually do something as a one-off, but often worth the effort of putting the details into a script for re-use)

Interesting, thanks for checking that out.

As it turns out, I just spent some time converting a couple of my remastered-rootfs installs back to the large collection of upper_changes and uninstalling frescobaldi, and my thinking is since you guys are getting to the RC stage of the game, I want to have my system in shape to drop the new KLVrootfs and kernel in there. Using the remaster tool built into KLV, I don't think that's possible (well maybe the kernel) but not the new builds. I definitely would like to be able to upgrade to a later build and still keep all my work up to this point, though I know it's expecting a lot.

Which got me thinking, it's probably possible, but maybe a lot of effort, to adjust the remaster script to only merge modules over a certain number. In other words don't include the clean system .sfs files, just the higher upper_changes directories. That would be the best of both worlds if not too problematic. I understand that this KLV is more of a psuedo full install than a frugal, and with Void system updates thrown into the mix conflicts are bound to happen with that approach.

At any rate, while I was revamping my file structures, I also ran my lilypond process in Xfce terminal using the micro editor and epdfview. Micro's color code formatting looks fantastic. I definitely don't have to depend on frescobaldi, though it does have a lot of lilypond autocomplete and opens up a lot of commands that I wouldn't necessarily know were there. Flatpak might be a good way to go in KLV, but I've always heard it's a beast. Still there are a lot of applications available in that environment. I have several installs to work with, so I'll give it a whirl. I might like it..

I've got this system crackin! The fact that Xfce save sessions allows me to shutdown with a basic desktop template that I can boot back into. It's just a fun OS all around.

[geo_c]

BTW those errors don't look to critical, mostly it looks like it doesn't have a midi codec to open, or perhaps a sequencer to send a midi file to, since frescobaldi can create a midi file and play it if the right midi applications are available. Frescobaldi and lilypond's main job is to create the sheet music. The midi creation is a bonus.

[geo_c]

And I updated my system and python 3.11 doesn't seem to be causing any other breakage. It all looks good.

[fredx181]

..... Which got me thinking, it's probably possible, but maybe a lot of effort, to adjust the remaster script to only merge modules over a certain number. In other words don't include the clean system .sfs files, just the higher upper_changes directories. That would be the best of both worlds if not too problematic .....

I thought about that too and agree it would be better if the "extra" modules are not merged in the remaster (just the changes merged in the rootfs sfs), I'll have a look at that, but for sure it will be much more complex.

[wiak]

Which got me thinking, it's probably possible, but maybe a lot of effort, to adjust the remaster script to only merge modules over a certain number. In other words don't include the clean system .sfs files, just the higher upper_changes directories.

Actually we have had a utility that does that, well, for NNupper_changes files. It was written by previous member of the forum 'rufwoof' a couple of years back. I know rockedge has been successfully experimenting with it not long ago but not yet been included in published iso releases - no doubt will be included eventually since a general merge layers utility is obviously useful. However... it is certainly the case that it is generally not possible to use merged previous upper_changes with new base builds - that would break xbps database with, as you say, serious package version conflicts - so the idea is limited because of that need to maintain package database integrity.

However, it remains a useful approach if database info is first removed from addons to be merged. For example, say a large app had been installed via xbps, and you did that using a new upper_changes layer - if you could then remove the xbps database in that layer I can envisage the result could be then used, as a portable sfs package, with newer builds, assuming all dependencies remained met, since underlying xbps would not know the portable package was being used (and hence wouldn't object to it...). Overall the flexibility and possibilities are huge and limited only by the imagination - the facilities are certainly there to be experimented with.

There are also nice/useful 'tricks' to do with trying alternative kernels. In the FirstRib openbox/tint2 Arch Linux based system I am working on at the moment, I have the official Arch kernel installed in the main 07 root filesystem, but I can leave that there and instead use something like the huge kernel/modules and even firmware from say vdpup and all works on reboot, without removing the Arch official kernel/modules/firmware. The new kernel only uses the new addon modules, but the vdpup firmware gets merged in with the existing firmware (provided by Arch) - the result is 'more' firmware than vdpup itself was providing (which usually doesn't cause any problem and is sometimes advantageous), but the vdpup firmware, where filenames are the same, takes precedence. In fact my newish computer won't boot successfully with vdpup kernel/modules/firmware alone because some firmware missing, but boots fine with same vdpup components when I have official Arch firmware installed in the main root filesystem (because that includes the otherwise missing from vdpup firmware...).

When using the Arch kernel, some modules need added into the initrd (since Arch not providing a so-called huge kernel with media drivers built in), but the resulting initrd.gz (around 7MB in size) can also be used with the vdpup kernel directly (since the external vdpup 00modules addons takes precedence entirely). In other words, I can supply the system with both approaches - built-in modules/firmware for official Arch Linux kernel, and external modules/firmware for being tried vdpup huge kernel and easy to swap between the two. There is an advantage, in this FR Arch build to using the vdpup kernel instead of the official current Arch kernel - vdpup kernel is 5.10 series and I find using that needs less RAM on startup than the current 6.0.X Arch official kernel (surprisingly, less RAM by around 100MB... quite significant on older lower RAM-provided machines).

[wiak]

..... Which got me thinking, it's probably possible, but maybe a lot of effort, to adjust the remaster script to only merge modules over a certain number. In other words don't include the clean system .sfs files, just the higher upper_changes directories. That would be the best of both worlds if not too problematic .....

I thought about that too and agree it would be better if the "extra" modules are not merged in the remaster (just the changes merged in the rootfs sfs), I'll have a look at that, but for sure it will be much more complex.

Yes, whilst rockedge has successfully tried rufwoof's old 'merge' changes script, I did say to him that I feel it may be missing some necessary refinement - whiteout stuff needs thought about carefully. I haven't examined the matter in detail myself - may be fine, but don't thus know. But 'changes merged in the rootfs sfs' sounds like another variation of the possibilities anyway - certainly a bit more complex than existing remaster util. Just wait till the day we start experimenting with nested layer structures, which I have no doubt will have some uses not even thought about yet (i.e. overlay stacks being used as one component of new overlay stack and so on - almost has possibilites like COW filesystems - reusing an, maybe read-only, overlay stack in a new overlay stack or stacks, but I don't know for what purpose off the top of my head at the moment).

[Phil_54]

Have frugally installed beta 25. I have not seen any difference to the beta19 I use frequently. However after downloading latest firefox using Octoxbps gui, then clearing cache, I have been unable to launch octoxbps either via menu or terminal (run-as-spot octoxbps). The latter gave
octoxbps: symbol lookup error: octoxbps: undefined symbol: _ZN11QTermWidget20setScrollBarPositionENS_17ScrollBarPositionE

I tried reinstalling octoxbps, and also rebooting. No joy.
I expect I'm doing something really silly. Advice welcome.

[geo_c]

Have frugally installed beta 25. I have not seen any difference to the beta19 I use frequently. However after downloading latest firefox using Octoxbps gui, then clearing cache, I have been unable to launch octoxbps either via menu or terminal (run-as-spot octoxbps). The latter gave
octoxbps: symbol lookup error: octoxbps: undefined symbol: _ZN11QTermWidget20setScrollBarPositionENS_17ScrollBarPositionE

I tried reinstalling octoxbps, and also rebooting. No joy.
I expect I'm doing something really silly. Advice welcome.

I have always looked at that 'clear the cache' option and considered doing it, then a little voice always says, "no, better not try that." I might have a lot of wasteful bloat as a result. No advice from me unfortunately.

[rockedge]

I tried reinstalling octoxbps, and also rebooting. No joy.

Simple fix! run in a terminal -> xbps-install -Suy which will upgrade OctoXBPS to match the new lib's.
Then open /usr/share/applications/octoxbps.desktop and add this to the Exec= line

Code: Select all

Exec=sudo -u spot /usr/bin/octoxbps

[geo_c]

I tried reinstalling octoxbps, and also rebooting. No joy.

Simple fix! run in a terminal -> xbps-install -Suy which will upgrade OctoXBPS to match the new lib's.
Then open /usr/share/applications/octoxbps.desktop and add this to the Exec= line

Code: Select all

Exec=sudo -u spot /usr/bin/octoxbps

Should I do this? I'm running beta25 with my collected upper_changes. OctoXBPS seems to be working alright, but I never tried to clear the cache.

[rockedge]

Sure you can clear the cache! It will not damage anything and will be regenerated when it's needed again which then you can clear again.

If OctoXBPS is working then the upgrade step does not need to happen. In case it does upgrade you will know how to fix the menu entry again in the .desktop file.
Also possible in a terminal ->

Code: Select all

xbps-remove -Oo

Code: Select all

-O, --clean-cache
    Cleans cache directory removing obsolete binary packages.
-o, --remove-orphans
    Removes installed package orphans that were installed automatically (as dependencies) and are not currently dependencies of any installed package. See --mode auto in xbps-pkgdb(1).

[fredx181]

It looks like that @Phil_54's problem is that octoxbps doesn't run at all;

I have been unable to launch octoxbps either via menu or terminal (run-as-spot octoxbps). The latter gave
octoxbps: symbol lookup error: octoxbps: undefined symbol: _ZN11QTermWidget20setScrollBarPositionENS_17ScrollBarPositionE

Updating repos with xbps-install -Suy doesn't help then, I'm afraid.

@Phil_54 Are you perhaps using save storage from earlier release (e.g. beta19) ? That may possibly cause the problem.

[rockedge]

I had the same exact error. It began after I ran an full update when lots of things upgraded and OctoXBPS did not. Later after some time went by, I ran another update, this time octoxbps did update and after this it works in a terminal or on the Exec= line in the .desktop file again as expected.

Code: Select all

sudo -u spot octoxbps

defintley possible that an older version is hanging around in the save files/folders layers.

[Phil_54]

Thanks for replies.
I am using a complete fresh install on separate partition to beta19. I did not use any old save folder/file.
Running xbps-install -Suy updated octoxbps.
It now opens from terminal run-as-spot octoxbps.
I updated Exec line in .desktop file and launching from menu works.
I also found in XBPS void linux online handbook that one update doesn't update octoxbps. Another is required, as advised by you.
Thanks again.

[fredx181]

I had the same exact error. It began after I ran an full update when lots of things upgraded and OctoXBPS did not. Later after some time went by, I ran another update, this time octoxbps did update and after this it works in a terminal or on the Exec= line in the .desktop file again as expected.

Code: Select all

sudo -u spot octoxbps

defintley possible that an older version is hanging around in the save files/folders layers.

Aha ok, what I just tested was first upgrading octoxbps only, then running sudo -u spot octoxbps gave the same error as @Phil_54 mentioned. (edit, changed 'root' to 'spot' in code block)
Then I upgraded all with xbps-install -Suy and sudo -u spot octoxbps worked OK to launch octoxbps.

Btw, perhaps better (since you include octoxbps in the rootfs) to put the (modified for to run as spot) .desktop launcher for octoxbps in /usr/local/share/applications , so then it has priority (in case desktop launcher in /usr/share/applications is changed caused by upgrading).
EDIT: Or perhaps better in /root/.local/share/applications , not sure (then it's only for when logged in as root).

[rockedge]

@fredx181 Excellent tip! I will do that and also with gufw the firewall GUI which needs Exec=gufw-pkexec in the .desktop file which also gets changed if gufw upgrades.

I will try it first in /root/.local/share/applications