This error is generated by the initramfs script that finds and mounts the root fs.

I've experienced this message before and it turned out to be caused by updating the initramfs from a live cd.

The thing was that I had an encrypted root, and when opening the luks volume from the live cd I didn't use the same name that was in my crypttab.

So, I booted the live cd and did:

cryptsetup luksOpen /dev/md1 md1

vgchange -ay

mount /dev/vgmain/lvroot /mnt/custom

<... mount dev et. al ...>

chroot /mnt/custom

<... fix something ...>

update-initramfs -u

exit

umount /mnt/custom && vgchange -an && cryptsetup luksClose md1

The update-initramfs -u did warn about cryptsetup: WARNING: invalid line in /etc/crypttab - but at first I didn't deem it important.

After some failed attempts to boot it hit me: my crypttab had md1_crypt for the luks volume, but when I updated the initramfs it saw md1 so it went with that. From within the boot scripts md1 was not available as a luks volume.

So I booted my livecd again and corrected it:

cryptsetup luksOpen /dev/md1 md1_crypt

vgchange -ay

mount /dev/vgmain/lvroot /mnt/custom

<... mount dev et. al ...>

chroot /mnt/custom

update-initramfs -u

exit

umount /mnt/custom

vgchange -an

cryptsetup luksClose md1_crypt

I've looked through the initramfs-tools scripts, but I couldn't find the exact spot where this went wrong, so I assume it was just some weird interaction between cryptsetup, mdadm and lvm.

On another debian host I had a similar issue*, except this time without crypttools or lvm involved, and I was able to work around it by changing my mdadm.conf from /dev/md/n device paths to /dev/mdn. On this ocassion, the issue only presented itself while the array was rebuilding and not when everything was normal.

Perhaps someone more familiar with the inner workings of initramfs-tools can figure this out.

_{* the debian host also showed a message like incrementally starting raid arrays after a few CREATE group disk not found.}