Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
libstorage-ng and YaST used to lack support for the RAID level "linear". That leaded to errors during probing in a system with such RAIDs. See bsc#1215022.
To fix the problem, support for a new
MdLevel::LINEAR
was added to libstorage-ng. But yast2-storage-ng needs the corresponding adaptations to the new MD level.To be precise, we want YaST to stop failing in presence of such a RAID, but we don't want to add support to create new ones.
Solution
This targets SLE-15-SP4, only as a fix for the reported bug.
Adds the code needed to recognize the new level added to libstorage-ng, so probing works and the RAIDs are properly represented (eg. in the Expert Partitioner).
This also adds basic handling at AutoYaST. Basically preventing the
<raid_level>
to be cloned as "linear". If a linear RAID is detected in the system it will be exported with an unknown RAID level. That's a first step (the solution will be refined in subsequent versions) to clearly state that such a RAID level is not supported by (Auto)YaST.Testing
Tested manually with a patched SLE-15-SP4