Project

General

Profile

Actions

action #44129

closed

[functional][y][timeboxed:4h][investigation] test fails in snapper_undochange - /dev/ttyS0 device or resource busy

Added by mlin7442 almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 21
Start date:
2018-11-21
Due date:
2018-12-18
% Done:

0%

Estimated time:
Difficulty:

Description

Acceptance criteria

  1. Root cause analysis is performed
  2. After 4h either we create follow-up task with current findings, or new ticket/bug depending on the outcome is created

Observation

openQA test in scenario opensuse-15.1-DVD-x86_64-extra_tests_filesystem@64bit fails in
snapper_undochange

Reproducible

Fails since (at least) Build 351.3

Expected result

Last good: 350.1 (or more recent)

Further details

Always latest result in this scenario: latest


Related issues 1 (0 open1 closed)

Related to openQA Tests - action #45284: [functional][y] Add workaround to enter password in ttyS0 while changing systemd targetRejectedokurz2018-12-182019-02-26

Actions
Actions #1

Updated by okurz almost 6 years ago

  • Subject changed from test fails in snapper_undochange - /dev/ttyS0 device or resource busy to [functional][y] test fails in snapper_undochange - /dev/ttyS0 device or resource busy
  • Assignee set to riafarov
  • Priority changed from Normal to High
  • Target version set to Milestone 21

@riafarov because of your recent experiences trying to handle the serial device, what do you think about this issue?

Actions #2

Updated by riafarov almost 6 years ago

  • Assignee deleted (riafarov)

It's definitely something not related to serial-getty. I've seen this issue before, but I definitely have seen this issue before. I could not find any open bug for this though.

Actions #3

Updated by riafarov almost 6 years ago

@okurz do you think we should handle it as [y]? I propose [u] here, to be honest.

Actions #4

Updated by okurz almost 6 years ago

  • Due date set to 2018-12-18

"snapper" relates to [y], doesn't it? This is why I suggested y-team.

Actions #5

Updated by riafarov almost 6 years ago

  • Subject changed from [functional][y] test fails in snapper_undochange - /dev/ttyS0 device or resource busy to [functional][y][timeboxed:4h][investigation] test fails in snapper_undochange - /dev/ttyS0 device or resource busy
  • Description updated (diff)
  • Status changed from New to Workable

It's about serial output which fails, so it's oversimplified thinking, like assigning tickets to the test module maintainers. I propose to make it timeboxed to do the proper investigation and do not leave it as a "fix the world" task for the issue we don't know about.

Actions #6

Updated by okurz almost 6 years ago

Of course, I don't see "assignment" as contract written in blood to fix the whole issue or … "the world", just to provide the next bread crumb ;)

Actions #7

Updated by riafarov almost 6 years ago

Arvin from the YaST team can help with investigation as snapper inventor.

Actions #8

Updated by okurz almost 6 years ago

My suggestion to crosscheck behaviour on older product versions:

Download https://openqa.opensuse.org/assets/hdd/opensuse-42.3-x86_64-GM-gnome@64bit.qcow2 and/or https://openqa.opensuse.org/assets/hdd/opensuse-15.0-x86_64-GM-gnome@64bit.qcow2 and check manually if the same problem happens there. If we confirm it's a change in the product we can try to find out if the change intended, e.g. find out if an additional service, e.g. "getty" is enabled for the rescue systemd target, then try to find out by which files this relation is defined, then find out which package owns this file with rpm -qf <file>, then look into the changelog of this package with rpm -q --changelog <package> | less, take a look for bugs or persons and use that to talk to people :)

Actions #9

Updated by oorlov almost 6 years ago

  • Status changed from Workable to In Progress
  • Assignee set to oorlov
Actions #10

Updated by oorlov almost 6 years ago

  • Status changed from In Progress to Feedback

After deeper investigation I've found out, that it happens while switching to another systemd target (to rescue in the case) if 'console=ttyS0 console=tty" boot parameters were set during installation.

While switching to rescue target, the system asks for a password. If enter it in tty1, the ttyS0 will still wait for the password and that caused the "bash: /dev/ttyS0: Device or resource busy" while echoing to /dev/ttyS0. If then enter the password in ttyS0 it starts working as expected.

The changed behavior of the product was introduced in Leap 15.1, build 351.3.

Created bugzilla ticket: https://bugzilla.opensuse.org/show_bug.cgi?id=1119123

Actions #11

Updated by oorlov almost 6 years ago

  • Status changed from Feedback to Resolved

As decided during the refinement meeting, putting the ticket to resolved (because it is time-boxed one and boo ticket is enough for resolving it)

Actions #12

Updated by okurz almost 6 years ago

  • Status changed from Resolved to Feedback

Unfortunately though this is related to currently failing tests, no one looked into the bug and you set the severity to "minor" (but at least the blocker flag) so I wonder if we should try to apply a workaround? WDYT? If yes, then please create a follow-up ticket an close again, if not, please explain that and just close again. Thanks.

Actions #13

Updated by oorlov almost 6 years ago

  • Status changed from Feedback to Resolved

After discussion it was decided that riafarov will create a progress ticket, which is blocked by the boo#1119123 to monitor the issue.

All further actions will be identified in the ticket.

Actions #14

Updated by okurz almost 6 years ago

You know the problem I have observed often enough in the past is that people close a ticket and then there is no followup until someone else realizes and becomes frustrated because there was no follow-up ticket. When you prefer to have this ticket closed and not provide the followup ticket then I feel the need to track the followup elsewhere, e.g. note down on my todo-list to check later if any followup ticket was created. To not frustrate you for the time being I will not open the ticket again because I did not understand your reasoning completely.

Actions #15

Updated by oorlov almost 6 years ago

  • Related to action #45284: [functional][y] Add workaround to enter password in ttyS0 while changing systemd target added
Actions

Also available in: Atom PDF