"Authorization required, but no authorization protocol specified" error printed multiple times if running from chroot

[xfzv]

General description of bug:

If running fastfetch from chroot, I'm getting the following error printed multiple times: Authorization required, but no authorization protocol specified.

• What happened:

• What should happen: The error isn't printed.
• Did it work in an older version: 1.12.2 is the first one I'm using.
• Where did you get the binary: Gentoo official overlay - app-misc/fastfetch
• Does this issue still occurs in the latest dev build? yes

Often helpful information:

Output of fastfetch --version:

fastfetch 1.12.2 (x86_64)

The content of the configuration file you use (if any)

--structure Title:Separator:OS:Kernel:Uptime:Packages:Shell:Display:DE:WM:Terminal:CPU:GPU:Memory:Battery:PowerAdapter:Break:Colors
--color blue
--logo-color-1 blue
--logo-color-2 blue
--separator-string "━"
--percent-type 3

Output of fastfetch --list-features:

threads
vulkan
xcb-randr
xcb
x11
dbus
egl
glx
libpulse

[CarterLi]

I don't know how to reproduce this issue. Quick google reads

those programs require X windows features but there's no configuration available in the root account for that to happen.

https://www.reddit.com/r/linux4noobs/comments/lu1plx/hi_i_get_this_authorization_required_but_no/

So you were running x11, and the environment you chrooted had no necessory configuration for xsessions.

I don't think I want to support this situation. What's the point of running fastfetch from chroot?

[xfzv]

I don't think I want to support this situation.

It's up to you of course. I'm not getting the error in chroot with other fetch tools including:

• Albafetch
• Mitch
• Neofetch
• Nitch
• pfetch
• pfetch-rs
• pixfetch
• unifetch

so I assumed there was something wrong with fastfetch and created this issue.

[CarterLi]

How many *fetch programs did you install :laughing:

I assume that they didn't get the same error because they didn't try to connect x11 server. Do they support refresh rate detection?

I can add a flag to force display detection to use /sys/class/drm/

[CarterLi]

$ ./fastfetch --ds-force-drm -s display --pipe --thread false
Display (eDP-1): 2560x1440

$ ./fastfetch -s display --pipe --thread false
Display (eDP-1): 2560x1440 @ 240Hz (as 1280x720)

[xfzv]

Not sure if I'm missing something but with latest dev build:

./fastfetch --ds-force-drm -s display --pipe --thread false

gives me no output at all, both on my host machine and in the chroot.

[CarterLi]

Try

NO_DEBUG=1 ./fastfetch --ds-force-drm -s display --pipe --thread false --show-errors

[xfzv]

NO_DEBUG=1 ./fastfetch --ds-force-drm -s display --pipe --thread false --show-errors
Display: Couldn't detect display

(Both on host system and in chroot)

[CarterLi]

What does ls -l /sys/class/drm print?

[xfzv]

❯  \ls -l /sys/class/drm
total 0
lrwxrwxrwx 1 root root    0 Aug  1 09:43 card0 -> ../../devices/pci0000:00/0000:00:03.0/0000:03:00.0/drm/card0
lrwxrwxrwx 1 root root    0 Aug  1 09:43 renderD128 -> ../../devices/pci0000:00/0000:00:03.0/0000:03:00.0/drm/renderD128
-r--r--r-- 1 root root 4096 Aug  1 09:43 version

[CarterLi]

It seems that the DRM kernel module does not work properly.

But at least it doesn't generate error messages...

[CarterLi]

Okey. The error messages should be removed in the latest dev branch ( without --ds-force-drm ). Please have a try

Please make sure you are building fastfetch in Release mode

[xfzv]

Please make sure you are building fastfetch in Release mode

Not sure what "release mode" is, I compiled fastfetch following the README instructions:

mkdir -p build
cd build
cmake ..
cmake --build . --target fastfetch --target flashfetch

I guess it's fine? I can see https://github.com/fastfetch-cli/fastfetch/commit/aa498776108eb0df31535f6be3261e63f8c7b7e5 from the dev branch in git log.

Without any config file

• From main system:

NO_DEBUG=1 ./fastfetch -s display --pipe --thread false --show-errors
Display (DP-0): 2560x1440 @ 165Hz

• From chroot:

NO_DEBUG=1 ./fastfetch -s display --pipe --thread false --show-errors
Display: Couldn't detect display

Also from chroot and with my config file:

# ~/.config/fastfetch/config.conf
--structure Title:Separator:OS:Kernel:Uptime:Packages:Shell:Display:DE:WM:Terminal:CPU:GPU:Memory:Battery:PowerAdapter:Break:Colors
--separator-string "━"
--percent-type 3

Only the following elements are printed:

• Shell
• Terminal
• CPU
• GPU
• Memory
• Colors

The following elements aren't printed:

