QA » openQA Project » openQA Infrastructure

@tinawang123 I don't think we can anything about that from openQA side. This is quite usual behaviour I have seen in Linux regardless of the architecture and definitely not related to a specific machine. You need to handle that behaviour in test code accordingly.

JERiveraMoya wrote in #note-3:

Is there any other way to have a fresh lpar there?

Potentially by wiping the LPAR assigned storage from novalink at the beginning of the test execution.
As alternative one could try to force a refresh of storage devices from the Linux system.

to reboot at that point and handling on the test would be an overkill, this new setup for some reason does't allow to perform that operation.

What do you mean with "new setup"? What we have now in PRG2 are the very same machines that were already used in before.

Unfortunately, latest build doesn't pass the bootloader to give you any feedback here (sorry for the delay in any case).
Once that happens we might consider your advice there (although technically I don't know how can be done).
The issues most likely will persist, but if you prefer reject it for now we can reopen later, up to you how to handle it.
The other point is that now I know that they are the same machines that have existing issues from years ago, thanks for that info.

Here is the sporadic issue: https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le-spvm&test=create_hdd_textmode_yast&version=15-SP6#next_previous

What command did you suggest that could be run before the parted to refresh the storage?
For the other suggestion we don't have expertise to remove LPAR assigned storage from novalink.

Can be connected with https://progress.opensuse.org/issues/157447 ?
If you need a new ticket instead of reopening this one, please let us know.

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_reinstall
https://openqa.suse.de/tests/14373678#step/bootloader_start/1

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

I also saw such behavior on several Linux systems. From the configuration point of view I can only tell you that all disks are equally created once and live in some virtualization layer ("PowerVM") managed by either NovaLink or the HMC/VIOS. It would surprise me if the management makes any difference but might be worth a try.

leli wrote in #note-11:

All failed case has the parted issue, on grenache-1:2 grenache-1:4, while passed job without the parted issue on other workers(Strange is that I found one passed job on 1:4 also)

This brings me back to my first sentence; it might be just a case of random access to that disk. I don't see much done between the wipefs call and parted except a single sync which does not really ensure the kernel is not still using any previous references to the partition table.
Fully recreating the disk in NovaLink or the HMC might be equally overkill as a reboot of the testcase itself because it usually takes some time to process and is prone to produce errors.

We could however introduce another disk to these systems to they could switch to the other disk in case this (sporadic) issue is encountered. But I'm not sure if this is really worth the effort to implement?

Looking at https://openqa.suse.de/tests/14373678#step/bootloader_start/39; the partitions are mounted before the wipefs call. Of course the system is complaining about deleting mounted partitions. Wouldn't the solution here be just unmount them first before wipe and sync?