QA » openQA Project » openQA Tests

can this be as simple as

$ openqa_clone_job_osd 467621 UEFI=1 MACHINE=uefi
Cloning dependencies of sle-12-SP2-Server-DVD-x86_64-Build1903-RAID1@64bit
Created job #468285: sle-12-SP2-Server-DVD-x86_64-Build1903-RAID0@64bit
Created job #468286: sle-12-SP2-Server-DVD-x86_64-Build1903-RAID1@64bit

what I just did so let's wait for https://openqa.suse.de/tests/468286

Added relation to fate entry.

Feature is not ready, tested manually. Automated test is on the way.

referring to #11434#note-10 shows that t#468286 passed but the boot partition does not end up on RAID. The test module "partitioning_raid" needs to be adapted to put boot on raid and then check in the installed system that e.g. the first disk can be removed and the system is capable of booting, still, e.g. by chaining tests.

Dumitru, I added a question to Fate. What exactly is your problem? It seems that nobody understood/answered the question? I still see that ticket as urgent for SP3.

@dgutu please update the ticket with current state. I suggest to add acceptance criteria to this ticket in the description so that we can more easily check when it is done.

okurz wrote:

please stick to https://progress.opensuse.org/projects/openqatests/wiki#Definition-of-DONE especially "At least one successful test run has been observed on osd or o3 and referenced in the corresponding progress item or bugzilla bug report if one exists"

Right now we have general problem with aarch64 jobs so no finished job is still available.
Will update the issue with corresponding job when available.

We are bit in conflict :) see https://progress.opensuse.org/issues/18444

According to EFI spec the ESP can be stored on raw GPT+FAT only.

It may depends on used uefi fw - some users using gigabit and asus MB reports that they can use ESP stored on RAID1. But not possible ATM on qemu efi fw.

• it goes against https://fate.suse.com/322485

@thehejik you can not simply declare this ticket as invalid as long as the fate issue exists. Also, keep in mind that it is not about hardware raid (support by mainboard) but software raid. Feel free to comment in the fate entry though. I myself don't see a problem creating a software raid within the system although the firmware just sees two disks which just happen to have the same boot code installed.

@dgutu what do you mean "Nothing to be done from my side right now"? The last comments state that something has been working and we just need "verification runs".

okurz wrote:

@thehejik you can not simply declare this ticket as invalid as long as the fate issue exists. Also, keep in mind that it is not about hardware raid (support by mainboard) but software raid. Feel free to comment in the fate entry though.

Since EFI firmware shipped with qemu doesn't support ESP stored on MDRAID array (ESP - EFI system partition - /boot/efi) it gives no sense to test it in openQA. MDRAID ESP must be supported by EFI vendor (users on forums says that ASUS and Gigabyte supports that).

I myself don't see a problem creating a software raid within the system although the firmware just sees two disks which just happen to have the same boot code installed.

It is not just about two disks with the same content in mirror. There is a special mdraid superblock for each raid member/drive in the array and qemu EFI fw doesn't know how to handle with that.

@dgutu what do you mean "Nothing to be done from my side right now"? The last comments state that something has been working and we just need "verification runs".

@okurz: The software raid needs to be mounted be the early running UEFI. As long as the QEMU EFI is not capable of mounting mdraids we cannot further progress here because "no one" is able to mount the raid that early on.

I've updated https://fate.suse.com/314829 about the firmware "issue" we have here. There is already a discussion about the header version which can maybe mitigate our problem if we just can tell the bootloader to treat the raid as normal partition.

thank you so much. Would you mind taking the ticket, setting it to feedback, adding yourself as QA tester role to the fate issue and just track the discussion there?

No update on the fate yet since my last explanation of what QA needs for automated testing.

okurz wrote:

So blocked by bsc#924487, please review again at M10 review

Hm, IMHO this is not our blocker. Our blocker is that the QEMU firmware does not support mdadm raids and it's still not decided which header format they use if this feature gets implemented.

@okurz: I'm confused now. The ticket is linked to the fate but in my understanding barely touches the real issue here. So technically speaking bsc#924487 blocks us - yes.

However, still no reaction on the fate entry. Is there someone we can poke about this or is this feature just not important enough?

I suggest that you test the whole thing again as soon as we have a more or less complete "storage-ng" within openSUSE Tumbleweed and/or SLE 15 and comment about results in the fate entry and the bug as even if it works for any of these products one might want to provide hints or fixes (e.g. in form of DUD) for older versions or ensure that at least 12 SP4 gets it as well. As the fate entry is marked as "Validation" I think people will assume the feature is complete and working unless proven otherwise.

Duration: 419
Moved from milestone to a milestone.

Is this really workable?

@okurz: what are the exit criteria for this one?
@okurz: is this a new test to be added or update to an existing one?

sebchlad wrote:

Duration: 419
Moved from milestone to a milestone.

Yes, because the feature was supposed to be done before QA starts testing but it never was for any SLE12 SP. Another example of where we should revisit the development workflow and how QA is involved.

Is this really workable?

Not regarding development but as a "feature tracker" ticket it is: We have to track when the feature is done and then we can think about automating

@okurz: what are the exit criteria for this one?

same as for all fate feature tracker items as described in https://progress.opensuse.org/projects/suseqa/wiki#feature-tests-Fate-requests that is mainly

1) a comment on the Fate issue about the result exists, e.g. link to passing openQA test for feature (automatic) or link to Testopia test case (manual)

@okurz: is this a new test to be added or update to an existing one?

Not easy to answer that question because I don't know your definition of "test" here. Strictly speaking every new fate issue needs a new test case so then the answer would be "yes". But of course in most if not all cases we have some tests existing which are usable as a starting base. In the best case only slight adaption of existing openQA test modules need to be done to cover this "new test". In the case of this feature here I actually assume that the biggest missing chunk is an actual automated test of booting a degraded RAID which we don't have even for non-UEFI.

The feature is not there for SLE15 bug: https://bugzilla.suse.com/show_bug.cgi?id=1081578

The feature is also not working for SLE12-SP4: The installer doesn't detect the efi boot partition from a RAID volume.

The feature is also not working for SLE12-SP3: The installer doesn't detect the efi boot partition from a RAID volume.