|
Bugzilla – Full Text Bug Listing |
| Summary: | Change date and time screen wrongly visualized in ncurses | ||
|---|---|---|---|
| Product: | [SUSE Linux Enterprise Server] PUBLIC SUSE Linux Enterprise Server 15 SP3 | Reporter: | Joaquín Rivera <jeriveramoya> |
| Component: | YaST2 | Assignee: | YaST Team <yast-internal> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | igonzalezsosa, jeriveramoya, jlopez, kanderssen, sbrabec |
| Version: | GMC | ||
| Target Milestone: | unspecified | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/z6Cvb7Mh | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
logs when entering that screen
screenshot of that screen in ncurses [Good] Screenshot in ncurses on an installed system these are the three lines of text left in the screen when navigating back same text is repeated in the wrong place same area after refresh |
||
Created attachment 850098 [details]
screenshot of that screen in ncurses
I guess that was that a manual test, right? Did you try Ctrl-L to force a manual redraw? We had screen redraw problems with QEMU in the past. This might be another one of them. Created attachment 850100 [details]
[Good] Screenshot in ncurses on an installed system
Just for comparison, I am attaching a screenshot of the same screen in an installed system.
According to the logs, Joaquín's screenshot is from the installer, right? In that case, we are running under fbiterm. It might be relevant. That's not another variant of bug 1186093? (In reply to Steffen Winterfeldt from comment #5) > That's not another variant of bug 1186093? That one was about a wrong or broken font; this one looks like not redrawing parts of the screen correctly. But both IMHO probably have the same root cause: Not 100% reliable NCurses rendering in that environment (fbiterm and/or QEMU). ctrl-L fixed visualization of the screen when I tried in VM with SLE and openSUSE in textmode in the installer. We had such problems in the past, but always only in that very specific QEMU environment; I am not aware of any customer ever reporting this in a real terminal environment with a human interacting with it. It is possible that openQA is a bit quick to grab the screen content. It is also possible that QEMU has some trouble interpreting all those escape sequences that libNCurses sends. But it can also be on the kernel console side, on the libNCurses side or on the fbiterm side. Pick your poison... Hi all, OK, so it is not clear where to start looking. Stanislav, as fbiterm's maintainer, could you have a look? Or at least, could you point us in the right direction? Thanks! If you can reproduce the problem in the fbiterm only, then it is either a problem of fbiterm or a problem of its terminfo description. Actually, the screenshot indicates that the expected cursor row is not equal to the real cursor row. The rendering process probably did the position reset. There can be alternative sources of this problem than fbiterm or terminfo: - Font change during the application run and ignored SIGWINCH signal. To verify that it is not an issue, please: Verify that $LINES match the real number of lines: for i in $(seq 0 $((LINES-1))) ; do echo line $i ; done If $LINES is correct, you should see numbers from 1 and shell prompt on the last line. After this test, run "yast2 timezone" separately. I tried that, and I cannot reproduce in that way. - Incorrect TERM In my case, fbiterm set TERM=iterm. - Possible problem in the application (e. g. writing some EOL characters outside ncurses). I went to that screen with refreshment issues in Tumbleweed and I switched virtual console to tty2 where I run the loop, $LINES is 48, so I can see printed "line 1 ... line 47" and the prompt again. At that point I cannot run yast2 timezone because I'm in the installation (where the bug occurs) and I cannot run another simultaneous installation. `echo $TERM` shows 'linux' during installation. Created attachment 850179 [details]
these are the three lines of text left in the screen when navigating back
Created attachment 850180 [details]
same text is repeated in the wrong place
Created attachment 850181 [details]
same area after refresh
I have tried YaST timezone inside fbiterm with TERM=linux. The result is a rendering breakage, but a different than the reported one. => Not a problem with TERM. The number of LINES also matches. => Probably no problem with SIGWINCH (But we cannot say it by sure, as installer does not log it.) So there are two questions: Is it reproducible by hand, not inside the openQA. It could really be a rendering race. And actually, are you sure that the screenshot comes from fbiterm? The font does not look like a default fbiterm font, but looks like a standard VT font. A tip for openQA in general: util-linux contains a "script" tool. It could be used for all console based tests. Screenshot just allows to log only a snapshot of a state, but "script" log could log all characters that appeared on the display including the exact time. It is reproducible by hand just running a VM (as mentioned on the first comment). Screenshots I provided are from normal manual installation in a VM. Interesting tool this 'script' utility, I tried to use it but as the recording and the installation run in different virtual consoles I could not record the info. So then I tried to use boot parameter startshell=1, start the recording by running 'script' and manually triggering yast.ssh, but when I get to the screen the refreshment is ok in this case and there is no bug. The bug only occurs when yast.ssh is triggered automatically. Interesting. If the bug cannot be reproduced inside "script" tool, we can eliminate incorrect terminfo and incorrect sequence at all. (It also explains, why Ctrl-L redraws correctly.) The most probable problem is a rendering race (output is displayed before the text is fully rendered). I do not have insight to the VM installation process. What is your exact reproduction environment? You are running a VM with the installation inside qemu. Is the installation fbiterm called inside the VM and converted to graphics output by qemu? Or it is a virtual serial inside the VM, and the fbiterm runs outside the VM and it is connected to the virtual serial console? I'm using virtual manager just grabbing the iso and installing, nothing special, so perhaps YaST developers can answer better that question. Joaquín is not doing anything special, so fbiterm should be running within qemu, no serial lines involved. Any update here? Is this still happening? With latest TW and virtual manager I can still reproduce it. (In reply to Joaquín Rivera from comment #21) > With latest TW and virtual manager I can still reproduce it. Thanks Joaquín for checking. Tracking in our trello. We need to take a deeper look. This *might* be related to bug #1191112: Another redraw problem, and it also only happens in QEMU. In a slightly different context we observed a similar screen redraw problem, but only when using terminal type ($TERM) "screen-256color". When we changed that to something different (e.g. "vt100"), the problem was gone. IMHO that is clearly a bug in that terminal emulation (the "screen" terminal session manage?) or in the terminfo entry of that terminal. Could you try that? As Stefan commented we found some ncurses redraw issue when using tmate (TERM screen-256color) And I was able to reproduce the issues described here too as you can see in the GIF. https://user-images.githubusercontent.com/7056681/152360996-00efe4ec-8be6-4dfc-86bc-a118fb7608a6.gif Joaquin, we are waiting for your feedback to comment #24. Yes, sorry I missed this notification somehow, Just booting with Virtual Manager this textmode installation https://openqa.suse.de/tests/8168951/asset/hdd/sle-15-SP4-x86_64-97.1-textmode@64bit.qcow2 and running `TERM=screen-256color yast2 timezone` the screen appears for a moment ok, and then it shows in wrong way as the bug reported (once the specific NTP Server is displayed). If trigger with `yast2 timezone` the refreshment of the NTP Server doesn't show any issues in the screen. Similar result for this black and white you mentioned `TERM=vt100 yast2 timezone`. (In reply to Joaquín Rivera from comment #27) > Just booting with Virtual Manager this textmode installation > https://openqa.suse.de/tests/8168951/asset/hdd/sle-15-SP4-x86_64-97.1-textmode@64bit.qcow2 Unfortunately, that link expired in the meantime. :-( > and running `TERM=screen-256color yast2 timezone` the screen appears for a > moment ok, and then it shows in wrong way as the bug reported (once the > specific NTP Server is displayed). > > If trigger with `yast2 timezone` the refreshment of the NTP Server doesn't > show any issues in the screen. Similar result for this black and white you > mentioned `TERM=vt100 yast2 timezone`. So, this problem appears only with TERM=screen-256color, but not with TERM=vt100, right? I am a bit confused here. If it depends on that terminal type, the problem is not on the YaST side. It might be a bug in the terminfo entry (/etc/terminfo, /usr/lib/terminfo) or in the terminal emulation (most likely "screen"). Or it might simply be a wrong setting of $TERM. So it looks like we came to a dead end with this. Nobody seems to be willing to take over. It is a valid problem, but for sure it's not on the YaST side; it may be an unfortunate combination of a terminal type that isn't set 100% correctly, a terminal emulation that doesn't emulate 100% correctly, and QEMU weirdness. Closing before it reaches its anniversity. |
Created attachment 850097 [details] logs when entering that screen I noticed running in VM and in openQA that 'Change date and time' screen has some visualization problem in ncurses.