General > On Topic

Lite Tweaks issue

(1/3) > >>

I'm not sure Lite Tweaks kernel remover has the sequencing to remove all the generic kernels from the system, i/e you must keep one. If you only want one low latency kernel and no others you might have to remove the last generic one manually.
I think /temp/ltlogs.log has to do with web session saving.

Anyway something is up with the at-spi bus, which is normally enabled in session and startup and should not be a problem. I do not get that error on 6.6, only on 7.0 and it is enabled in 7.0. This may be an XFCE bug in session manger.

updates: I resovled the at-spi warning. Just updated lightdm greeter. LT no longer issues warning.
I believe the root trash folder warning is meaningless too i/e file is only actually there during ISO live sesssion

Starting from the terminal provides no useful information.

Maybe the issue could be zenity version dependencies that cause syntax issues with the bash commands. I'm not sure that zenity can be safely regressed to earlier versions. I don't like that begin kills the app i/e seems to imply that the commands must need a syntax change somewhere. I'm also not sure how much of the LT application depends on zenity i/e just the notification windows or the whole app.


Şerban S.:

I tried the suggestion of LL-User:

--- Quote from: LL-user on May 07, 2024, 11:22:19 AM ---Hi TC,
Did you start it from a terminal and see if the output can give you any hint?

--- End quote ---
I checked and the directory is writeable by the user. I could save a dummy text and reopen it.

Here is the output:

--- Code: ---sudo lite-tweaks
[sudo] password for serban:
ls: cannot access '/root/.local/share/Trash/files/': No such file or directory
cat: '/root/.config/xfce4/panel/whiskermenu-*.rc': No such file or directory
tee: /tmp/ltlogs.log: Permission denied
tee: /tmp/ltlogs.log: Permission denied
/usr/bin/lite-tweaks-super: line 1089: ((: PERCENTAGE = 100 \* 2 / 1 : syntax error: invalid arithmetic operator (error token is "\* 2 / 1 ")
ls: cannot access '/root/.local/share/Trash/files/': No such file or directory
cat: '/root/.config/xfce4/panel/whiskermenu-*.rc': No such file or directory

--- End code ---

I find it weird, since it was running as Root (see code above). (I never did this before).
Further more, my intuition regarding the removal routine, seems to be correct.
I'll do my best to check the LL 7.0, same procedure, CLI.
The only idea that comes in mind, is a string variable wrong formatted and passed to the next code snippet.
The routine that interprets the content of the variable, for some reason breaks the routine without a code error or something >> 10,000.
That makes the program flow go sideways.
I'll see what comes out.
Another idea crossed my mind:

--- Code: ---pluma /tmp/ltlogs.log
Gtk-Message: 21:22:59.086: Failed to load module "xapp-gtk3-module"

--- End code ---

I get a lot of these <Gtk-Message: 21:22:59.086: Failed to load module "xapp-gtk3-module">.
When I need DoubleCmd as Root, for one.
Anyway, the file /tmp/ltlogs.log is really missing.
If it is created runtime and as Root, it seems that the privileges are lost somewhere for some reason (Time out?).
Since Kernel Remover runs as Root, it is possible, but how?
As long as REMKERNELS runs as Root, it should be able to write/read anything anywhere.
What really means that: "/tmp/ltlogs.log: Permission denied"
For who? For Root?!
is the sudo time-out set too low?
Sometimes, kernel removal takes a long time, even on Dell T1700.

Best regards, Șerban.

On LL 7.0 the error message when starting Lite Tweaks in the terminal is:

(zenity:11739): dbind-WARNING **: 11:31:37.757: Couldn't connect to accessibility bus: Failed to connect to socket /root/.cache/at-spi/bus_0.0: Permission denied

However on LL 6.6 I get no warnings starting Lite Tweaks from the terminal.


Şerban S.:
Lite Tweaks issue

Tested Today (06-05-2024)
[L06-05-2024 ora 13:20]
I ran today the updater:
The following packages will be upgraded:
Procedure went smooth. Nothing seems wrong, so far (13:20, GMT+3)
The only issue with Lite Tweaks, is the same old one, relate to the Kernel Removal section.
The removal program, looks like exiting with some unknown error and breaks the program at the point of removing the initial kernel (5.15.0-86 I guess). I belive that is somehow GRUB related. Maybe there is some kind of built-in safeguard that somehow leads to this result.
You can reproduce this, running multiple times the same removal procedure, with or without restarting (cold boot).

Lite Tweaks Config
I ran the App with the following configuration: Autoremove Packages; Kernel Remover; Log Archives; Package Cache; SystemD Log Cleaner;
Except for the Kernel Remover, the rest of the options are pretty much the same everytime I do some cleaning for whatever reason.
At first run, the kernel list is: “linux-image-unsigned-5.15.0-82-generic”.
My current kernel is “linux-image-5.15.0-89-lowlatency” and the specification is “5.15.0-89.99 Signed kernel image lowlatency”.
At SECOND run, (after rebooting!) the kernel list is: “linux-image-5.15.0-82-generic”. Says “Successfully…”.

At THIRD run, (after the second reboot!) the kernel list is: “linux-image-unsigned-5.15.0-82-generic”. Says, again (!!!) “Successfully…”.
This goes on and on, indefinitely. I tested once a number of eight reboots then gave it up.
I even removed the said kernels manually until searching returned an empty string, yet, this weird thing gets back.
[L06-05-2024 ora 14:20]
After one hour from the update, still nothing suspect.
I’ll probably publish this and eventually, update it after some hours (days) of uptime and some “heavy weigths lifting”: Audio work (JACK, QTractor & the like). At this moment, all looks good.

After 5 hours...[/color]
[L06-05-2024 ora 18:40]
As I said above, I did some demanding tasks: I’ve been working on a track for an album.
After closing the Audio Session, I ran again Lite Tweaks: Kernel Remover; Package Cache; SystemD Log Cleaner.
Kernel Remover: the kernel list is: “linux-image-5.15.0-82-generic”.
So, as I said above, in fact, it did nothing although it reported “Successfully…”.
As for the rest of tasks, still OK.
Given the fact that the system was changed from the default installation (another kernel, JACK + some other pro-audio Apps), I guess that if it were to crush for a reason residing inside the system installation, this should be somehow “visible”.

Best regards, Șerban.

Thanks for that. Perhaps we'll catch something in the RC release - hope not :)


[0] Message Index

[#] Next page

Go to full version