openSUSE:Report a YaST bug

Bugs/fouten

Indienen van bugrapporten - Veelgestelde vragen over rapporteren van bugs - Definities van bugs - Meest vervelende bugs - Testen

Deze pagina beschrijft hoe bugs in YaST2 of de installatie te rapporteren.

Bijlagen - y2logs, hwinfo etc.

Ik heb een YaST2 bug gerapporteerd en nu wordt ik gevraagd om "attach y2logs" (voor pakketinstallatie ook "libzypp logging"). Wat betekent dat en hoe doe ik dat?

Dit artikel is nog maar gedeeltelijk vertaald. Als u mee wilt helpen met vertalen lees dan Wiki vertalen naar het Nederlands.

YaST2 writes logging information to log files below /var/log/YaST2 while it runs. We need that information to reconstruct what happened.

Libzypp (the package library) logs information about package installation to /var/log/zypp, /var/log/zypper.log and /var/log/pk_backend_zypp (logging from 'gpk-update-viewer').

From SUSE Linux 9.3 or SLES-9 SP1 on, press Shift-F8 in the Qt UI (the graphical mode). You will be prompted for a file name to save the logs to.

From NCurses UI (text mode), exit the UI and use the shell command

save_y2logs /tmp/y2logs.tgz

From SUSE Linux 11.2 on, Shift-F8 resp. save_y2logs also collects /var/log/zypper.log and /var/log/pk_backend_zypp. For earlier versions (including SLES 11 GM/ SP1/SP2) these files have to be added manually.

For SUSE Linux 9.2 (or SLES-9) or earlier, create a (compressed) tar archive from all those files. Please do not try to guess which one we might need and which not - this is impossible to tell for most everybody. Simply tar them all up like this:

cd /var/log
tar -czvf /tmp/y2logs.tgz YaST2

Regardless of what release you are using, if that happened during the first part of an installation/update or during a system repair session, don't forget to copy the resulting file from /tmp (which is on a RAM disk then) to a safe place - to a floppy, to a USB stick, to a different hard disk partition or over the network.

Finally, create a new bugzilla attachment to the respective bug with that /tmp/y2logs.tgz file. Please specifically select file type tar.gz archive (app/x-gunzip) in Bugzilla rather than rely on Bugzilla autodetecting the type.

I attached /var/log/YaST2/y2log to a YaST2 bug, and still I am asked to attach y2logs. Why?

Because that one file y2log is only one file of many we need to reconstruct what happened. /var/log/YaST2 contains many more files. y2logs are rotated at a certain size so the one named y2log is only the most recent one - and typically the older ones contain the information we are looking for. In addition to that, there are also other files there that help us debugging the problem.

Please do not try to guess which one we might need and which not - this is impossible to tell for most everybody. Please tar up the whole directory - refer to the previous question for details.

It is important , that you always attach directory contents of /var/log/YaST after the installation fails, the best way to get an appropriate logs is to use YaST logging to USB stick during installation

I want to report a bug related to package dependencies and libzypp solver and now I am asked to "attach a solver testcase". Which logs to attach?

You can create a solver testcase by selecting the menu entry:

 Extras/Generate_Dependency_Resolver_Test_Case 

in the single package selection frame. You will be asked for generating the logfiles which you should add to the bugzilla entry.

To create a solver testcase with zypper simply add the option --debug-solver to your zypper command. In case the option is not supported by your command, or there is no related zypper command, simply run zypper as below:

 $ zypper in --debug-solver nopackage
 Loading repository data...
 Reading installed packages...
 'nopackage' not found.
 Resolving package dependencies...
 Generating solver test case...
 Solver test case generated successfully at /var/log/zypper.solverTestCase.

Then pack the directory that contains the testcase and attach it to the bugreport:

 $ tar czvf /tmp/zypper.solverTestCase.tgz /var/log/zypper.log /var/log/zypper.solverTestCase

The generated solver testcase described above would be ENOUGH in 95 percent of all cases! A second way (and only if the above one does not work.):

