Reporting bugs

What to consider when reporting bugs

Reporting bugs is one of the things which helps developers improve their software. To get through this as quickly as possible here are some things to consider when experiencing bugs:

What kind of bug do you want to report?
Do you have some kind of log or screenshot of the occurrence? Things like “screen goes dark” are hardly resolvable without giving proper information about the circumstances (such as specs, error message, etc.)
Is the problem related to Garuda or is the problem caused by a bug in the software used? If there are issues with a specific version of software that is used in Garuda the only solution will most likely be to report the bug at the software’s bug tracker (e.g. Gitlab). If the issue is related to the Garuda specific settings they can be reported to our Forum with proper background information (see below)
Make sure to do at least a quick search concerning the issue prior to posting a bug report or opening a new thread. Sometimes there is already information available on how to solve the issue, saving you (and us) time.

So how to actually write a good bug report?

Please, do not post pictures of terminal output, or a whole screenshot in which only a short sentence with the error message can be seen.
Have system logs ready. Longer terminal outputs can be pasted to our PrivateBin and linked to the thread to avoid making the post too long and messy. Screenshots are not as useful as actual text outputs and should be avoided unless it’s a graphical bug or something similar.
Include the output of garuda-inxi in your post. This gives the people trying to resolve the issue proper information on the hardware used.
Provide the name of the ISO (full name!) used to install Garuda on your system
If you include terminal outputs in your post please use the proper output format in your post. Using ` 3 times above and ` 3 times below the text block will provide a readable, raw look.
Be specific - Try to summarize the problem in minimum words yet effectively.
Do not combine multiple problems even if they seem to be similar. Write different reports for each problem.

How to identify and report software bugs

For assistance with any program that is crashing or exhibiting buggy behavior you need to post all errors the program is generating. Accurate textual output containing the exact content of any error message(s) is required to properly diagnose issues. Providing a summation of an error message in your own words (or a picture) is not the correct procedure for reporting bugs.

The exact complete error message content must be provided, so that it may be searched online. Better yet, skip the middleman, and research your own errors online prior to opening a help request on the forum. This is referred to as performing your due diligence. Meaning you are expected to make a reasonable effort to search for a solution before opening any help request on the forum.

We attempt to help users with issues with third party software, however this is not Garuda’s responsibility. Any software experiencing bugs that can not be resolved should be reported to its upstream project.

Launch the program from a terminal

A program that will not start, or is experiencing bugs should be launched in the terminal to display a textual output of any errors produced by the program. You can find the correct command to start the program in the terminal by right clicking on the program’s icon in the application start menu. If for example you were trying to start the program “Octopi” for installing and uninstalling software you would do as follows.

Right click on the icon named “Octopi” in the applications menu (KDE).
Depending upon your DE there should be a menu popup with a choice similar to “Edit application” or “Properties”. Left click on this option and then select the “Application” tab (or similar).
In the “Application” tab there will be a section with a listing for the “Command:” to start the program. You should find Command: octopi listed there.
Copy and paste octopi into the terminal (without quotes) and press enter.
Copy and paste any resultant errors from starting the program via the terminal into a properly formatted code block in your “Opening Post” (OP) on the forum.

Add missing information to your post

Help requests that have zero possibility of ever being solved because of a total lack of information are simply considered cruft and clutter on the forum. Any help request with woefully inadequate information may be moved from the main forum until sufficient information is provided. Your help request’s OP can be edited to provide the required information in the following manner.

Click on the three dots (…) at the bottom margin of your opening post.
A new section will expand that contains a pencil icon.
Clicking on the pencil icon will allow you to edit your post to add the information your post is lacking.

Generally most technical help requests require at least your system specifications and any relevant errors and background information related to your issue. Be sure to properly format all errors and other code in easily human readable code blocks as already explained above. Once your OP has been edited to include the required information it will be returned to the main forum (if it has been moved).

Yes. garuda-inxi filters the output for privacy before it prints it, so you can paste it in a forum post.

garuda-inxi runs inxi -Faz --zv. The -z option removes IP addresses, serial numbers, MAC addresses, location data, the host name and your home directory name from the output.
The --zv option removes the CPU vulnerability report that inxi -Ca prints. That report is no longer part of the output.
The output still shows hardware models, drivers, kernel and desktop information. This is the data needed to solve most issues.
Check the output before you post it. Long output belongs in our PrivateBin, linked from your post.

Source: Does inxi really contains something that can invade your privacy on the Garuda forum, answer by BluishHumility.