action #44129
closed[functional][y][timeboxed:4h][investigation] test fails in snapper_undochange - /dev/ttyS0 device or resource busy
0%
Description
Acceptance criteria¶
- Root cause analysis is performed
- 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
Updated by okurz about 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?
Updated by riafarov about 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.
Updated by riafarov about 6 years ago
@okurz do you think we should handle it as [y]? I propose [u] here, to be honest.
Updated by okurz about 6 years ago
- Due date set to 2018-12-18
"snapper" relates to [y], doesn't it? This is why I suggested y-team.
Updated by riafarov about 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.
Updated by okurz about 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 ;)
Updated by riafarov about 6 years ago
Arvin from the YaST team can help with investigation as snapper inventor.
Updated by okurz about 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 :)
Updated by oorlov about 6 years ago
- Status changed from Workable to In Progress
- Assignee set to oorlov
Updated by oorlov about 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
Updated by oorlov about 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)
Updated by okurz about 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.
Updated by oorlov about 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.
Updated by okurz about 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.
Updated by oorlov about 6 years ago
- Related to action #45284: [functional][y] Add workaround to enter password in ttyS0 while changing systemd target added