** Changed in: mdadm (Fedora)
Status: Unknown => Fix Released
** Changed in: mdadm (Fedora)
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1320402
Title:
Hm, i used server 16.04.1 LTS with patch in the post #13 and additional upgrade
kernel to 4.7 or 4.8
NOTE: when using only mdadm.patch radi1 is resync always boot.
now i using newest kernel with raid1, all work fine.
Linux srv-design 4.8.0-040800-generic #201610022031 SMP Mon Oct 3 00:32:57
thank you for the script Martin Stjernholm. seems to be working,
although the unmounting doesn't seem to be done by the script if I
shutdown/reboot my pc - added a few logger-statements and i'm only
seeing the mount-messages in my logs. another neglectable problem is
that autologin doesn't work
#34 worked for me for all of about two weeks or so, then no more. I
suspect an update, but I couldn't find any update of any package that
seemed relevant.
I've now resorted to my first workaround in #8, i.e. to mount and
unmount the raid partitions separately from the ordinary boot and
shutdown
tried kernel 4.7.5 from mainline with mdadmpatch from #13 - no help.
still resyncing after every reboot/start
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1320402
Title:
mdadm resyncs imsm raid
With respect to #34, isn't the ubuntu 4.4.0 kernel meant to pick up
important security updates and fixes from the mainline 4.4.x stable
branch?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1320402
To me, this is highly critical. If you cannot use mdadm to manage RAID
on dual boot systems that need the imsm metadata (and obviously you
cannot if it means paying the price of constant resyncing) then you need
to resort to dmraid, which is very badly maintained and fails to
properly resync
see also https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1587142
mdadm with imsm metadata seems to be completely broken in ubuntu.
Having something as common as RAID1 on Intel boards broken is not very
nice.
Until this can be fixed, it would be good to at least add a very visible
warning
I have been affected by this bug. on 16.04.
I will either have to switch to a distribution that either has this fix
or will allow me to fix it myself, or cease Linux usage entirely until
the fix is backported to 16.04.
--
You received this bug notification because you are a member of Ubuntu
Since I upgraded to 16.04, the mdadm resync has started again. How do
these changes map to the new systemd configuration? What is the process
that systemd uses to start up mdadm? Will this change going forward to
16.10, etc.?
--
You received this bug notification because you are a member of
Roger, many thanks for finding that. At first it looked like it wouldn't
work for me, but it turns out that both kernel >= 4.4.2 AND the script
fixes in comment #13 are necessary.
I have also tested and found that both fixes in #13 are still required:
- /etc/init.d/mdadm: The mdmon pid is put
Confirmed. Kernel 4.4.2 or higher fixes this nasty, nasty life ruining
raid bug. Thank God, It's gone!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1320402
Title:
mdadm resyncs imsm raid in
I found this on the net after searching for "kernel 4.4 mdadm" (a page about
mdadm - follow first link):
"Kernel versions in series 4.1 through 4.4.1 have a broken RAID implementation.
Use a kernel with version at or above 4.4.2. "
I am using kernel 4.4.0-24 therefore I have broken raid.
Hope
Update results (using my fix):
Reboot with resync in progress= start where I left off (ex. 23%).
Reboot after full resync is done = go back to 0% and resync all 2TB all over
again.
Why is this bug not given importance or assigned to anyone?
It is destroying my life. That's all. I have work to do.
Small updateat the 23% sync mark I rebooted.
If my change failed then I'd go back to 0% like usual.
It didn't. I stayed at the 23% mark.
Partial confirmation the fix to /etc/init.d/sendsigs does work.
:-D
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Just a note for #12. Your change to sendsigs is broken, at least for mint 18.
The process mdmon will not be found.
It is actually /sbin/mdadm --monitor
I set OMITPIDS to OMITPIDS=`pidof /sbin/mdadm`
When using pidof the full path of the executable should be specified.
Your second sed
I have tried two different fixes for this (#12 and #13).
It won't stop.
At this point I can no longer use raid at all.
If my boot drive was raid 5 I'd be screwed as I could not turn it off at all.
I use raid 1 so I am lucky.
Can someone post a command to FORCE the raid to be clean?
Perhaps a
I am running Linux Mint 18 64bit with Cinnamon Desktop.
I never had this issue with mint 17 (ubuntu 14.04).
Mint 18 does it every single reboot.
I have implemented the fix from #12.
I have yet to test.
It takes 4hrs for my raid 1 mirror to resync.
I cannot live with this bug.
--
You received
I've had this problem since wily (15.10) - the workarounds in this
ticket stopped working then. It's still the same in xenial (upgraded
yesterday, so it's fresh).
Fwiw I can say it's still a problem at shutdown rather than startup: If
I reboot to Windows it's detected as unclean and a resync is
My playing with /rc0.d/rc6.d was unsuccessful, script not executed at
all. After some learning it turned out that Ubuntu 16.04 lts does not
use scripts from init.d/rcN.d at all, now there is systemd services
uses. I tried to create a service but it always executes before umount
or just not
It seems that the resync doesn't happen anymore when I reboot my 16.04
system. Maybe a recent update (last 2 weeks) fixed it. Does anybody else
still have the problem?
Also the mdadm-waitidle has the symlinks in /etc/rc0.d and /etc/rc6.d by
default - I didn't install them myself. Maybe the update
I'm also have bumped to "imsm raid always resync after boot" issue under
Ubuntu 16.04.lts.
I can see that the mdadm-waitidle scrip really does present into the
/etc/init.d/ but at the same time no any symbolic links to this script into the
etc/rcX.d dirs. I.e. by default this script never
I also had the exact same problem with Ubuntu 15.10 and Windows 10 dual-
boot setup and now that I upgraded to Ubuntu 16.04 LTS it is still there
unfortunately. Mdadm or the intel tool in windows will always try to
resync the array on each reboot.
--
You received this bug notification because
I am also experiencing this problem when dual booting with Windows 10
and Ubuntu 15.10 , which supposedly has the fix implemented in
/etc/init.d/mdadm-waitidle.
Whenever I reboot the system from one OS to another, even if the raid1
array appears to be in "normal" status in the bios POST, the
This problem just started happening for me too. I tried only the
changes in #13 but it still resyncs. Are the changes in 12 necessary as
well?
I tried the pidof command on its own and got this: "sed: -e expression
#2, char 9: unterminated `s' command"
Also ps ax|grep mdmon shows nothing, and
Patch on Comment #13 worked like a charm for me on 14.04.1 LTS. Syncs on
reboot stopped cold (after running to completion, of course) after the
patch was applied and system rebooted.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just being bitten by this now, this is a serious issue for mdadm root
filesystems on RAID1, if there were actual disk issues this could
completely destroy a system, the complete opposite of what RAID is
supposed to do!
Maintainers, the users fixed the problem for you, please integrate the
fix.
I have the similar issue with Ubuntu Server 14.04.2 and I confirm that
the patch in #13 working flawlessly. Disks are no longer synced every
time I boot the server.
Are the maintainers going to fix this issue in the next release?
--
You received this bug notification because you are a member of
Hi to all..
I have the same problem with fresh installed Ubuntu 14.04
can somebody help me how to apply this patch? It seems I am missing files
Downloads/init.d/mdadm and Downloads/init.d/umountroot ?
Thank you...
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I have suffered under the same problem, running 12.10, 13.10 now
14.04. I just tried your patches, Matthew, they appeared to work. I
only rebooted once, however. I'll test some more later.
Thanks!
-John
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Comment #12 worked for me! Thanks Chris.mn.
However, I believe the more canonical way of omitting the PIDs to kill
would be to use the /run/sendsigs.omit.d directory. Interestingly,
/etc/init.d/mdadm already adds mdmon to this, just only on stop, not
start. I don't understand why and this may be
The attachment mdadm.patch seems to be a patch. If it isn't, please
remove the patch flag from the attachment, remove the patch tag, and
if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any
I also experienced the same problem with a IMSM RAID 1. I believe that
the problem is essentially identical to the gentoo problem which was
noted earlier. I put in the following workaround which seems to work
(on a clean install of Ubuntu 14.04.1 with mdadm version 3.2.5). At
least, I have not
I also have a similar problem. Had a lot of troulbe setting uf mdadm
raid.
Have mdadm for my root partition as well as others so cannot use
workaround displayed above.
I believe the problem is somethingto di with thre initramfs not closing
down mdmon properly on shutdown.
I also have the
Hi Martin,
Thanks for that piece of script !
Are you also facing the bug where any operation on the RAID1 file-system
under Ubuntu (write) will trigger a Verification of the array on Windows
?
Damien
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Yes, the bios reports the raid as normal, but a resync is started
regardless whether I boot Ubuntu or Windows. So I think it's pretty
clear that the problem is in writing down a clean state to the metadata
block during the Ubuntu shutdown.
--
You received this bug notification because you are a
Hi Martin,
My RAID array is automatically mounted through fstab and stays in auto-
read-only state as you mentionned. Even mounting it unmounting it
manually and re-mounting does not cause it to go in write state for
me. That's the only difference.
Thanks for pointing the Gentoo bug. Our issue
I deviced a workaround for this by mounting and unmounting my raid
separately. The key is that I don't need it during boot, nor start any
daemons that keep files open on it.
First, I added the noauto option to all the mounts on the raid in
/etc/fstab.
Then I added an upstart script as below.
Alright, my bug is slitghtly different than yours. See
http://ubuntuforums.org/showthread.php?t=2224874
Ubuntu is not systematically resync-ing the RAID1 array after each
reboot for me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I can confirm that if the raid stays in auto-read-only state (i.e. isn't
written to), then it won't start a resync on the next boot. I verified
that by not mounting any of the file systems (for me it's enough to
mount a file system to cause a write - it doesn't have to be a file
write). That being
I will watch that carefully as I noticed pretty much the same !
At first, on Linux, the RAID was in Initialize state. You can power-down and
up, Ubuntu will continu re-sync from where it stops (expected behavior)
After full re-sync with Ubuntu, BIOS displayed Normal status for the RAID1.
From
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: mdadm (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1320402
Title:
Windows finished the Verification. RAID1 went into Normal state. I could
reboot on both Ubuntu and Windows several times while the RAID1 stayed
in Normal state.
When I created a file on the RAID array in Ubuntu, then after reboot, it
started a full resync again.
dmesg | grep md:
[3.261354]
Another observation: This system is a dual boot with Windows (why else
use imsm?), and if I shut down from Windows with the raid in healthy
state, mdadm doesn't start a resync. It is only if I shut down
normally/cleanly from Ubuntu that that happens.
--
You received this bug notification because
44 matches
Mail list logo
