Project

General

Profile

action #11434

[sle][functional][fate#314829][fate:validation][medium] Support for UEFI boot partition on sw raid (raid 1)

Added by maritawerner almost 6 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Category:
New test
Start date:
2016-04-01
Due date:
2018-02-27
% Done:

100%

Estimated time:
Difficulty:

Description

For details see https://fate.suse.com/314829

Situation

Currently, SLES support installation with root on raid (software raid 1), however this is limited for UEFI machines, where it seems very reasonable to have also "/boot/efi" on raid 1, thus preventing issues when disk on which "/boot/efi" currently resides fails. In order to work properly, this setup also needs creation of multiple entries in UEFI (using efibootmgr), thich would point to disks of which such raid device is created.

Acceptance criteria

  • AC1: A manual test has been conducted for SLE 15 as well as SLE 12 SP4 showing if a system with a UEFI boot partition on RAID is bootable or not

Tasks

  • Manually test with a current build of SLE15 (including storage-ng) if a system is bootable from a degraded RAID with /boot/efi on RAID
  • Do the same test for SLE12 SP4
  • Update the bug report in bsc#924487
  • If possible automate the test

History

#1 Updated by dgutu almost 6 years ago

  • Assignee set to dgutu

#2 Updated by RBrownSUSE almost 6 years ago

  • Target version set to 168

#3 Updated by dgutu almost 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

@Marita, I was checking the fate, the state for this is marked as 'Ready' and I think
we already covered something similar to fate description, we are running 5-6 tests
with different raid configs with UEFI in place.
https://openqa.suse.de/tests/346088/modules/partitioning_raid/steps/34
Do I need to test this strictly as per description?

Thx.

#4 Updated by dgutu almost 6 years ago

  • Status changed from In Progress to Feedback
  • Assignee changed from dgutu to maritawerner

#5 Updated by okurz over 5 years ago

  • Target version changed from 168 to Milestone 3

#6 Updated by maritawerner over 5 years ago

  • Status changed from Feedback to In Progress
  • Assignee changed from maritawerner to dgutu

Hello Dumitru, sorry I can not say if the testcase you added does cover that feature but in the suggested Testcase there are mentioned 4 disks, so I would like to follow that Testcase and get it implemented like that. BTW the Feature is set to Validation now.

#7 Updated by dgutu over 5 years ago

  • Status changed from In Progress to Resolved

#8 Updated by dgutu over 5 years ago

  • Status changed from Resolved to In Progress

#9 Updated by RBrownSUSE over 5 years ago

  • Priority changed from Normal to Urgent

#10 Updated by okurz over 5 years ago

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.

#11 Updated by okurz over 5 years ago

  • Subject changed from Feature 314829: Support for UEFI boot partition on sw raid (raid 1) Page_white_edit Edit title to Feature 314829: Support for UEFI boot partition on sw raid (raid 1)

#12 Updated by dgutu over 5 years ago

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

#13 Updated by okurz over 5 years ago

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.

#14 Updated by okurz about 5 years ago

  • Category set to New test

#15 Updated by maritawerner about 5 years ago

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.

#16 Updated by maritawerner about 5 years ago

  • Priority changed from Urgent to High

#17 Updated by maritawerner about 5 years ago

  • Target version deleted (Milestone 3)

#18 Updated by dgutu about 5 years ago

  • Status changed from In Progress to Feedback

#19 Updated by dgutu about 5 years ago

  • Status changed from Feedback to In Progress

#20 Updated by okurz about 5 years ago

  • Target version set to Milestone 5

#21 Updated by okurz almost 5 years ago

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.

#23 Updated by okurz almost 5 years ago

  • Target version changed from Milestone 5 to Milestone 6

#24 Updated by dgutu almost 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 70 to 100

PR was merged.

#25 Updated by okurz almost 5 years ago

  • Status changed from Resolved to In Progress

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"

#26 Updated by dgutu almost 5 years ago

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.

#27 Updated by okurz almost 5 years ago

  • Subject changed from Feature 314829: Support for UEFI boot partition on sw raid (raid 1) to [sles][functional]Feature 314829: Support for UEFI boot partition on sw raid (raid 1)

#28 Updated by thehejik almost 5 years ago

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.

#29 Updated by thehejik almost 5 years ago

#30 Updated by dgutu almost 5 years ago

  • Assignee deleted (dgutu)

Nothing to be done from my side right now, unassigning the task.

#31 Updated by okurz almost 5 years ago

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".

#32 Updated by okurz almost 5 years ago

  • Subject changed from [sles][functional]Feature 314829: Support for UEFI boot partition on sw raid (raid 1) to [sles][functional]Feature 314829: Support for UEFI boot partition on sw raid (raid 1)
  • Target version changed from Milestone 6 to Milestone 7

thehejik: I would appreciate your answer

#33 Updated by thehejik over 4 years ago

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".

#34 Updated by okurz over 4 years ago

  • Target version changed from Milestone 7 to Milestone 8

I really don't understand the issue enough but I think we should be able to at least find a common understanding within M8

#35 Updated by nicksinger over 4 years ago

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.

#36 Updated by nicksinger over 4 years ago

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.

#37 Updated by okurz over 4 years ago

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?

#38 Updated by nicksinger over 4 years ago

  • Assignee set to nicksinger

#39 Updated by nicksinger over 4 years ago

  • Status changed from In Progress to Feedback

#40 Updated by nicksinger over 4 years ago

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

#41 Updated by okurz over 4 years ago

  • Target version changed from Milestone 8 to Milestone 9

waiting for feedback, revisit the latest M9 review

#42 Updated by nicksinger over 4 years ago

  • Priority changed from High to Normal

okurz wrote:

waiting for feedback, revisit the latest M9 review

Thanks for the update @okurz. A little bit more context:
It seems that the attached bsc ticket has no priority at all. Even if we get this feature in general we would still depend on either the right header structure (which is unlikely) or support in the qemu firmware/EFI (also unlikely to happen soon(ish)). So most likely this is going to be a feature we have to test manually if it gets implemented. M9 was agreed on in the call, to revisit the ticket again and check if anything changed.

#43 Updated by okurz over 4 years ago

  • Target version changed from Milestone 9 to Milestone 10

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

#44 Updated by nicksinger over 4 years ago

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.

#45 Updated by nicksinger over 4 years ago

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?

#46 Updated by okurz over 4 years ago

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.

#47 Updated by okurz over 4 years ago

  • Status changed from Feedback to In Progress
  • Target version changed from Milestone 10 to Milestone 11

after storage-ng is now in a better state in SLE15 please retest with latest snapshot and see if the installer allows the thing at all or if you are lead into a death trap :)

