Bugs/YaST

This page describes how to report bugs in YaST2 or the installation.

Attachments - y2logs, hwinfo etc.

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

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

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

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 or update, 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.

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.

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

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?

Switch to console 2 with Ctrl-Alt-F2. There is a root shell running during installation.

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).

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.

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.

== I download 5 cds and burned.I boot computer of cd1 and he don´t start from cd.In bios i defined c: on first time in mode boot.what I am doing wrong?