View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015658||CentOS-7||mdadm||public||2018-12-31 19:00||2018-12-31 20:00|
|Target Version||Fixed in Version|
|Summary||0015658: mdadm cannot assemble array at boot, hence if the array is mounted , Centos boots into emergancy mode|
|Description||If an Array is created ( in this case RAID6 with 6 physical disks) on bare disks (/dev/sd*) an some of the disks contains a partition table, even an empty one, mdadm happily creates the Array, possibly informing that there is apartitiontable, but it will be useless after mdadm is ready.|
After a reboot, those disks containing remains of a partition table is wiped during the boot making it impossible for mdadm to use them, and system boots into emergency mode.
After the filesystem is removed from fstab a normal reboot could be performed, using mdadm examine on those disk reveals that both superblock and uuid is missing from them.
I suspect that the disks are silently checked by fsck during boot, and finds the empty partitiontabe and tries to fix it, wiping all data of the array from the disk.
Deleting disklabel and the empty partitiontable solves the problem (using gParted)
In my opinion mdamd should not try to create such Array, but should exit with the information that the relevant disks should be completly wiped, or mdadm should wipe the disks during the creation of the array.
Now bearing in mind, that it takes some time to create and resync large arrays, up to several Days, it is quite frustrating to find out that the Array has been destroyed at boot time.
|Steps To Reproduce||Label the disk as gpt, create partition, delete the partition, use the disk with mdadm --create.|
If one does this with several disks, so one excceds the minimum required number of disks for the particcular level, mdadm will fail to assemble the array
|Tags||No tags attached.|
Forgot to mention, in my case the mounted partition contains data, nothing for the system.
I would have thought that the system should boot normaly, even if it cannot mount an auxillary filesystem.
Giving that the system is headles, I cannot ssh into the system when its in emergancy mode.