action #103344
closed[Timebox: 8h] Investigate why the partitioning issues is not present in the logs (sporadically?)
Description
Observation¶
openQA test in scenario sle-15-SP4-Online-x86_64-autoyast_lvm@64bit fails in
verify_y2log_entries
Test suite description¶
AutoYaST installation using LVM for partitioning, having GPT with /, /opt and
swap Logical Volumes in a single Volume Group. Following is validated in the SUT:
- LVM configuration.
- Firewall configuration.
- Subvolumes configuration.
- Passwords are set for the users in the profile.
In our group this job fails three consecutive times: https://openqa.suse.de/tests/7758412#next_previous
Nevertheless with the same build one of the automatic retriggered runs worked: https://openqa.suse.de/tests/7759588#step/verify_y2log_entries/2
We should try to run it at least 10 times to see how it behaves and file a bug if it is not logged sporadically for some reason.
Task¶
- Double-check the logs manually;
- Ask YasT development team for the assistance in case the root cause of issue is unclear.
Updated by JERiveraMoya over 2 years ago
- Project changed from openQA Tests to qe-yam
- Subject changed from [Timebox: 8] Investigate why the partitioning issues is not present in the logs (sporadically?) to [Timebox: 8h] Investigate why the partitioning issues is not present in the logs (sporadically?)
- Category deleted (
Bugs in existing tests) - Target version set to Current
Updated by oorlov over 2 years ago
- Tags deleted (
qe-yast-refinement) - Description updated (diff)
- Status changed from New to Workable
Updated by JERiveraMoya over 2 years ago
It also happens here: https://openqa.suse.de/tests/7887598#step/verify_y2log_entries/4
As a clue, both test suite were using validation using external server, so they are pretty old and some param might not be working fine in the ay profile (at least most of the problem are related with that in old ay profile xmls)
Updated by JRivrain over 2 years ago
- Status changed from Workable to In Progress
- Assignee set to JRivrain
Updated by JRivrain over 2 years ago
It did not happen in the last build in production, but I cloned it 20 times and could confirm it is still present, yet sporadic. I thought of some log rotation deleting the last log after the fifth, but it did not look plausible as on my own system I see some files like y2log-9.gz from 2019. So I reported a bug https://bugzilla.suse.com/show_bug.cgi?id=1194022, if some log rotation that we are not aware of was implemented, at least it will be clarified, and if not, then this is certainly a valid bug.
Updated by JRivrain over 2 years ago
- Status changed from In Progress to Feedback
- Assignee deleted (
JRivrain) - Target version deleted (
Current)
Updated by JERiveraMoya over 2 years ago
- Status changed from Feedback to Closed
- Assignee set to JRivrain
- Target version set to Current
Thanks for the investigation, let's close the ticket with you as assignee. I labeled the job with the bug then.