SRU of mdadm to Focal

Bug #1890248 reported by Mariusz Tkaczyk
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mdadm (Ubuntu)
Fix Released

Bug Description

Please update mdadm package for focal to latest upstream.
mdadm-4.2 in on way but no release date was committed yet.

Upstream contains a lot of various fixes for problems with specific hardware or system configuration.
Also there are some fixes for sporadic bugs related with metadata updater (mdmon).
I will notify if mdadm 4.2 will become available.

tags: added: vrco
tags: added: vroc
removed: vrco
Revision history for this message
Mariusz Tkaczyk (mtkaczyk) wrote :

mdadm-4.2 not released yet.
Feel free to close it if not applicable.

Revision history for this message
Mariusz Tkaczyk (mtkaczyk) wrote :

mdadm-4.2-rc-1 has been released officially.
Could you update the mdadm version?

Revision history for this message
Stéphane Verdy (sverdy) wrote :

mdadm-4.2-rc1 has been published in Impish. However, now that mdadm-4.2-rc2 has just been released and packaged in Debian, would it be possible to update it in Impish?

tags: added: ls-ii-incoming
Revision history for this message
Jeff Lane  (bladernr) wrote :

Just an update, rc2 is in -proposed for impish

Jeff Lane  (bladernr)
Changed in mdadm (Ubuntu):
status: New → Confirmed
Graham Inggs (ginggs)
tags: added: rls-ii-incoming
removed: ls-ii-incoming
Changed in mdadm (Ubuntu):
status: Confirmed → Fix Released
summary: - update mdadm for focal
+ SRU of mdadm to Focal
tags: added: fr-1705
Revision history for this message
Graham Inggs (ginggs) wrote :

Although we probably want to wait until the 4.2 release before going ahead with this, I've prepared a backport of 4.2~rc2-2ubuntu1 from impish to focal in a PPA:

Revision history for this message
Graham Inggs (ginggs) wrote (last edit ):

In the debdiff, I included only the packaging changes and filtered out the changelog and translations, etc. (filterdiff -i '*/debian/*' -x '*/debian/changelog' -x '*/debian/copyright' -x '*/debian/po/*' -x '*/debian/FAQ').

In addition, I removed the diff of all the patches that were dropped due to being included upstream, i.e.


Revision history for this message
Graham Inggs (ginggs) wrote :
Revision history for this message
Graham Inggs (ginggs) wrote :

Subscribing ~ubuntu-sru for comment.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

With my SRU hat on: it's always a bit of a tricky situation whether we accept a completely new upstream version backport for a stable LTS series. In case of mdadm it's especially tricky, considering that 4.1 has been tagged (released) 3 years ago, meaning 4.2 has 3+ years of changes bundled up. And that always carries risks of regressing many users.

Per the SRU policy [1], generally we allow new upstream microreleases into stable series which carry changes fitting SRU criteria if the upstream project has:
 * a reliable and credible test suite for assuring the quality of every commit or release,
 * the tests are covering both functionality and API/ABI stability,
 * the tests run during package build to cover all architectures,
 * the package has an autopkgtest to run the tests in an Ubuntu environment against the actual binary packages

So these are the general policy guidelines. We can of course evaluate every project case-by-case, and not all of these points need to be strictly true (it would be hypocrisy to say we STRICTLY require that, as there are exceptions that we approved). But in general the idea is: we need to make sure that the upstream project has sufficiently strong testing story to make sure a minimal number of users can be potentially affected by any ABI/API breakages and/or general regressions.

I would appreciate some help in getting a better understanding of the mdadm situation with this in mind. Things I'd like to know:
 1) I see that mdadm runs its tests/ as autopkgtests. How thorough are those tests? How often are new test cases added by upstream?
 2) How many autopkgtests of other packages are triggered when mdadm is uploaded?
 3) What are the bugfixes (and possibly also new features) that are added between 4.1 and 4.2?
 4) Besides the merit of having many different bugfixes from 4.2, is there a legitimate reason why we want to have mdadm 4.2 in focal? Is there a particular bugfix/feature we need that would otherwise be a pain to cherry-pick? (this is not particularly a requirement, but will help in decision making)



Revision history for this message
Mariusz Tkaczyk (mtkaczyk) wrote (last edit ):

mdadm supports set of different metadata. Intel metadata is a part of it (called IMSM). We (as Intel) are submitted a lot of fixes and features, all are validated and tested. Beside upstream testing, we have our internal test scope, focused on IMSM aspects. I can say with certainty that upstream test form IMSM are working and are used daily.
But there are more metadata types. They are not maintained as IMSM is. There was recent topic on mailing list about problem with tests:
https://<email address hidden>/T/#t

Seems that some tests could be invalid. New test are not added frequently. I'm not aware of CI testing done by the maintainer. For that reason, I have to say that mdadm doesn't meet SRU criteria.

So, according to your questions:
1 - there are some test added a lot time ago and they are not updated frequently. They covers usecases mainly. New test are added rarely.
2- I don't know, but I think that it doesn't matter since it is tending to be rejected.
3- We (and community) submitted many bugfixes for many different problems. There are small improvements, there are fixes for potential DC too. Unfortunately, maintainer doesn't list features in announce file:

4- We submitted many fixes and features for IMSM, all are validated, but as I wrote below- we are only a part of product.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Thank you Mariusz for the explanation. There is a few 'red/yellow flags' here right now, but we can continue the discussion. I mean, some bits we could work-around - like, the lack of a good test automation story - this for instance could be still accepted taking into consideration your (Intel's) testing. Since the only thing we want to accomplish with this requirement is reducing the risk of regressions for existing users, and any thorough testing might be already an acceptable criteria here.

But then I think the remaining requirements for getting this in would be: trying to formulate a legitimate reason (rationale) for bumping mdadm to 4.2 in focal and a list of changes (or at least new features) added between 4.1 and 4.2. If we can get these in order + maybe get some insight into what exact testing you, at Intel, perform on mdadm, we can get the new version into focal-updates.

I assume the most difficult would be the list of feature changes. This is a requirement as we need to know in advance if there's any changes that could potentially break existing users and for us to request additional targeted testing. Maybe we could figure something out here?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.