|
Bugzilla – Full Text Bug Listing |
| Summary: | Navigating to Kernel Parameters hangs YaST2 Boot Loader. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Forgotten User tjKRikeLeu <forgotten_tjKRikeLeu> |
| Component: | Bootloader | Assignee: | Josef Reidinger <jreidinger> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | forgotten_tjKRikeLeu, snwint, sonichedgehog_hyperblast00 |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | The Yast 2 log file. | ||
|
Description
Forgotten User tjKRikeLeu
2017-02-17 11:03:14 UTC
please upload yast logs, so I can see where it stuck. Thanks https://en.opensuse.org/openSUSE:Report_a_YaST_bug setting needinfo see comment #1 *** Bug 1029526 has been marked as a duplicate of this bug. *** Definitely safe to say I can confirm this issue. Sadly I don't have any logs either. My own observations from the duplicate report: YaST permanently freezes and eats 100% of one CPU core, when entering System - Boot Loader and clicking on the Kernel Parameters tab. This happens with both the YaST GUI as well as when running YaST in a console. It appears to get stuck when reading the following fields: Use graphical console, Console resolution, Console theme. Other fields (Optional Kernel Command Line Parameter) load before the freeze, whereas those remain empty... implying the crash occurs while accessing or displaying their data. The issue seems to take place randomly: Some package updates cause it to happen, then other updates appear to fix it. I first noticed this a few months ago, but it was since fixed... then last night it started happening again, however today it seems to be working once more. (In reply to Mircea Kitsune from comment #4) > Definitely safe to say I can confirm this issue. Sadly I don't have any logs > either. My own observations from the duplicate report: > > YaST permanently freezes and eats 100% of one CPU core, when entering System > - Boot Loader and clicking on the Kernel Parameters tab. This happens with > both the YaST GUI as well as when running YaST in a console. > > It appears to get stuck when reading the following fields: Use graphical > console, Console resolution, Console theme. Other fields (Optional Kernel > Command Line Parameter) load before the freeze, whereas those remain > empty... implying the crash occurs while accessing or displaying their data. > > The issue seems to take place randomly: Some package updates cause it to > happen, then other updates appear to fix it. I first noticed this a few > months ago, but it was since fixed... then last night it started happening > again, however today it seems to be working once more. thanks for info. In past it is caused on some hardware when trying to read available graphical modes. can you please try if hwinfo --framebuffer also hangs? as it is cli to get available modes. and in past it hangs there. And today, it started happening once again. I tried running yast2 from the console, however there is no output during the hang. Below is what I got... the later half is me pressing Control + C to kill the process after it freezes. linux-qz0r:/home/mircea # yast2 Run command: /sbin/yast2 bootloader & ^CYaST got signal 2 at file /usr/share/YaST2/modules/Initrd.rb:423 sender PID: 0 (In reply to Mircea Kitsune from comment #6) > And today, it started happening once again. I tried running yast2 from the > console, however there is no output during the hang. Below is what I got... > the later half is me pressing Control + C to kill the process after it > freezes. > > linux-qz0r:/home/mircea # yast2 > Run command: /sbin/yast2 bootloader & > ^CYaST got signal 2 at file /usr/share/YaST2/modules/Initrd.rb:423 > sender PID: 0 yes, it looks like same issue as it is during probing of framebuffer. It is hardware specific problem, so we cannot go forward without your help. Steffen can you please provide specific instructions how to debug this framebuffer stuck? This is a bit tricky to debug. For a start: if 'hwinfo --framebuffer' blocks, what's the last line it has written to the console? *If* hwinfo freezes, could you go to https://software.opensuse.org/package/mdt, install mdt and run (as root) 'mdt --modes'. Does this also freeze? The point here is that mdt uses the same code to access the video bios as hwinfo but it's easier to debug with it (as it's dedicated to this task). Created attachment 718077 [details]
The Yast 2 log file.
As requested i added a clean log of me opening "Bootloader" in YaST Control Center and selecting "Kernel Parameters" and then killing the process. I hope this helps you in finding the issue.
Steps taken:
1. Move y2log to y2log.old.
2. touch y2log.
3. Open Bootloader in YaST2 Control Center
4. Select Kernel Parameters in YaST2 Boot Loader.
5. Kill YaST2 Boot Loader process.(Because it hang indefinably)
This is what "mdt --modes" spits out for me whilst executing the following steppes: 1. Open Bootloader in YaST2 Control Center 2. Select Kernel Parameters in YaST2 Boot Loader. 3. Kill YaST2 Boot Loader process.(Because it hang indefinably) --------------------------------------------------------------------------- video bios: using int 0x10 version = 3.0, oem version = 15.50 memory = 49152k oem name [0xc0270] = "AMD ATOMBIOS" vendor name [0xc0177] = "(C) 1988-2010, Advanced Micro Devices, Inc." product name [0xc0104] = "ELLESMERE" product revision [0xc48dc] = "01.00" 18 video modes: 0x0110[bb]: 640x480+1280, 15+1 bpp, max. 400 MHz, fb: 0xc0000000, a0000.7: 64k 0x0111[bb]: 640x480+1280, 16 bpp, max. 400 MHz, fb: 0xc0000000, a0000.7: 64k 0x0113[bb]: 800x600+1664, 15+1 bpp, max. 400 MHz, fb: 0xc0000000, a0000.7: 64k 0x0114[bb]: 800x600+1664, 16 bpp, max. 400 MHz, fb: 0xc0000000, a0000.7: 64k --------------------------------------------------------------------------- steffen please check provided output. Thanks for the log! There were some changes in the hardware detection to avoid the hang around May (cf. bug 1033832), so it should no longer happen. If current Tumbleweed still has this issue feel free to reopen this bug. |