• Logo
• Title
• Separator
• OS
• Kernel
• Uptime
• Packages
• Display
• DE/WM (normal I guess, isn't printed with 1.12.2 either)

On host (with the same config), Packages is missing too.

With 1.12.2 binary, these elements are printed correctly (albeit the error initially reported of course)

[CarterLi]

Please make sure you are building fastfetch in Release mode

Not sure what "release mode" is, I compiled fastfetch following the README instructions:

mkdir -p build
cd build
cmake ..
cmake --build . --target fastfetch --target flashfetch

I guess it's fine? I can see aa49877 from the dev branch in git log.

Without any config file

• From main system:

NO_DEBUG=1 ./fastfetch -s display --pipe --thread false --show-errors
Display (DP-0): 2560x1440 @ 165Hz

• From chroot:

NO_DEBUG=1 ./fastfetch -s display --pipe --thread false --show-errors
Display: Couldn't detect display

Also from chroot and with my config file:

# ~/.config/fastfetch/config.conf
--structure Title:Separator:OS:Kernel:Uptime:Packages:Shell:Display:DE:WM:Terminal:CPU:GPU:Memory:Battery:PowerAdapter:Break:Colors
--separator-string "━"
--percent-type 3

Only the following elements are printed:

• Shell
• Terminal
• CPU
• GPU
• Memory
• Colors

The following elements aren't printed:

• Logo
• Title
• Separator
• OS
• Kernel
• Uptime
• Packages
• Display
• DE/WM (normal I guess, isn't printed with 1.12.2 either)

On host (with the same config), Packages is missing too.

With 1.12.2 binary, these elements are printed correctly (albeit the error initially reported of course)

Oh, I think that's because DisplayServer is run in a separated thread, and swallowed the output from normal module.

Please try fastfetch --thread false

[CarterLi]

I have to revert the fixes. And since the error message is printed directly in X11 libs, I don't think I have any better ideas to fix it.

[xfzv]

Please try fastfetch --thread false

Indeed, it's working as expected with ./fastfetch --thread false

All values from my config file are printed on main system and from chroot too, except Display on chroot which isn't displayed (which is fine I guess)

[CarterLi]

You could just use --ds-force-drm in chroot, and this flag will skip the X11 connection.

I'm closing this

CC @LinusDierheimer

[xfzv]

You could just use --ds-force-drm in chroot, and this flag will skip the X11 connection.

OK. I think I'll use the following shell function to automatically use --ds-force-drm only if chroot is detected since it's not doable from the config file:

ff() {
    if [[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]]; then
    fastfetch --ds-force-drm
    else
    fastfetch
    fi
}

(Source)

It works reliably after recompiling with latest commits. Feel free to let me know if you have a better idea.

Thank you for your time. :+1:

[alba4k]

• Albafetch

This is like 300% unrelated but @xfzv how did you even find out about albafetch's existence 😂

It was never meant to be used, but I'm glad it's usable ahah

[xfzv]

@alba4k I think I was searching for Neofetch alternatives on the AUR :disguised_face:

albafetch is nice too, keep it up!

[CarterLi]

@alba4k I just found this. Great project! I compared the performance of albafetch with fastfetch in Fedora Linux, and found that albafetch costs about 400 ms while fastfetch costs about 34ms

$ hyperfine -w3 ./albafetch ~/fastfetch/build/fastfetch
Benchmark 1: ./albafetch
  Time (mean ± σ):     405.4 ms ±   2.9 ms    [User: 373.9 ms, System: 32.2 ms]
  Range (min … max):   399.6 ms … 409.8 ms    10 runs

Benchmark 2: /home/carter/fastfetch/build/fastfetch
  Time (mean ± σ):      34.3 ms ±   1.7 ms    [User: 21.1 ms, System: 12.6 ms]
  Range (min … max):    31.2 ms …  39.2 ms    85 runs

Summary
  /home/carter/fastfetch/build/fastfetch ran
   11.82 ± 0.60 times faster than ./albafetch

debug shows that the bottleneck comes from packages. albafetch uses raw rpm command which is very slow. I suggest that you should query the sqlite database used by rpm directly. The following patch does the trick:

diff --git a/src/info.c b/src/info.c
index 8d11ec9..28def2e 100644
--- a/src/info.c
+++ b/src/info.c
@@ -424,7 +424,7 @@ int packages(char *dest) {
         path[0] = 0;
         if(getenv("PREFIX"))
             strncpy(path, getenv("PREFIX"), 255);
-        strncat(path, "/bin/rpm", 256-strlen(path));
+        strncat(path, "/var/lib/rpm/rpmdb.sqlite", 256-strlen(path));
         if(pkg_rpm && !access(path, F_OK)) {
             if(pipe(pipes))
                 return 1;
@@ -433,7 +433,7 @@ int packages(char *dest) {
                 close(pipes[0]);
                 dup2(pipes[1], STDOUT_FILENO);

-                execlp("sh", "sh", "-c", "rpm -qa 2>/dev/null | wc -l", NULL); 
+                execlp("sh", "sh", "-c", "sqlite3 /var/lib/rpm/rpmdb.sqlite 'SELECT count(*) FROM Packages' 2>/dev/null", NULL);
             }
             wait(0);
             close(pipes[1]);

albafetch costs about 27ms with the patch applied, which is even faster than fastfetch, really impressive!

[CarterLi]

I also compared the performance of albafetch with fastfetch in macOS, and found that albafetch costs about 285 ms while fastfetch costs about 60ms

$ hyperfine -w3 ./albafetch '~/fastfetch/build/fastfetch -c none'
Benchmark 1: ./albafetch
  Time (mean ± σ):     285.7 ms ±  23.1 ms    [User: 54.0 ms, System: 84.4 ms]
  Range (min … max):   261.3 ms … 345.7 ms    10 runs

Benchmark 2: ~/fastfetch/build/fastfetch -c none
  Time (mean ± σ):      59.3 ms ±   2.6 ms    [User: 11.1 ms, System: 10.2 ms]
  Range (min … max):    54.7 ms …  64.0 ms    45 runs

Summary
  ~/fastfetch/build/fastfetch -c none ran
    4.81 ± 0.44 times faster than ./albafetch

debug shows that the bottleneck comes from gpu. albafetch uses system_profiler for Apple Silicon which is very slow. However resolving this issue requires a lot more code changes. You may refer to how fastfetch did it if you want to fix it.

[alba4k]

Oh, thanks so much @CarterLi !

As for it being faster, well, it just has less features so it's pretty much expected

On macOS, system-profiler was never meant to be a long-term solution, it instead mainly started as a way to have it working on apple silicon too, so I should look into it, eventually