| Summary: | imsm raid1 resync after each reboot | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Groß <fedora> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | gansalmon, itamar, jamjon3, johann.fot, jonathan, kernel-maint, madhu.chinakonda, naveed, ncjeffgus, pb | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-06-07 11:35:32 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
I got the same problem. Intel fakeraid 1 + reboot => new resync. PS: If it is of importance, the system is encrypted. (This whole issue wasnt an issue in F14. Hardware and raid settings havent changed since F11.) Even after tabula rasa the issue persists. Steps: 1. Format both drives 2. Disassemble the raid1 3. Reassemble 4. Fresh install of Fedora 15 5. Update all Packages 6. reboot 7. Wait for resync to complete 8. reboot 9. raid1 is resyncing AGAIN (and again and again...) I'm just confirming that I have the same problem. I've been suffering with it for a few weeks now but hadn't seen any postings until this one that pinpoints what's _actually_ going on. The problem still persists with kernel version 2.6.40.4-5.fc15.x86_64. This problems hit's me too, everytime the resync starts at 0% while I believe to see a message during reboot that raid sync state is saved. Just note that the resync also starts with kernel 2.6.40.4-5 if the RAID was reported as Normal from the BIOS, very strange. So it simply ignores the previous sync state totally. I'm currently using mdadm-3.1.5-2, because newer are broken regarding imsm (see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=736387) BTW: how is triggering the resync? The mdadm program or the kernel code itself? Can this somehow debugged, e.g. by a kernel boot option? "dmesg | grep md:" only shows "resync of RAID array...", but no reason and also nothing about the option ROM. Is this still happening with the 2.6.43/3.3 kernel? Didn't happen with the latest kernels on F16. Now i'm already using F17, no resync after reboot. Seems to be fixed. Thanks for letting us know. I have still the issue on latest F17 kernel from updates, so it's not fixed for my case. See also related https://bugzilla.redhat.com/show_bug.cgi?id=753335, which is still open. (In reply to comment #10) > I have still the issue on latest F17 kernel from updates, so it's not fixed > for my case. See also related > https://bugzilla.redhat.com/show_bug.cgi?id=753335, which is still open. Then F17 can track it there. F15 is going EOL. |
Created attachment 512390 [details] Dmesg showing rebuild start. Description of problem: I have an board with Intel fakeraid. Fedora correctly detects the raid1 configured in the BIOS. The raid builds fine once Fedora is running. But after each reboot the raid is detected as not clean an a rebuild is started How reproducible: always Steps to Reproduce: 1. configure fakeraid in BIOS 2. let the array finish building while system is running 3. reboot system Additional info: Perhaps the Problem is caused because some filesystems are not correctly unmounted? From /var/log/messages: Jul 12 12:12:16 fnop kernel: [76208.375962] umount[450]: umount: /tmp: device is busy. Jul 12 12:12:16 fnop kernel: [76208.375972] umount[450]: (In some cases useful info about processes that use Jul 12 12:12:16 fnop kernel: [76208.375979] umount[450]: the device is found by lsof(8) or fuser(1)) Jul 12 12:12:16 fnop kernel: [76208.397105] umount[452]: umount: /home: device is busy. Jul 12 12:12:16 fnop kernel: [76208.397115] umount[452]: (In some cases useful info about processes that use Jul 12 12:12:16 fnop kernel: [76208.397122] umount[452]: the device is found by lsof(8) or fuser(1)) Jul 12 12:12:16 fnop kernel: [76208.408357] umount[455]: umount: /var/lib/nfs/rpc_pipefs: device is busy. Jul 12 12:12:16 fnop kernel: [76208.408367] umount[455]: (In some cases useful info about processes that use Jul 12 12:12:16 fnop kernel: [76208.408374] umount[455]: the device is found by lsof(8) or fuser(1)) Jul 12 12:12:16 fnop ntpd[1016]: ntpd exiting on signal 15 Jul 12 12:12:16 fnop acpid: exiting Jul 12 12:12:16 fnop kernel: Kernel logging (proc) stopped.