I'm booting a Slackware 14 system with an initrd, and I'd like to use file system labels in /etc/fstab. Both / and /boot are on LVM (actually dmraid, but that should make no difference).

Problem: Once the initrd exits, findfs returns the wrong devices for both labels.

Inside initrd:
Once initrd exits, it's a different story:
Since both these partitions are actually in use by device-mapper, any attempt to access or mount either of them will fail. Since /dev/sda1 can't be fsck'ed, the system won't boot unless I mount the root file system as writable (and get an error message, but at least it boots).

I believe this has to be an issue with the init script in the initrd. Any idea where I should start looking?

What mkinitrd command did you use to create it?

I used the command generated by mkinitrd_command_generator.sh, except I changed the root device parameter to -r LABEL=root. I then added the dmraid executable to /boot/mkinitrd-tree/sbin, copied all dmraid-related libraries to /boot/mkinitrd-tree/lib64, and added the following commands to the init script, right below the part that does LVM initialization:
I then ran mkinitrd again with no parameters. This generated a working /boot/initrd.gz with dmraid support.

While troubleshooting this issue, I added a few debug statements to the init script that would print the output of findfs LABEL=root at various points in the script. I was able to determine the following:

• When init starts, findfs returns /dev/sda1 and /dev/sda2 for LABEL=root and LABEL=boot respectively. This is as expected, as each component of a fakeRAID mirror set contains a regular partition with a valid file system and RAID metadata at the end.
• Once the dmraid command has been run, findfs returns /dev/dm-1 and /dev/dm-2, as it should.
• The init script successfully identifies /dev/dm-1 as the root FS, and is able to mount it (adding a mount command et the very end of the init script confirmed this).

And now for the weird part: When initrd exits and the boot process continues, findfs immediately starts returning /dev/sda1 and /dev/sda2 again. There's no way the kernel could have probed /dev/sda1 again as it is mounted and locked by device-mapper, so this must be stale information from earlier in the boot process. At this point, mount also insists that /dev/sda1 is mounted as /. And no, there's no stale information in /etc/mtab, so where is this information coming from?

Interestingly, running partprobe will fix the invalid /dev/sda2 reference, since /dev/dm-2 (a small, mirrored boot volume) never gets mounted. The /dev/sda1 reference stays though, as /dev/dm-1 is mounted and cannot be probed.

Maybe the blkid cache file is the culprit: /run/blkid/blkid.tab

Slackware doesn't seem to have that file, neither in /run/blkid (which doesn't exist) nor anywhere else.

It gets created when you run blkid. I was working on the assumption that findfs used the same backend, but perhaps that's not the case then.