LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   findfs returns wrong device(s) outside initrd (http://www.linuxquestions.org/questions/slackware-14/findfs-returns-wrong-device-s-outside-initrd-4175466457/)

Ser Olmy 06-18-2013 03:22 AM

findfs returns wrong device(s) outside initrd
 
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:
Code:

# findfs LABEL=root
/dev/dm-1
# findfs LABEL=boot
/dev/dm-2

Once initrd exits, it's a different story:
Code:

~# findfs LABEL=root
/dev/sda1
~# findfs LABEL=boot
/dev/sda2

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?

Richard Cranium 06-18-2013 09:33 PM

What mkinitrd command did you use to create it?

Ser Olmy 06-19-2013 11:32 AM

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:
Code:

if [ -x /sbin/dmraid ]; then
  dmraid -ay
  /sbin/udevadm settle --timeout=10
fi

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.

GazL 06-19-2013 12:16 PM

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

Ser Olmy 06-19-2013 01:18 PM

Quote:

Originally Posted by GazL (Post 4974847)
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.

GazL 06-19-2013 03:15 PM

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.


All times are GMT -5. The time now is 04:08 AM.