Is there a more recent test failure than the linked one from three months ago?

I suspect an issue with systemd-vconsole-setup, but the showconsolefont output looks correct: https://openqa.opensuse.org/tests/1488788#step/consoletest_setup/49

(In reply to Fabian Vogt from comment #1)
> Is there a more recent test failure than the linked one from three months
> ago?

Yes, it happened in extra_tests_textmode test from snapshot 20210221:
https://openqa.opensuse.org/tests/1640220#step/yast2_lan_device_settings/14

New occurrence with snapshot 20210308: https://openqa.opensuse.org/tests/1662622#step/ncurses/6

Can I have the terminal type as well as terminal configuration and value of TERM variable?  Also the ncurses version/changlog info of the affected system?

Hmmm ... just compared ncurses from a actual build and Leap 15.2

werner/ncurses> infocmp -T linux -1 | diff -uwp ~/tmp/linux.ti -
--- /suse/werner/tmp/linux.ti   2021-03-11 09:01:47.253612000 +0100
+++ -   2021-03-11 09:02:07.296997333 +0100
@@ -12,7 +12,7 @@ linux|linux console,
        it#8,
        ncv#18,
        pairs#64,
-       acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+       acsc=++\,\,--..00__``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}c~~,
        bel=^G,
        blink=\E[5m,
        bold=\E[1m,


where ~/tmp/linux.ti is from ncurses 6.2.20210306 build in a latest Factory

Seems to be ncurses-6.2-20200711.patch with

+20200711
+       + fix pound-sign mapping in acsc of linux2.6 entry (report by Ingo
+         Bruckl).

@@ -1029,8 +1029,8 @@
 #      'r' scan line 7
 #      '_' scan line 9
 linux2.6|linux 2.6.x console,
-       acsc=++\,\,--..00__``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwx
-            xyyzz{{||}c~~,
+       acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxy
+            yzz{{||}}~~,
        enacs=\E)0, rmacs=^O,
        sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5
            %t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;,

as this is a bug fix I need some more information about the mapping for the
line graphics mapping on our system and those of Ingo Bruckl

Or I'm wrong and the screen shot shows a principal broken line graphics mapping

(In reply to Dr. Werner Fink from comment #4)
> Can I have the terminal type as well as terminal configuration and value of
> TERM variable?

Unfortunately not easily. It's essentially a random failure, which indicates a race condition. It's not easily reproducible.

> Also the ncurses version/changlog info of the affected system?

This issue occurs in tests from a while ago, so I don't think the version helps much.

I've just tested the new linux terminfo entry on my Leap 15.2 and it works on my linux console here:

   /local/werner> strace -o log dialog --yesno yesno 5 30

perfect line graphics and

   /local/werner> grep terminfo log
   stat("/local/werner/.terminfo", {st_mode=S_IFDIR|0755, st_size=15, ...}) = 0
   stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
   stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
   access("/local/werner/.terminfo/l/linux", R_OK) = 0
   openat(AT_FDCWD, "/local/werner/.terminfo/l/linux", O_RDONLY) = 3
   /local/werner> infocmp -T linux -1 | grep acsc
       acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,

Nevertheless the date with the patch ncurses-6.2-20200711.patch and the first occurrence seems to correspond

>  Fails since (at least) Build [20200714](https://openqa.opensuse.org/tests/1333590)

no idea if this is causal

(In reply to Fabian Vogt from comment #7)
> (In reply to Dr. Werner Fink from comment #4)
> > Can I have the terminal type as well as terminal configuration and value of
> > TERM variable?
> 
> Unfortunately not easily. It's essentially a random failure, which indicates
> a race condition. It's not easily reproducible.
> 
> > Also the ncurses version/changlog info of the affected system?
> 
> This issue occurs in tests from a while ago, so I don't think the version
> helps much.

I need information otherwise I can do exactly nothing.   It should be possible to take a snapshot of the QA system to allow to logon

What type of font is used on the linux console ... does it use console magic sequences and/or are console magic sequences given in /etc/sysconfig/console ...

adding maintainers of kbd to carbon copy

Still I do not know what console font is used!

Also what kind of hardware/platform is missed ... is this ARM/ARM64?

(In reply to Dr. Werner Fink from comment #12)
> Still I do not know what console font is used!

How to check this?
I can update the openQA test to collect required data on failure, if you tell me exactly what and how to do it.

(In reply to Dr. Werner Fink from comment #13)
> Also what kind of hardware/platform is missed ... is this ARM/ARM64?

This happens in qemu VM for both x86_64 and aarch64.

(In reply to Guillaume GARDET from comment #14)
> (In reply to Dr. Werner Fink from comment #12)
> > Still I do not know what console font is used!
> 
> How to check this?
> I can update the openQA test to collect required data on failure, if you
> tell me exactly what and how to do it.

The values set /etc/sysconfig/console like CONSOLE_FONT,
CONSOLE_MAGIC, CONSOLE_ENCODING,

The value TERM on the console (should be linux and not old cons25 or similar)

Please be aware that the nurses API use a escape sequence to switch
line graphics mode on and off of the used console font.  If you are using the
option --ascii-lines ... like

  dialog --ascii-lines --yesno yesno 5 30

then the real characters are shown as it are defined and shown in
man:terminfo(5) at section `Line Graphics` at the table in column
`Ascii Default` ... and as this works with the ACS characters

  acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,

in new TERM=linux as I've seen on the console it is very likly that this
is not an error of ncurses.

> 
> (In reply to Dr. Werner Fink from comment #13)
> > Also what kind of hardware/platform is missed ... is this ARM/ARM64?
> 
> This happens in qemu VM for both x86_64 and aarch64.

Hmmm ... it could be a problem with qemu and its EGA/VGA console emulation
and it  this happens randomly this smells like not initialized start values
for the font character mapping

That would be one possible cause:

https://github.com/qemu/qemu/blob/master/ui/curses.c

The simple ncurses dialog used in openQA is:
  dialog --yesno "test for boo#1054448" 3 20

So, no '--ascii-lines' option set.

PR to update the openQA test to upload required info on failure: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12123

(In reply to Guillaume GARDET from comment #17)
> The simple ncurses dialog used in openQA is:
>   dialog --yesno "test for boo#1054448" 3 20
> 
> So, no '--ascii-lines' option set.
> 
> PR to update the openQA test to upload required info on failure:
> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12123

Sorry but you have not taken it ... I'm aware of the yesno window
and the broken line graphic characters but ... just try with

  dialog --ascii-lines --yesno "test for boo#1054448" 3 20

what is shown then?  Are there shown ASCII lines or also crap?

As this seems to be a qemu bug ... where can I set qemu

This simple bash command line

  echo "$(tput smacs)lqqqqqqqqqqqqqqqqk$(tput rmacs;tput sgr0)"

should show a Line Graph on both console and xterm , if not the font
is broken.

Even more

  echo "$(tput smacs;tput setaf 1;tput bold)lqqqqqqqqqqqqqqk$(tput rmacs;tput sgr0)"

bold red line graph

(In reply to Guillaume GARDET from comment #17)
> The simple ncurses dialog used in openQA is:
>   dialog --yesno "test for boo#1054448" 3 20
> 
> So, no '--ascii-lines' option set.
> 
> PR to update the openQA test to upload required info on failure:
> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12123

Is there a way to change this into

  dialog --yesno "test for boo#1054448" 3 20 | tee boo_1054448.tee

and provide the resulting boo_1054448.tee as attachment.  With this
I would be able togetehr with the value of the variable TERM to see if ACS character mapping is used by ncurses.

Notabene:  The bug boo#1054448 is about the rep feature of XTerm (repeat character) that is that this check is only usefull for terminal types which are using exactly this feature (and the linux console does not!):

 /local/werner> infocmp -1 | grep rep
         rep=%p1%c\E[%p2%{1}%-%db,
 /local/werner> infocmp -T linux -1 | grep rep
 /local/werner> 

with this rep feature the the line graph looks like

tput -S <<!
smacs
rep 108 0
rep 113 20
rep 107 0
rep 10 0
rmacs
!

without the rep feature this becomes

tput smacs; echo lqqqqqqqqqqqqqqqqqqqk; tput rmacs

clearly the ncurses uses the information from the terminfo data pointed by the TERM variable to use or not use the rep feature

There is a very similar bug 1180613 in SLE 12 SP5. (Exactly, the bug is very same, but that one is reproducible in some setups, this one is random.)

(In reply to Stanislav Brabec from comment #24)
> There is a very similar bug 1180613 in SLE 12 SP5. (Exactly, the bug is very
> same, but that one is reproducible in some setups, this one is random.)

Maybe I should write a simple shell script to check with help of TERM, if the terminfo descriptions fits to the used terminal line/device, and using tput to check the line graphics as well.

That might be better then using dialog to check a not valid bug on linux console

Created attachment 847273 [details]
bash script cursescheck

this script does check for ACS Line Graphic mapping as well as the the REP capability of the current terminal line using the TERM variable to get the description of the terminal.

If in the terminfo description no ACS mapping is found then the script does not show line graphics. Also if no REP capability is found in the terminfo description then the second test of the line graphics is skipped.

I'd like to ask to replace this dialog check for boo#1054448 with this script cursescheck as it checks if the line graphic works for the terminfo description given by the TERM variable on the current terminal line... and after 5 seconds or pressing enter ... check if the rep fcpability is found in the terminal description given by the TERM variable and if so test this as well for five seconds .... the script requires an installed ncurses-utils package and standard tools otherwise it will show an error

Created attachment 847343 [details]
bash script cursescheck ... now  with color if available as well as three pages

to check all ACS line gaphich characters found in terminfo description of variable TERM

Created attachment 847392 [details]
tee file of the broken ncurses dialog

A new occurrence of ncurses test failed and the simple red line is broken:
https://openqa.opensuse.org/tests/1670502#step/ncurses/4

as well as the ncurses simple dialog: https://openqa.opensuse.org/tests/1670502#step/ncurses/9

The tee file of the ncurses dialog has been added in attachment to this bug.

$TERM is set to 'linux': https://openqa.opensuse.org/tests/1670502#step/ncurses/196

Created attachment 847396 [details]
screenshot wit my smartphone

(In reply to Guillaume GARDET from comment #29)
> Created attachment 847392 [details]
> tee file of the broken ncurses dialog

Thanks ... just downloaded and had done a 

  cat ~werner/Downloads/ncurses-boo_1054448.tee

on the local linux comnsole /dev/tty1 and it works flawless!

IMHO this is not a problem of ncurses not any ncurses based application as here only the informations of /usr/share/terminfo/l/linux via TERM=linux is used and it works as shown.  Here we mighth have a broken console font setup or a broken font its self or a broken VGA/EGA qemu emulator for aarch64.

It could be also the wrong terminal line for TERM=linux ... or what kind of terminal line the device /dev/ttyAMA0 is?  This looks like a serial line and this might be something like TERM=vt100

This is not aarch64 specific and happens on x86_64 as well.

/dev/ttyAMA0 is a serial which is not used for this test.

Given the randomness, I would go for a broken console font setup, likely due to some race conditions. 
How should we check this?

From the tee I see that ncursesw is used as the line graphs are UTF-8 based

 e2 94 80

which is U+2500, compare with

 https://www.utf8-chartable.de/unicode-utf8-table.pl?start=9472&unicodeinhtml=dec

looks like a wrong UTF-8 locale setup on the terminal line or a console font which wrong UTF-8 line glyphs.

(In reply to Guillaume GARDET from comment #34)
> This is not aarch64 specific and happens on x86_64 as well.

But with qemu I guess ... or has this ever been seen on real hardware?

> 
> /dev/ttyAMA0 is a serial which is not used for this test.
> 

OK, taken

> Given the randomness, I would go for a broken console font setup, likely due
> to some race conditions. 
> How should we check this?

I would search for a wrong console font setup, that is with wrong UTF-8 line glyphs as this dialog program uses ncursesw and hence uses UTF-8 glyphs.

Created attachment 847400 [details]
bash script cursescheck ... now also with UTF-8 line glyphs

This one check not only for ACS but also for UTF-8 glyphs

Created attachment 847404 [details]
bash script cursescheck ... now also with UTF-8 line glyphs (also working on console)

To solve this it would be a start point to look for the console used font.  That are the values  set in /etc/sysconfig/console like CONSOLE_FONT,
CONSOLE_MAGIC, and CONSOLE_ENCODING.

Then to check if the font loaded does include the required line glyphs, e.g. by using exactly this font on a hardware system, and if this works then to check the VGS/EGA implementation of qemu at https://github.com/qemu/qemu/blob/master/ui/curses.c

To debug this it would be very helpful to see if the console font and its mapping on the current terminal device line is configured correct.

For this I'd like to propose the command sequence

   tty
   tput init
   echo -en '\x0elqqqqqqqqqqk\x0f\n'
   . /etc/sysconfig/console
   echo $CONSOLE_FONT
   find /usr/share/kbd/consolefonts/ -name "${CONSOLE_FONT}*"
   loadunimap -o old.uni lat1
   grep 'U\+2500' old.uni
   echo -en '\x0elqqqqqqqqqqk\x0f\n'

I'm interested not only on the output of the command sequence above but also on the file

   old.uni

to see what mapping is really loaded.  This mapping is used to get the correct eight bit byte line glyph of the loaded font on the multi byte character line glyph as well as on the alternates characters set (ACS) line glyp

(In reply to Dr. Werner Fink from comment #43)
> To debug this it would be very helpful to see if the console font and its
> mapping on the current terminal device line is configured correct.
> 
> For this I'd like to propose the command sequence
> 
>    tty
>    tput init
>    echo -en '\x0elqqqqqqqqqqk\x0f\n'
>    . /etc/sysconfig/console
>    echo $CONSOLE_FONT
>    find /usr/share/kbd/consolefonts/ -name "${CONSOLE_FONT}*"
>    loadunimap -o old.uni lat1
>    grep 'U\+2500' old.uni
>    echo -en '\x0elqqqqqqqqqqk\x0f\n'
> 
> I'm interested not only on the output of the command sequence above but also
> on the file
> 
>    old.uni
> 
> to see what mapping is really loaded.  This mapping is used to get the
> correct eight bit byte line glyph of the loaded font on the multi byte
> character line glyph as well as on the alternates characters set (ACS) line
> glyp

Any news on that question?

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: upgrade_Leap_15.0_kde
https://openqa.opensuse.org/tests/2134828

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: upgrade_Leap_15.0_kde
https://openqa.opensuse.org/tests/2169767

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Is this bug still valid on Tumbleweed?  ... 


> This bug is still referenced in a failing openQA test: upgrade_Leap_15.0_kde
https://openqa.opensuse.org/tests/2169767


... seems not be Tumbleweed

Yes, it still occurs on Tumbleweed: https://openqa.opensuse.org/tests/2180751#step/yast2_lan/14

I had never seen an answer on my comment #44

In the QA report there is no Hardware Type nor Architercture nor used locale nor used Encoding nor used Font mapping specified and therefore those are not very useful.

I guess due initial report says x86_64 and aarch64 ...or are we talking about KVM x86_64 and KVM aarch64 ... but why I can not reproduce this on both of my x86_64 worksations on the console?

Run my cursescheck bash script on those affected consoles and then determine used terminal type in TERM, the locale settings, the font, font encoding, and font mapping (normal done by psfu font with setfont) .... maybe the used console magics and so on (compare with /etc/sysconfig/console)

(In reply to Dr. Werner Fink from comment #49)
> I had never seen an answer on my comment #44

I need to run this on an affected system, but this is not easily reproducable. So, it take times.

> In the QA report there is no Hardware Type nor Architercture nor used locale
> nor used Encoding nor used Font mapping specified and therefore those are
> not very useful.
> 
> I guess due initial report says x86_64 and aarch64 ...or are we talking
> about KVM x86_64 and KVM aarch64 ... but why I can not reproduce this on
> both of my x86_64 worksations on the console?

This has been seen on some openQA qemu runs.
This might be a race condition, triggered more often in openQA qemu.

> Run my cursescheck bash script on those affected consoles and then determine
> used terminal type in TERM, the locale settings, the font, font encoding,
> and font mapping (normal done by psfu font with setfont) .... maybe the used
> console magics and so on (compare with /etc/sysconfig/console)

I will provide the traces/files once I can reproduce.

Make sure that the package lmod is *not* installed not on a server for running kvm nor on the clients ... I've a report that lmod seems to cause trouble with font mapping on linux console

Before any access to any of the virtual consoles the systemd-vconsole-setup(8) has to be executed to be sure that the configuration in vconsole.conf(5) is applied (font with its font mappings as well as the keymap)

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: kde-wayland@
https://openqa.opensuse.org/tests/2414353#step/yast2_lan/1

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

This is not my bug.  The problem is not ncurses but the the wrong configured console its self.  The ncurses library does its job, nothing more and nothing less.  I've debug this problem and showed how it might be solved (see comment #52)

Assign it to reporter, based on the comment above, it needs to update the testing code.

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16086 for openqa test fix

(In reply to WEI GAO from comment #56)
> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16086 for
> openqa test fix

Reassigned to you then.

Does this bug still occur?

(In reply to Chenzi Cao from comment #55)
> Assign it to reporter, based on the comment above, it needs to update the
> testing code.

No, this is a product bug and not a test bug.

(In reply to Fabian Vogt from comment #58)
> Does this bug still occur?

Yes, it does in Tumbleweed and likely in SLE/Leap.

(In reply to Guillaume GARDET from comment #59)
> (In reply to Fabian Vogt from comment #58)
> > Does this bug still occur?
> 
> Yes, it does in Tumbleweed and likely in SLE/Leap.

Can you link to the latest occurence?

(In reply to Fabian Vogt from comment #60)
> (In reply to Guillaume GARDET from comment #59)
> > (In reply to Fabian Vogt from comment #58)
> > > Does this bug still occur?
> > 
> > Yes, it does in Tumbleweed and likely in SLE/Leap.
> 
> Can you link to the latest occurence?

Snapshot 20221213: opensuse-Tumbleweed-NET-aarch64-Build20221213-zdup_tw2twnext_gnome@aarch64 - https://openqa.opensuse.org/tests/2952996#step/yast2_lan/15

Sanpshot 20221214: opensuse-Tumbleweed-NET-aarch64-Build20221214-zdup-Leap-15.3-kde@aarch64 - https://openqa.opensuse.org/tests/2957876#step/yast2_lan/14

May be a stupid question, but could we not make sure that the service runs as part of multi-user target by adding WantedBy=multi-user.target in the service file ?