openSUSE:Reportar uma bug YaST

Bugs

Submeter relatórios de bugs - FAQ dos relatórios de bugs - Definições de bugs - Bugs mais incômodos - Testes - Dia do bug

Página em tradução

Esta página descreve como reportar bugs no YaST2 ou na instalação.

Introdução com esforço dedicado em "onde reportar bugs"

Anexos - y2logs, hwinfo etc.

Eu reportei um bug no YaST2, e agora pede-me para "anexar y2logs" (para instalação de pacotes também referido por "libzypp logging"). O que significa isto, e como é que é suposto eu proceder?

O YaST2 escreve informações de log (registo de diário) nos ficheiros de log em /var/log/YaST2 enquanto está a correr. Nós precisamos dessa informação para reconstruir o que aconteceu.

A Libzypp (o gerenciador de pacotes) escreve a informação das logs sobre a instalação de pacotes em /var/log/zypp, /var/log/zypper.log e /var/log/pk_backend_zypp (logs do 'gpk-update-viewer').

Do SUSE Linux 9.3 ou SLES-9 SP1 para a frente, pressione Shift-F8 no UI Qt (o modo gráfico). Será lhe pedido um nome de ficheiro para onde gravar as logs.

No NCurses UI (modo de texto), saia do UI e utilize o seguinte comando da shell

save_y2logs /tmp/y2logs.tgz

Se você tiver o nova instalação 'modular' do SLE pode necessitar de instalar o yast2 para obter o save_y2logs

zypper in yast2

Do SUSE Linux 11.2 para a frente, Shift-F8 resp. save_y2logs também recolhe o /var/log/zypper.log e o /var/log/pk_backend_zypp. Para versões anteriores (includindo o SLES 11 GM/ SP1/SP2) estes ficheiros tem de ser adicionados manualmente.

Para o SUSE Linux 9.2 (or SLES-9) e mais antigo, cire um arquivo (comprimdo) tar com todos estes ficheiros. Por favor não tente adivinhar quais os ficheiros que nós vamos precisar, isso é impossível e depende de pessoa para pessoa. Simplesmente comprima-os a todos desta forma:

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

Independentemente do lançamento que estiver a usar, se o problema acontecer durante a primeira parte de uma instalação, atualização ou reparação do sistema, não se esqueça de copiar o ficheiro resultante de /tmp (que até ao momento se encontra apenas em RAM) para um lugar seguro - para uma pen USB, para outra partição do disco, ou mesmo pela rede.

Por fim, crie um anexo bugzilla para a respetiva bug com o tal ficheiro /tmp/y2logs.tgz. Por favor garanta que especifiqua o tipo de ficheiro tar.gz archive (app/x-gunzip) no Bugzilla, em vez de deixar o Bugzilla tentar automáticamente detetar o tipo de ficheiro.

O Firefox falha ao anexar o /tmp/y2logs-*.tar.gz que eu gravei com o save_y2logs. Porquê?

Isto é normal, pois o save_y2logs tem de ser executado como root, e utiliza o modo 0600 para indicar informação sensível. Como consequência previne também o seu navegador de internet de ler o ficheiro. No Firefox você não recebe uma mensagem de erro, o botão de submissão simplesmente falha sem dizer nada. Por favor tente 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

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

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.

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.zh:openSUSE:YaST 上报故障