action #45284
closed[functional][y] Add workaround to enter password in ttyS0 while changing systemd target
0%
Description
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
The Problem¶
snapper_undochange test module fails with "/dev/ttyS0 device or resource busy".
The issue 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.
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
Suggestions¶
- Type password to both tty and ttyS0 in btrfs_test.pm -> sub snapper_nodbus_setup;
- Add softfail pointing to boo#1119123 while typing a password to ttyS0.
Further details¶
Always latest result in this scenario: latest
Updated by oorlov over 5 years ago
- Related to action #44129: [functional][y][timeboxed:4h][investigation] test fails in snapper_undochange - /dev/ttyS0 device or resource busy added
Updated by oorlov over 5 years ago
- Subject changed from [functional][y] Add workaround for to [functional][y] Add workaround to enter password in ttyS0 while changing systemd target
Updated by okurz over 5 years ago
- Description updated (diff)
- Due date set to 2019-02-12
- Category changed from Enhancement to existing tests to Bugs in existing tests
- Status changed from New to Blocked
- Assignee set to okurz
Let's wait if anyone picks up the bug.
Updated by okurz about 5 years ago
- Due date changed from 2019-02-12 to 2019-02-26
- Status changed from Blocked to Rejected
- Target version changed from Milestone 22 to Milestone 23
No movement in the bug. Time for a workaround?
The latest job https://openqa.opensuse.org/tests/851109 and actually all since build 375.2 are fine again. Did something change? Closing bug as WORKSFORME as well as this ticket.