The error occurs when attempting to create a RAID 10 array while some partitions are actively being used by the system. In this case, partitions 1 (/boot) and 2 (root filesystem) are likely mounted, preventing mdadm from accessing the underlying block devices.

# Checking mounted filesystems
mount | grep 'sd[a-h][12]'
/dev/sda1 on /boot type ext3 (rw)
/dev/sda2 on / type ext4 (rw)

When converting from a single disk to RAID 10, you cannot create arrays using partitions that are currently mounted. The system needs these partitions to remain operational during the process. This is particularly true for:

• Boot partitions (/dev/sdX1)
• Root filesystem partitions (/dev/sdX2)

The most reliable method is to perform this operation from a rescue environment where these partitions aren't mounted. Here's the step-by-step process:

# 1. Boot into rescue mode (using systemrescuecd or similar)
# 2. Stop any existing arrays
mdadm --stop /dev/md[0-9]*

# 3. Create the new arrays for partitions 1 and 2
mdadm --create /dev/md0 --level=10 --raid-devices=8 /dev/sd[abcdefgh]1
mdadm --create /dev/md1 --level=10 --raid-devices=8 /dev/sd[abcdefgh]2

# 4. Verify creation
cat /proc/mdstat

If you cannot use a rescue disk, you might try this more complex approach:

# 1. Create temporary mount points
mkdir /mnt/tempboot /mnt/temproot

# 2. Copy boot and root filesystems
rsync -a /boot/ /mnt/tempboot/
rsync -a / /mnt/temproot/ --exclude=/boot --exclude=/proc --exclude=/sys --exclude=/dev

# 3. Unmount original partitions
umount /boot
umount /

# 4. Proceed with RAID creation
mdadm --create /dev/md0 --level=10 --raid-devices=8 /dev/sd[abcdefgh]1
mdadm --create /dev/md1 --level=10 --raid-devices=8 /dev/sd[abcdefgh]2

After successfully creating the arrays, you'll need to:

1. Update /etc/fstab with the new UUIDs
2. Reconfigure your bootloader (GRUB)
3. Rebuild your initramfs

# Get new UUIDs
blkid /dev/md0
blkid /dev/md1

# Update GRUB
grub2-mkconfig -o /boot/grub2/grub.cfg

# Rebuild initramfs
dracut --force

• Always have complete backups before attempting RAID migrations
• Monitor rebuild progress with watch cat /proc/mdstat
• Consider using --assume-clean flag if all disks are known to be blank
• For production systems, test the procedure in a non-critical environment first

When attempting to convert from a single disk configuration to RAID 10 using mdadm, many administrators encounter the frustrating "Device or resource busy" error, particularly when dealing with partitions containing mounted filesystems like / and /boot.

The error occurs because:

• The system is actively using /dev/sda1 (typically for /boot partition)
• Existing partitions might be mounted or in use by other processes
• mdadm cannot overwrite partitions currently involved in system operations

Here's the proper workflow to resolve this:

# First check mounted filesystems
mount | grep sd

# If /boot or / is mounted from sda1/sda2:
umount /boot
umount /

# Verify no remaining processes using the device
lsof /dev/sda1

# If necessary, stop any services using the partitions
systemctl stop some-service-using-partition

For critical partitions, booting from a rescue disk is often the cleanest solution:

1. Boot using LiveCD/USB
2. Identify disks: lsblk
3. Create array before mounting:
   mdadm --create /dev/md0 --level=10 --raid-devices=8 /dev/sd[abcdefgh]1
4. Proceed with filesystem creation and mounting

When building large RAID 10 arrays:

• Always use --metadata=1.2 for better compatibility
• Consider chunk size carefully (--chunk=)
• Monitor initial sync progress with watch cat /proc/mdstat

# Example optimal creation command
mdadm --create /dev/md0 --level=10 --raid-devices=8 \
--metadata=1.2 --chunk=512 /dev/sd[abcdefgh]1

Your current /proc/mdstat shows active arrays on partitions 3 and 4. When dealing with such scenarios:

# Stop existing arrays if needed
mdadm --stop /dev/md3
mdadm --stop /dev/md4

# Wipe superblocks
mdadm --zero-superblock /dev/sd[abcdefgh][34]

Remember to backup all data before proceeding with these operations.