On 11/16/2013 10:06 AM, Tom H wrote:
Somehow md1 and md2 became md127 and md126
Have you changed your hostname?
No, do you suspect the October 3rd dracut-network update?
On Sat, Nov 16, 2013 at 4:16 PM, Kevin H. Hobbs hobbsk@ohio.edu wrote:
On 11/16/2013 10:06 AM, Tom H wrote:
Somehow md1 and md2 became md127 and md126
Have you changed your hostname?
No, do you suspect the October 3rd dracut-network update?
The renaming happens because the hostname prefixes the mdraid UUID so, when an array is assembled, a "foreign" hostname results in a rename.
If you haven't changed the hostname, it may be that the array is assembled before the real hostname is set.
I found this bug:
"dracut doesn't copy etc/mdadm.conf into the initramfs image"
https://bugzilla.redhat.com/show_bug.cgi?id=1015204
which looks exactly like what I'm describing.
Thank you for your response.
On Mon, Nov 18, 2013 at 1:41 PM, Kevin H. Hobbs hobbsk@ohio.edu wrote:
I found this bug:
"dracut doesn't copy etc/mdadm.conf into the initramfs image"
https://bugzilla.redhat.com/show_bug.cgi?id=1015204
which looks exactly like what I'm describing.
Thank you for your response.
You're welcome, not that I was of any help.
So IIUC "#mdadmconf=no" was enough in a previous version for mdadm.conf to be copied into the initramfs but you now need "mdadmconf=yes"?
"dracut doesn't copy etc/mdadm.conf into the initramfs image"
So IIUC "#mdadmconf=no" was enough in a previous version for mdadm.conf to be copied into the initramfs but you now need "mdadmconf=yes"?
That's my understanding as well.
Much of the discussion in the bug talks about failure to boot.
I can still boot because my /etc/fstab has all UUID's not device names.
My only symptom is that mdadm complains when it tries to monitor the arrays...