Based on the observations you should consider the impact on SLE12.

#48 Updated by okurz over 4 years ago

  • Due date set to 2017-10-25

#49 Updated by okurz over 4 years ago

  • Due date changed from 2017-10-25 to 2017-11-08

#50 Updated by sebchlad over 4 years ago

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?

#51 Updated by okurz over 4 years ago

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.

#52 Updated by okurz over 4 years ago

  • Due date deleted (2017-11-08)
  • Assignee changed from nicksinger to sebchlad
  • Target version changed from Milestone 11 to Milestone 12

To be discussed with PO to make it workable first, e.g. what are our expectations

#53 Updated by okurz about 4 years ago

  • Subject changed from [sles][functional]Feature 314829: Support for UEFI boot partition on sw raid (raid 1) to [sle][functional][fate#314829][fate:validation][medium] Support for UEFI boot partition on sw raid (raid 1)
  • Description updated (diff)
  • Due date set to 2018-02-27
  • Status changed from In Progress to Workable
  • Assignee deleted (sebchlad)
  • Target version changed from Milestone 12 to Milestone 14

Added AC, added tasks, clarified what do do.

#54 Updated by SLindoMansilla almost 4 years ago

  • Assignee set to SLindoMansilla

#55 Updated by SLindoMansilla almost 4 years ago

  • Status changed from Workable to In Progress

#56 Updated by SLindoMansilla almost 4 years ago

  • Status changed from In Progress to Blocked

Blocked by bug on EFI partition: https://bugzilla.suse.com/show_bug.cgi?id=1078707

SR was declined because the build failed: https://build.suse.de/request/show/155005

#57 Updated by SLindoMansilla almost 4 years ago

  • Status changed from Blocked to In Progress

#58 Updated by SLindoMansilla almost 4 years ago

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

#59 Updated by SLindoMansilla almost 4 years ago

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

#60 Updated by SLindoMansilla almost 4 years ago

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

#61 Updated by SLindoMansilla almost 4 years ago

  • Status changed from In Progress to Resolved

The feature is working for SLE12-SP2. (fate updated)

Regression for higher versions.
Bug already created for SLE12-SP3, SLE12-SP4 and SLE15: https://bugzilla.suse.com/show_bug.cgi?id=1081578

Nothing more to do here.

Also available in: Atom PDF