Bug 732297 - raid background reconstruction after every full bootup
Summary: raid background reconstruction after every full bootup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-21 18:30 UTC by Damjan
Modified: 2012-12-20 15:42 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-20 15:42:04 UTC


Attachments (Terms of Use)
full dmesg output (73.53 KB, text/plain)
2011-08-21 18:30 UTC, Damjan
no flags Details

Description Damjan 2011-08-21 18:30:10 UTC
Created attachment 519198 [details]
full dmesg output

Description of problem:
I use onboard RAID 1 (intel ICH9R) which used to work fine on previous versions of Fedora. Now on every bootup the raid array gets auto resynced. This is very annoying at best and I do believe it will shorten my drives' life. There is no hardware error reported and the background reconstruction finishes fine. The only way to avoid it is to put the workstation in sleep mode - avoiding reboot.

Version-Release number of selected component (if applicable):
mdadm-3.2.2-6.fc15.x86_64
dracut-009-12.fc15.noarch

How reproducible:
Every time system boots F15.

Steps to Reproduce:
1. shutdown
2. power up and select F15
or just reboot.
  
Actual results:
Resync of the raid 1 array.

Expected results:
Array stays normal - no rebuild required.

Additional info:
(from dmesg)
[    3.462629] dracut: Autoassembling MD Raid
[    3.470681] md: md127 stopped.
[    3.472500] md: bind<sda>
[    3.472584] md: bind<sdb>
[    3.473141] dracut: mdadm: Container /dev/md127 has been assembled with 2 drives
[    3.477324] md: md126 stopped.
[    3.477512] md: bind<sdb>
[    3.477634] md: bind<sda>
[    3.479392] md: raid1 personality registered for level 1
[    3.479521] bio: create slab <bio-1> at 1
[    3.481195] md/raid1:md126: not clean -- starting background reconstruction
[    3.481198] md/raid1:md126: active with 2 out of 2 mirrors
[    3.481217] md126: detected capacity change from 0 to 1000202043392
[    3.483908]  md126: p1 p2 p3

Comment 1 Doug Ledford 2011-09-01 17:26:40 UTC
This is most likely a systemd issue.  Initscripts used to make sure on reboot that we umounted everything, mounted root read only, then ran mdadm --wait-clean --scan, then rebooted.  My guess is that systemd is not performing this vital series of steps.  These steps are responsible for the raid array being marked clean, without them you will have a rebuild on every reboot.

Comment 2 Damjan 2011-09-05 06:36:48 UTC
Is it possible to manually add that command to an existing/new systemd script?

It also happens that I cannot shut down/reboot the machine as it stalls on "unmount".

Now that I'm using hybernate to "stop" the PC, I've found out that after waking up from hybernate a new gnome-shell starts for the same session. These processes keep piling up and I have to manually kill them to release the CPU and memory resources.

Comment 3 Michal Schmidt 2011-09-08 15:08:43 UTC
(In reply to comment #1)
> This is most likely a systemd issue.  Initscripts used to make sure on reboot
> that we umounted everything, mounted root read only, then ran mdadm
> --wait-clean --scan, then rebooted.

Is this specific to RAID with external metadata?
Looks related to bug 713224.

Comment 4 Doug Ledford 2011-09-09 00:42:44 UTC
Yes, it is specific to external metadata.  The --wait-clean --scan option to mdadm tells it to wait for all existing external imsm arrays to be marked clean by the (should be still running) mdmon processes.  Once it reads that the array is clean from the on disk superblock of all imsm arrays, it exits and the reboot process can complete.

Comment 5 Fedora Admin XMLRPC Client 2011-10-20 16:28:58 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Damjan 2011-11-09 14:28:25 UTC
Has this issue been resolved yet? I keep updating packages, but problems with rebuild remain.

Comment 7 Damjan 2011-12-13 13:41:02 UTC
I have had further problems with this issue, so I went for a different distro altogether. The one I use now also implemented systemd and Gnome 3.2. The one thing they have done differently is the persistent use of dmraid for "fake-raid" controllers.
I now believe there is an issue within the newer mdraid implementation that fedora uses. Is there a way to get the old dmraid back to Fedora 16?

Comment 8 Harald Hoyer 2012-01-24 10:23:47 UTC
(In reply to comment #7)
> Is there a way to get the old dmraid back to Fedora 16?

add "rd.md.imsm=0 rd.md.ddf=0" to the kernel command line

Comment 9 Harald Hoyer 2012-01-24 10:24:27 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Is there a way to get the old dmraid back to Fedora 16?
> 
> add "rd.md.imsm=0 rd.md.ddf=0" to the kernel command line

"rd.md.imsm=0 rd.md.ddf=0 rd.dm=1"

Comment 10 Joel Andres Granados 2012-04-15 00:00:00 UTC
Any workarounds for this? Comment 9 did not work for me.

Ppl might be interested in this thread: http://lists.freedesktop.org/archives/systemd-devel/2011-November/003734.html

Comment 11 Harald Hoyer 2012-06-07 10:43:39 UTC
will add "mdadm --wait-clean --scan" to the dracut shutdown

Comment 12 Harald Hoyer 2012-06-07 11:46:19 UTC
dracut has "mdadm -v --stop --scan" since dracut-011.

Is that not enough?

Do I have to do  "mdadm --wait-clean --scan" first?

Comment 13 Fedora Update System 2012-09-27 10:21:55 UTC
dracut-018-60.git20120927.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/dracut-018-60.git20120927.fc16

Comment 14 Fedora Update System 2012-09-27 10:23:06 UTC
dracut-018-105.git20120927.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dracut-018-105.git20120927.fc17

Comment 15 Fedora Update System 2012-09-28 08:20:09 UTC
Package dracut-018-105.git20120927.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-018-105.git20120927.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14953/dracut-018-105.git20120927.fc17
then log in and leave karma (feedback).

Comment 16 Fedora Update System 2012-12-20 15:42:08 UTC
dracut-018-60.git20120927.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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