[functional][y][timeboxed:4h][investigation] test fails in snapper_undochange - /dev/ttyS0 device or resource busy
- 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
openQA test in scenario opensuse-15.1-DVD-x86_64-extra_tests_filesystem@64bit fails in
Fails since (at least) Build 351.3
Last good: 350.1 (or more recent)
Always latest result in this scenario: latest
#1 Updated by okurz about 4 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?
#5 Updated by riafarov about 4 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.
#8 Updated by okurz almost 4 years ago
My suggestion to crosscheck behaviour on older product versions:
Download https://openqa.opensuse.org/assets/hdd/opensuse-42.3-x86_64-GMfirstname.lastname@example.org and/or https://openqa.opensuse.org/assets/hdd/opensuse-15.0-x86_64-GMemail@example.com 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 :)
#10 Updated by oorlov almost 4 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
#12 Updated by okurz almost 4 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.
#14 Updated by okurz almost 4 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.