In SUSE Linux 10.1 (or earlier) please attach /var/log/YaST2/* to the bugzilla entry as described here. In most case it would be helpful increasing the loglevel and the logfile size before:

For package installation:

export ZYPP_FULLLOG=1
export Y2MAXLOGSIZE=123456789
export Y2MAXLOGNUM=42
yast2 -i

For YOU:

export ZYPP_FULLLOG=1
export Y2MAXLOGSIZE=123456789
export Y2MAXLOGNUM=42
yast2 online_update

For a graphical YaST:

 kdesu -u root -c env ZYPP_FULLLOG=1 Y2MAXLOGSIZE=123456789 Y2MAXLOGNUM=42 /sbin/yast2

I want to report a bug related to Zypper (Zypper, OpenSUSE Updater Applet with ZYpp backend). Which logs to attach?

Please attach /var/log/zypper.log to the bug. See Zypper Troubleshooting for more information.

If ZYpp backend is selected in the KDE Updater Applet, it uses Zypper internally to perform its tasks (like checking for updates, installing the updates). Attach /var/log/zypper.log when you suspect the problem is actually with performing these tasks instead of a problem in the applet GUI or elsewhere.

I want to report a bug related to ZENWorks (ZMD, rug, Software Updater). Which logs to attach?

Please attach /var/log/zmd-*.log to the bug. We usually need both zmd-messages.log* and zmd-backend.log*.

As these files might get pretty large, compress them before uploading. This saves bandwidth on both sides.

If you are running SLES or SLED 10 Service Pack 2 or later, you can generate a solver testcase yourself.

/usr/lib/zmd/zmd-solver-testcase /var/lib/zmd/zmd.db output-dir

You should generate it when rug s waiting for confirmation on the transaction. At this point the transaction information is present in zmd.db.

Pack output-dir and attach it to the bug.

If you generate the testcase while in the middle of a transaction confirmation, for example when rug ask to confirm to install a package, the testcase will include the selected transaction and will help finding the problem.

I want to report a registration bug. Do I have to do something special?

Yes, please attach /root/.suse_register.log and /var/log/messages to the bug.

I reported a YaST2 bug, and now I am asked to "attach hwinfo". What does that mean, and how do I do that?

hwinfo is the command that does hardware probing. We need the output of that command to find out what hardware was detected - if a piece of hardware you reported problems about was detected at all, if it was detected correctly, or simply if there might be a known problem with hardware that is known to be problematic.

Issue this command:

hwinfo >/tmp/hwinfo.txt

and attach the resulting file hwinfo.txt to Bugzilla.

Please do not attach the /usr/sbin/hwinfo binary itself (yes, some people actually did that) - we really need the output, not the binary.

How do I attach YaST2 screen shots?

In a Qt (graphical) installation, simply hit the PrintScreen key. You will be prompted for a file name. This doesn't work with the NCurses (text mode) installation, though.

(yast feature, not kde)

If the bug still show in an xterm, you can open Yast2 in an x-term and make a screenshot with ksnapshot (or any other hardcopy utility).

How can I issue shell commands during an installation?

If you are using a physical (not networked) console, switch to console 2 with Ctrl-Alt-F2. There is a root shell running during installation.

If you are on a networked console with graphics (e.g. VNC), you can get an X terminal window by pressing Ctrl-Alt-Shift-X Invoking terminal from YaST.

The y2logs don't seem to show my problem. Can that logging be made any more verbose?

Yes, it can: You can turn on debug logging (log level y2debug):

• In the installed system, set the Y2DEBUG environment variable and then start YaST2 from the same shell (!):

export Y2DEBUG=1
yast2

• For debug logging during installation, add y2debug to the kernel boot parameters (in the input field at the bottom of the boot menu).
• If you forgot to add y2debug to the kernel boot parameters, you can still use Shift-F7 in the Qt UI (the graphical mode).
• Sending SIGUSR1 to y2base also toggles debug logging:

pkill -USR1 -f y2base

In any case, please note that debug logging can be very verbose, so the logs might become very long - which can be a problem during the first phase of an installation where /var/log is on a RAM disk.

Isn't it enough if I tell you the hostname or the IP of a machine that had a bug and you can fetch everything you need from there yourself?

No, this is the bug reporter's responsibility.

Having ssh access to a machine with problems is a nice add-on, but this does not substitute attaching y2logs at the time to a bug report.

For one thing, a large percentage of bugs reported as YaST2 or installation related turn out to be something completely different - problems of packages (installed via YaST2, but that doesn't make those problems problems of YaST2), kernel problems, hardware incompatibilities, misunderstandings because the user didn't bother to read the documentation. That means we, the YaST2 maintainers, already do a lot of expensive first level support for many others, and we really don't want to do any more menial work (like fetching y2logs and hwinfo etc.) on top of that.

For another thing, by the time we get to actually do this the machine in question might long since have changed - reinstalled, logs full of unrelated things etc.; and we can't simply drop everything and hurry to ssh to some machine to get logs etc. each time a bug comes in - especially since at that time it is by no way clear who will work on that bug, so those distributing bug reports would have to do that in addition to everything else they are doing.

How can I redirect YaST logs to a remote computer during installation?

This is mostly useful for advanced testing/debugging. You can simply redirect your installation logs to a remote NFS server (just another computer) before the installation starts. An article how to configure it is here.

How can I redirect YaST logs to an USB stick during installation?

This is similar to the previous answer. YaST logs can be redirected to any device with write-permissions enabled, such as an USB stick or another hard disk. An article how to configure it is here.

How can I start YaST in debugger (gdb)? How can I create a backtrace?

In some situations you might be asked to run YaST in debugger (e.g. when YaST crashes) to get more detailed information.

To provide the complete debugging information you should install related *-debuginfo packages. This usually means yast2-core-debuginfo, yast2-pkg-bindings-debuginfo and libzypp-debuginfo packages. If the crash happens outside YaST (in an external library) additional debuginfo packages might be needed.

Debuginfo packages are available in extra repositories, for example http://download.opensuse.org/factory/repo/debug/ contains debuginfo packages for the Factory repository. Debugging without debuginfo packages is still possible but some information will be missing (e.g. function names, exact position in the source code...) so the result might be useless.

To start the YaST interpreter in the gdb debugger use command

gdb /usr/lib/YaST2/bin/y2base

Then use

run <module_name> qt

to run the respective YaST module in Qt graphical interface, use gtk for Gtk UI (ncurses UI might be also used but gdb and YaST output will be mixed, see the next paragraph how to solve this). You can Use 'yast -l ' command to see list of the available modules.

The other possibility is to attach gdb to already running YaST process. In this case use command

gdb /usr/lib/YaST2/bin/y2base <PID>

where PID is the process ID of y2base process. Use e.g. 'ps -aux' command to get the ID. Use 'cont' command in the debugger to run YaST again after attaching the debugger. This way it's possible to attach to a YaST module running in ncurses UI (from another terminal).

Now we have YaST runnig in gdb and we can try to reproduce the problem (crash). When the YaST module crashes use bt command in the running debugger to display the program stack (backtrace). Copy&paste the output if you need to attach it into a bug report.

Common Problems

I get a red text pop-up telling me "An error occurred during installation". Is there still any way to salvage log files?

Yes! As long as that error pop-up is open, the root shell on console 2 is still running. It terminates, however, when you confirm that error pop-up. You can use the shell on console 2 to copy log files from that failed installation attempt.

I was asked if the problem also occurs with manual installation. What is that "manual installation"?

In the installation media boot menu, choose "Installation" and enter "manual=1" as boot option. You will be prompted to confirm loading of kernel modules. When the installation hangs after one of those confirmations, this gives some hints about hardware incompatibilities or kernel driver problems.

I aborted the installation and restarted it from "linuxrc", and now I am asked lots of questions about kernel modules to be loaded. What's wrong?

You fell into the "Manual Installation" mode. This is perfectly normal.

The installation starts only in text mode, but I know for sure my machine does have a decent graphics card! What's up?

Graphical installation requires a resolution of 800x600 or better - in frame buffer mode. Not all graphics cards are VESA compliant enough to support this, so the X server used during installation would fall back to only 640x480 which is insufficient to display everything. We received so many complaints about texts or dialog elements being cut off that at some point we dropped support for those ancient graphics modes.

Reading YaST logs

If you want to read the YaST logs (/var/log/YaST2/y2log) yourself, you will probably be lost in all the information and overlook relevant parts.

To see only important messages, you can grep for the log level in the y2log:

grep '<[2345]>' /var/log/YaST2/y2log

will show only log lines with severity "warning" and above.

Existing log levels are:

• 0: debug
• 1: milestone
• 2: warning
• 3: error
• 4: security (rarely used - if at all)
• 5: internal (used sometimes for special debug messages)

A detailed description of the log levels can be found in the YaST2 documentation.