openSUSE:Report a YaST bug
Attachments - y2logs, hwinfo etc.
I reported a YaST2 bug, and now I am asked to "attach y2logs" (for package installation also "libzypp logging"). 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.
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
If you have the new 'modular' installation of recent SLE you might need to install yast2 to get save_y2logs
zypper in yast2
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.
Firefox fails to attach the /tmp/y2logs-*.tar.gz that I saved with save_y2logs. Why?
This is normal, as save_y2logs has to be run as root, and uses mode 0600 to indicate sensitive information. Thus it also prevents your browser from reading the file. In firefox you do not get an error message, the submit button just fails silently. Please try sudo chmod a+r /tmp/y2logs-*.tar.gz
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
You can create a solver testcase by selecting the menu entry:
Extras/Generate_Dependency_Resolver_Test_Casein 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 cjvf /tmp/zypper.solverTestCase.tar.bz2 /var/log/zypper.log /var/log/zypper.solverTestCase
In case the testcase exceeds the 10MB limit for bugzilla uploads, you can use split to divide the file into smaller pieces:
$ cd /tmp $ ls -lh zypper.solverTestCase.tar.bz2 -rw-r--r-- 1 root root 22M Jul 8 09:44 zypper.solverTestCase.tar.bz2
$ split -b 9M --additional-suffix=-zypper.solverTestCase.tar.bz2 zypper.solverTestCase.tar.bz2 $ ls -lh x* -rw-r--r-- 1 root root 9.0M Jul 8 09:56 xaa-zypper.solverTestCase.tar.bz2 -rw-r--r-- 1 root root 9.0M Jul 8 09:56 xab-zypper.solverTestCase.tar.bz2 -rw-r--r-- 1 root root 3.5M Jul 8 09:56 xac-zypper.solverTestCase.tar.bz2
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
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.
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.
How can I setup network connection manually?
You are often asked for attaching Yast logs, but how to copy them from inst-sys without network connection? Since openSUSE 13.2 and SLE 12 you can use this method: Switch into a console with Ctrl+Alt+F2 (in text-mode installation) or open new xterm with Ctrl+Alt+Shift+X (in graphical installation). Find your network device name, e.g., eth0, with
ip a
and create new configuration file, using, e.g., vi /etc/sysconfig/network/ifcfg-eth0 with this content:
BOOTPROTO=dhcp STARTMODE=auto
Save it with [Esc]:wq and activate your configuration with
wicked ifup all
For more options, such as static configuration, use man ifcfg in your installed system.
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.