Bugs/YaST

Úr Wikipedia, frjálsu alfræðiorðabókinni

Þessi síða skýrir hvernig á að gefa galla skýrslu um YaST2 eða innsettninguna.

Viðhengi - y2logs, hwinfo osfv.

Ég gaf skýrslu um YaST2 gallan, og nú er ég beðinn um að "bæta við y2logs". Hvað þýðir það, og hvernig fer ég að því?

YaST2 skráir upplýsingar undir /var/log/YaST2 undir keyrslu. Við þörfnust þessara upplýsinga til að endurskapa það sem hefur gerst.

Í SUSE Linux 9.3 eða SLES-9 SP1, ýtið á Skift-F8 í Qt viðmótinu (grafísku viðmóti). Þú þarft að gefa upp skrárnafn til að forða upplýsingunum í.

Í NCurses viðmótinu (teksta viðmóti), yfirgefið viðmótið og framkvæmið þessa skipun

save_y2logs /tmp/y2logs.tgz

Í SUSE Linux 9.2 (eða SLES-9) eða fyrri, skapið (þjappað) tar safn af öllum þessu skrám. Reynið ekki að geta ykkur til hvaða skrár við þörfnumst eða hverra ekki - þetta er ómögulegt fyrir nánast hvern sem er. Einfaldlega setjið þau öll í safnið á þennann hátt:

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

Óháð því hvaða útgáfu þú notar, ef það gerðist undir fyrsta hluta insettningar eða uppfærslu, gleimið ekki að afrita skrána sem er niðurstaðan frá /tmp (Sem er á RAM disk) yfir á öruggan stað - á diskettu, USB minni, á annan harðan disk eða yfir netið.

Að lokum, skapið nýtt bugzilla viðskeyti fyrir viðkomandi galla með /tmp/y2logs.tgz skránni. Vinsamlega veljið skráargerð tar.gz archive (app/x-guzip) í Bugzilla frekar en að reiða á að Bugzilla finni út úr því sjálft.

Ég skeytti /var/log/YaST2/y2log við YaST2 galla skýrsluna, og er samt beðin um að skeyta við y2logs. Af hverju?

Vegna þess að þessi eina skrá y2log er einungis ein skrá af mörgum sem við þurfum til að endurskapa hvað gerst hefur. /var/log/YaST2 inniheldur mun fleiri skrár. y2log er snúið við ákveðna stærð svo að sjálf y2log er einungis sú nýjasta í röðinni - og vanalega innihalda eldri srkárnar upplýsingar sem við leitum að. Að auki eru aðrar skrár þar sem aðstoða okkur við að leysa vandan.

Reynið ekki að geta ykkur til um hvaða skrár við þörfnumst og hverra ekki - þetta er ómögulegt fyrir nánast alla. Vinsamlega þjappið öllu efnisyfirlitinu í tar safn - snúið ykkur að fyrri spurningu til að fá ítarlegri upplýsingar.

Ég vil gefa skýrslu um galla tengdum ZENWorks (ZMD, rug, Software Update). Hvaða skráningu þarf að skeyta við?

Vinsamlega skeytið /var/log/zmd-*.log við gallaskýrsluna.

Þar sem þessar skrár gætu orðið stórar, þjappið þeim áður en þeim er hlaðað upp. Þetta sparar bandbreidd á báðum hliðum.

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.