Bug 1813623 - mdadm-4.1-4.fc31.x86_64: raid check no longer enabled after update
Summary: mdadm-4.1-4.fc31.x86_64: raid check no longer enabled after update
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: XiaoNi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-14 21:16 UTC by Harald Reindl
Modified: 2021-05-25 15:47 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-25 15:47:16 UTC
Type: Bug


Attachments (Terms of Use)

Description Harald Reindl 2020-03-14 21:16:11 UTC
seriosuly? you drop the cron snippet and don#t enbale the timer in the middle of a stable release?

------------------

mdadm-4.1-4.fc31.x86_64

warning: /etc/cron.d/raid-check saved as /etc/cron.d/raid-check.rpmsave

[root@testserver:~]$ systemctl status raid-check.timer
● raid-check.timer - Weekly RAID setup health check
   Loaded: loaded (/usr/lib/systemd/system/raid-check.timer; disabled; vendor preset: disabled)
   Active: inactive (dead)

Comment 1 XiaoNi 2020-03-16 09:41:20 UTC
It's replaced by systemd timer.

commit 8491dee0428b45db4cabf3ddee8bb5b9c6e18f83
Author: Alejandro Domínguez <adomu@net-c.com>
Date:   Sun Feb 9 08:35:31 2020 +0100

    Replace raid-check cron job with systemd timer


--- a/mdadm.spec
+++ b/mdadm.spec
@@ -1,7 +1,7 @@
 Name:        mdadm
 Version:     4.1
 #define subversion rc2
-Release:     2%{?subversion:.%{subversion}}%{?dist}
+Release:     3%{?subversion:.%{subversion}}%{?dist}

Comment 2 Harald Reindl 2020-03-16 09:49:55 UTC
> It's replaced by systemd timer

tell me something new when i showed the *disabled* timer state in the initial report after the update and while i am smart enough to understand dnf messages  i doubt that a majority of users are even facing them and don#t expect their raid-chek siltently disabled with a *random* update

* that idiotic update deletes /etc/cron.d/raid-check
* that idiotic update don't enable raid-check.timer
* this is unacceptable behavior in the middle of a sable release

Comment 3 XiaoNi 2020-03-16 14:10:42 UTC
(In reply to Harald Reindl from comment #2)
> > It's replaced by systemd timer
> 
> tell me something new when i showed the *disabled* timer state in the
> initial report after the update and while i am smart enough to understand
> dnf messages  i doubt that a majority of users are even facing them and
> don#t expect their raid-chek siltently disabled with a *random* update
> 
> * that idiotic update deletes /etc/cron.d/raid-check
> * that idiotic update don't enable raid-check.timer
> * this is unacceptable behavior in the middle of a sable release

I agree with your thought but I'm not agree with your words. Everyone can make
faults. 

For this problem, now it already was replaced with systemd service. If we enable
raid-check.timer properly, it doesn't need cron raid-check any more, right?

Comment 4 Harald Reindl 2020-03-16 14:14:02 UTC
the tone was because of the "It's replaced by systemd timer" response when my initial report shows that i am not an idiot and quoted the DISABLED state of the timer before i enabled it MANUALLY on my system

and you should simply NOT do such changes randomly on stable releases, NOW keep it please for that case but fix it for others not realizing that they need to do manual actions for random point updates

Comment 5 XiaoNi 2020-03-16 14:35:13 UTC
(In reply to Harald Reindl from comment #4)
> the tone was because of the "It's replaced by systemd timer" response when
> my initial report shows that i am not an idiot and quoted the DISABLED state
> of the timer before i enabled it MANUALLY on my system
> 
> and you should simply NOT do such changes randomly on stable releases, NOW
> keep it please for that case but fix it for others not realizing that they
> need to do manual actions for random point updates

In fact it's not my patch, you can see it in comment1. 

And yes. We should fix this problem. It needs to find a better solution. I think it's
not a good idea that cron raid-check and systemd raid-check exist at the same time. So
we need to choose one.

What's the meaning of "keep it please for that case"? You mean keep systemd raid-check, right?

Comment 6 Harald Reindl 2020-03-16 14:40:27 UTC
> I think it's not a good idea that cron raid-check and systemd raid-check exist at the same time

don't get me wrong but you don't understand anything of this bugreport giving that "warning: /etc/cron.d/raid-check saved as /etc/cron.d/raid-check.rpmsave" clearly *removes* cron raid-check (saved as rpmsave means that a user modified confignoreplace file was *removed*)

"keep it please for that case" means that i expect not to have this dance back and forth, now that i have manually enabled it and adjusted the time in a drop-in, it's in updates-testing and just replace it by a update which *enables* raid-check.timer in a post-script

Comment 7 Robert Scheck 2020-03-23 00:34:58 UTC
Dear package maintainer, it may makes sense to review and follow https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_how_to_enable_a_service_by_default in order to enable your timer by default.

Comment 8 XiaoNi 2020-03-26 12:49:48 UTC
I filed a new bug for the problem https://bugzilla.redhat.com/show_bug.cgi?id=1817491

Comment 9 Ben Cotton 2020-11-03 16:29:09 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Harald Reindl 2020-11-03 19:13:25 UTC
amazing that nobody cares about the outcome of his changes
guess how many ordinary users realize the problem until it's too late

Comment 11 Robert Scheck 2020-11-03 23:59:19 UTC
Dear package maintainer, are you still caring about your package? I've filed https://src.fedoraproject.org/rpms/fedora-release/pull-request/158 now to get this hopefully finally addressed...but normally this would have been your turn for 7+ months...

Comment 12 XiaoNi 2020-11-12 08:15:39 UTC
Hi Robert

Can https://bugzilla.redhat.com/show_bug.cgi?id=1817491 fix your problem. There is a same
pull request in this bug.

Comment 13 XiaoNi 2020-11-12 08:34:26 UTC
I installed a f32 and 90-default.preset doesn't enable raid-check. 
@Stephen, could you help to check? Does bug 1817491 really be fixed?

Thanks
Xiao

Comment 14 Stephen Gallagher 2020-11-12 16:45:04 UTC
(In reply to XiaoNi from comment #13)
> I installed a f32 and 90-default.preset doesn't enable raid-check. 
> @Stephen, could you help to check? Does bug 1817491 really be fixed?
> 
> Thanks
> Xiao

You never specified that it needed to be applied to Fedora 32. This change was made for Fedora 33+.

Comment 15 XiaoNi 2020-11-12 23:26:00 UTC
(In reply to Stephen Gallagher from comment #14)
> (In reply to XiaoNi from comment #13)
> > I installed a f32 and 90-default.preset doesn't enable raid-check. 
> > @Stephen, could you help to check? Does bug 1817491 really be fixed?
> > 
> > Thanks
> > Xiao
> 
> You never specified that it needed to be applied to Fedora 32. This change
> was made for Fedora 33+.

https://bugzilla.redhat.com/show_bug.cgi?id=1817491#c4 specified the version(f31/f32/rawhide).
Is it ok to fix this in f32/f31 now?

Comment 16 Fedora Program Management 2021-04-29 16:14:27 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 17 Ben Cotton 2021-05-25 15:47:16 UTC
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.