On Mon, Oct 24 2016, Dan Kortschak wrote: > First, I'll start with an apology - I have little (~nothing) in the way > of hard data to back up this question, but it is now just a matter of > personal interest as the problem appears to be fixed. > > > Background: > > Last week I tried to upgrade a kernel (ubuntu distro 16.04) but that > failed due to out of space (the system was originally built when > kernels were much smaller and I have now got to the point where it is > not possible to have two kernels on the /boot partitian). > > On reboot the boot failed with a great deal of disk noise which > persisted. Booting into recovery worked, and the noise was now knowable Disk noise shouldn't cause the boot to fail.... > to be coming from a RAID resync of /dev/md0 (RAID10) after I dropped > into a root shell. I allowed this to complete and then went back to > resume the normal boot. This failed as before. > > Repeating the process above, I found that the RAID was again unsynced > an doing a resync. > > This has now resolved - I again allowed the resync to complete and then > did a /sbin/reboot from the CLI rather than going back to the recovery > menu and continuing the boot from the menu. > > > Question: > > What is a/are likely cause(s) for a resync to not persist over a > reboot? If /sbin/reboot works and the menu-thing doesn't then the menu-thing much be doing something very seriously wrong. You might be able to get the resync status to be forgotten if you write something to the array and then quickly run "reboot -f -n", or maybe "echo b > /proc/sysrq-trigger". Given that /sbin/reboot works, I suggest you report this to ubuntu as a bug. NeilBrown
Attachment:
signature.asc
Description: PGP signature
