Damn Small Linux Forums

Hi, thank you very much for reviving this project, it is running very well on my old EeePC.

I just had one issue: gksu doesn't seem to be working. No window opens, and this results in apps like control centre not opening and leaving gksu processes running in the background.

Here is the result of gksu --debug apt update:

Code:
No ask_pass set, using default!

xauth: /tmp/libgksu-TE6qLq/.Xauthority

STARTUP_ID: gksu/apt 'update' /2070-0-EeePC_TIME1120526

cmd[0]: /usr/bin/sudo

cmd[1]: -H

cmd[2]: -s

cmd[3]: -p

cmd[4]: GNOME_SUDO_PASS

cmd[5]: -u

cmd[6]: root

cmd[7]: --

cmd[8]: apt

cmd[9]: update

buffer: --

buffer: --

buffer: --

buffer: --

[...]

buffer: --

buffer: --

buffer: --

buffer: --

brute force GNOME_SUDO_PASS ended...

No password prompt found; we'll assume we don't need a password.

Everything is default, and I do have a password set. Running latest rc5. Any help is much appreciated Smile

This bug seems to be cleared up by putting "export DISPLAY=:0" into /etc/environment. Please report if it works for you.

Unfortunately that didn't work. I also tried DISPLAY=:0 gksu zzzfm and no luck. I realized that once I run anything with sudo in the terminal, gksu works for the rest of the session, but also doesn't ask for a password.

Please tell me how you are running DSL. Did you install it on the hard drive or from a USB? Any kind of modifications made? Are you running it in the default desktop mde (zzzfm=fluxbox)?

Edit: I see the bug, post install.

(06-12-2024, 01:44 AM)PistachioGuy Wrote: [ -> ]Unfortunately that didn't work. I also tried DISPLAY=:0 gksu zzzfm and no luck. I realized that once I run anything with sudo in the terminal, gksu works for the rest of the session, but also doesn't ask for a password.

gksu is just a GTK+ library that wraps sudo, su providing a graphical interface for you to authenticate yourself and grant superuser permissions without needing to go to the command line.

When you run something with sudo in the terminal you are also granting that permission. Once it gas been granted it is maintained for a certain period of time. If you start a new process that requests those permissions before they are automatically revoked it will be automatically granted iirc.

-----

No idea why you weren't getting the gksu generated dialog boxes, but if they weren't being assigned to the display used for the current X windows session/desktop environment then you wouldnn't be able to see or interact with them.

I reinstalled with all defaults to confirm and it's not not opening. I noticed it on the default zzz-fluxbox but it happens on jwm too. Can confirm that this is not an issue on the live session for some reason.

(06-13-2024, 01:04 AM)PistachioGuy Wrote: [ -> ]I reinstalled with all defaults to confirm and it's not not opening. I noticed it on the default zzz-fluxbox but it happens on jwm too. Can confirm that this is not an issue on the live session for some reason.

I don't what the correct solution is, maybe @John does given his previous post.

The first message in the output does seem relevant though:

Code:
No ask_pass set, using default!

This page and answer are specific to Ubuntu
https://askubuntu.com/questions/1124875/...s-variable

But it seems that when 'sudo' is invoked, you can specify another program/script? to handle the request to the user instead of just sending it directly via the terminal (CLI).

The rest of the messages you got appears to be conveying how sudo was invoked AND what the result was. And the failure seems predictable given GNOME is not present/installed.

P.S.

https://linux.die.net/man/1/gksudo
^ man page for 'gksudo', of which 'gksu' is an alias, symbolic link, or something

https://linux.die.net/man/1/su
^ man page for 'su'

"
-A

Normally, if sudo requires a password, it will read it from the user's terminal.

If the -A (askpass) option is specified, a (possibly graphical) helper program is executed to read the user's password and output the password to the standard output.

If the SUDO_ASKPASS environment variable is set, it specifies the path to the helper program.

Otherwise, if /etc/sudo.conf contains a line specifying the askpassprogram, that value will be used.

For example:

# Path to askpass helper program
Path askpass /usr/X11R6/bin/ssh-askpass

If no askpass program is available, sudo will exit with an error."

https://linux.die.net/man/8/sudo
^ man page for 'sudo'

TLDR:

It looks like 'gksu' is being forced to use 'sudo', based on the debug output. And for some it's expecting to find an environment variable called GNOME_SUDO_PASS.

The reason you aren't seeing any windows might be that this whole bit is erroring out.

I've spent a bit if time trying to track this bug down. I'm going to be replacing gksu with a YAD script that does the same thing and is lot less temperamental in the next RC cut.

Alright, thank you for your hard work!

PistachioGuy

John

PistachioGuy

John

Nathan

PistachioGuy

Nathan

John

PistachioGuy