[ipmi unstability] jobs got blue screen making openqa needle match does not work
The blue screen looks like https://openqa.suse.de/tests/2319257#step/boot_from_pxe/25, and when it happens, needle matching mechenism of openqa will not work(creating new needle based on the blue screen not work and with such needle when retrigger jobs, job will fail at any needle matching).
@coolo, thanks for noticing this ticket.
Yes, the process is:
When blue screen issue happens on ipmi machines, tried to add a needle based on https://openqa.suse.de/tests/2319257#step/boot_from_pxe/25 with sshd-server-started tag, which aims to make assert_screen 'sshd-server-started' pass when this specific blue screen issue happens again.
However after this blue needle added, from the next triggered job, all needle matching will not work any more. That is to say from the first needle matching, https://openqa.suse.de/tests/2319257#step/boot_from_pxe/1, it will never succeed in needle match, although the screen should be exactly correct and matched.
But if remove that blue screen needle https://openqa.suse.de/tests/2319257#step/boot_from_pxe/25 from needle directory, needle match works again.
Well, black font on dark blue looks to openQA eyes (and to most human eyes) as pure black, so there is no way you can differ this.
So you better research if there is some key combination that resets the terminal (ctrl-L comes to mind) that you can press in case you didn't see the ssh needle in time. It's a design decision for openQA to look like a half blind snake and while technically we could offer HD needles, it won't happen soon.
@coolo, thanks for the suggestion. Sorry, would you please explain further, in your suggestion, what are expected to happen when such key to reset the terminal are sent? Screen refreshed and redisplayed without the blue screen background?
Actually for this specific case, when the 'sshd-server-started' screen shows, it means ssh service started, and next step of test is to start the root-ssh console to type yast.ssh to trigger installation. So what we want to find is a way to workaround this blue screen issue and check whether sshd starts to start later ssh session.