An MDADM array named md127 appearing at boot is a standard Linux behavior, not a ghost. The kernel assigns this name when no other arrays are active because it is the first available minor number in the dynamic allocation range. This "ghost" is simply an uninitialized or spare container ready for use, and it can be safely ignored or removed by clearing the superblock metadata on the underlying disks.
Understanding Dynamic Device Naming
To solve this mystery, you must understand how the Linux kernel manages block devices. Modern versions of MDADM and the Linux kernel do not rely on static names like /dev/md0 or /dev/md1 by default. Instead, they use a dynamic naming scheme. When the system boots, the kernel scans all connected storage devices for MDADM superblocks. If it finds none that form an active array, or if it finds disks with superblocks but no active assembly configuration, it may create a temporary device node.
The name md127 is often mistaken for a high-numbered error or a reserved identifier, but it is actually the starting point for dynamic allocation in many configurations. When the kernel initializes the MD subsystem, it looks for the lowest available minor number. If md0 through md126 are either in use by other arrays or explicitly reserved, md127 becomes the first candidate. It is crucial to note that md127 is not the maximum possible minor number; the limit is typically md255. Therefore, seeing md127 does not indicate a system failure or a resource exhaustion issue. It is merely the kernel's way of saying, "I found some disks, but I don't know what to do with them yet, so I created a placeholder."
Why Webmin Shows It
Webmin and similar management consoles query the /proc/mdstat file to display RAID status. This file lists every MD device the kernel knows about, regardless of whether it is active, degraded, or unused. If your server has spare disks or disks from a previous configuration that still have MDADM signatures (superblocks) on them, the kernel will detect these signatures during boot. It will then expose these disks as part of a new, empty array named md127. Webmin reads this state and displays it as an active entity, leading users to believe there is a phantom array consuming resources or causing conflicts.
This behavior is particularly common in Proxmox VE environments where users frequently add, remove, or repurpose disks. If you recently replaced a disk in a ZFS pool or changed a SATA controller, old MDADM metadata might remain on the drive. The kernel sees this metadata and attempts to assemble an array, resulting in the md127 entry. This is not a bug in Proxmox or Ubuntu; it is the expected behavior of the MDADM driver when encountering orphaned metadata.
Detecting the Source of the Ghost Array
Before attempting to remove the array, you need to identify which physical disks are being associated with md127. You can do this by examining the contents of /proc/mdstat after the system has fully booted. Run the following command in your terminal:
cat /proc/mdstatLook for the section labeled md127. If it exists, it will list the member devices, such as sdb, sdc, or vda. Note these device names carefully. Next, check the detailed status using the mdadm utility. Execute the following command to see if any arrays are assembled:
sudo mdadm --detail --scanIf md127 appears here, it means the array is currently assembled. However, if the array is inactive or unused, it might not appear in the scan output but will still show up in /proc/mdstat as a dummy device. To confirm the presence of superblocks on specific disks, use the --examine flag. For example, to check /dev/sdb:
sudo mdadm --examine /dev/sdbIf this command returns information about an MDADM superblock, it confirms that the disk contains old RAID metadata. This is the root cause of the ghost array. The kernel detects this signature, assumes an array should exist, and creates the md127 container to hold these members until instructed otherwise.
Removing the Ghost Array
Once you have identified the disks responsible for the ghost array, you can eliminate the issue by removing the MDADM superblocks from those drives. This process effectively erases the RAID history from the disks, allowing the kernel to treat them as plain storage devices again. First, ensure that the md127 array is stopped. If it is active, stop it using:
sudo mdadm --stop /dev/md127If the array is already inactive or does not exist as an active unit, this command may return an error indicating the device is not found, which is acceptable. Next, zero out the superblocks on the identified disks. Replace /dev/sdX with the actual device names you noted earlier. Be extremely careful to select the correct disks, as this operation will destroy any existing data on those specific partitions.
sudo mdadm --zero-superblock /dev/sdb /dev/sdcAfter running this command, reboot your system. Upon restart, the kernel will no longer find MDADM signatures on those disks, and md127 will not appear in /proc/mdstat or Webmin. The ghost array has been successfully exorcised.
Preventing Future Occurrences
To prevent this issue from recurring, consider updating your /etc/mdadm/mdadm.conf file. Ensure that only the arrays you intend to use are listed in the ARRAY lines. Additionally, if you are using Proxmox, you can configure the system to ignore specific disks during the MDADM assembly phase by adding them to the IGNORE_DEVICES list in the configuration file. This ensures that even if old metadata persists, the kernel will not attempt to assemble it into a visible array.
If you are managing multiple servers, you might find it helpful to audit your disk signatures regularly. Tools like blkid can help you identify which disks have various filesystem or RAID signatures. By keeping a clean slate on your storage devices, you avoid confusion during boot processes and maintain a clear view of your system's actual storage topology.
Frequently Asked Questions
Is md127 dangerous to my data?
No, the appearance of md127 is harmless and does not pose a risk to your existing data. It is simply a kernel-generated device node representing an unused or partially detected array. It does not overwrite data unless you explicitly write to it, which you should never do without verifying the target device first.
Can I rename md127 to something else manually?
You cannot permanently rename md127 because its name is dynamically assigned by the kernel based on availability. While you can create symlinks or use udev rules to create custom aliases for active arrays, this approach does not work for inactive or dummy devices like md127. The best solution is to remove the underlying metadata rather than trying to change the name.
What if I want to use these disks for a new RAID array?
If you intend to use the disks associated with md127 for a new RAID setup, you should first zero their superblocks as described in the removal steps. Then, you can create a new array using mdadm --create. This ensures that the new array starts with a clean slate and avoids potential conflicts with old metadata that might confuse the assembly process.
Does this issue affect ZFS pools in Proxmox?
No, this issue is specific to the Linux MDADM software RAID subsystem and does not directly interfere with ZFS pools. However, if ZFS is not detecting the disks because MDADM has claimed them via superblock detection, you may see errors in dmesg. Removing the MDADM superblocks allows ZFS to scan and import the vdevs correctly, restoring normal functionality to your storage pool.
How do I check if md127 is using CPU or RAM?
An inactive or unused md127 device consumes negligible system resources. It does not run background processes or allocate significant memory. Any perceived performance impact is likely due to other factors, such as disk I/O waits from scanning the drives during boot. Monitoring tools like top or htop will show minimal to no usage for the md127 process itself.