init rams fs issues since kernel 3.5

[jvillain]

Since the 3.5 kernels started rolling out I haven't been able to boot them. They start loading OK and then crash as they are unable to mount the file system. When I did some digging I discovered that the install is no longer generating an initramfs and there is no entry in grub2 for it either.

I have tried to generate one with this command.

mkinitrd /boot/initramfs-3.5.0-0.rc0.git9.2.fc18.x86_64.img 3.5.0-0.rc0.git9.2.fc18.x86_64

It seems to go wrong with multipath.


I: *** Including module: multipath ***
D: Installing /lib64/libmultipath.so.0
D: Creating extra symlink: /lib64/libmultipath.so
D: Installing /sbin/multipath
D: Installing /usr/lib64/libncurses.so.5.9
D: Installing /sbin/multipathd
D: Installing /lib64/multipath/libcheckcciss_tur.so
D: Installing /usr/lib64/libaio.so.1.0.1
D: Installing /lib64/multipath/libcheckdirectio.so
D: Installing /lib64/multipath/libcheckemc_clariion.so
D: Installing /lib64/multipath/libcheckhp_sw.so
D: Installing /lib64/multipath/libcheckhp_tur.so
D: Installing /lib64/multipath/libcheckrdac.so
D: Installing /lib64/multipath/libcheckreadsector0.so
D: Installing /lib64/multipath/libchecktur.so
D: Installing /lib64/multipath/libprioalua.so
D: Installing /lib64/multipath/libprioconst.so
D: Installing /lib64/multipath/libpriodatacore.so
D: Installing /lib64/multipath/libprioemc.so
D: Installing /lib64/multipath/libpriohds.so
D: Installing /lib64/multipath/libpriohp_sw.so
D: Installing /lib64/multipath/libprioiet.so
D: Installing /lib64/multipath/libprioontap.so
D: Installing /lib64/multipath/libpriorandom.so
D: Installing /lib64/multipath/libpriordac.so
D: Installing /lib64/multipath/libprioweightedpath.so
D: Installing /usr/lib/dracut/modules.d/90multipath/multipathd.sh
D: Installing /usr/lib/dracut/modules.d/90multipath/multipathd-stop.sh
D: Installing /lib/udev/rules.d/40-multipath.rules
I: Skipping program $env{MPATH_SBIN_PATH}/multipath using in udev rule 40-multipath.rules as it cannot be found
D: Installing /lib/modules/3.5.0-0.rc0.git9.2.fc18.x86_64/kernel/drivers/scsi/device_handler/scsi_dh_alua.ko
D: Installing /lib/modules/3.5.0-0.rc0.git9.2.fc18.x86_64/kernel/drivers/scsi/device_handler/scsi_dh_hp_sw.ko
F: installkernel failed in module multipath



A cat on /usr/lib/udev/rules.d/40-multipath.rules or /lib/udev/rules.d/40-multipath.rules show the following.

# multipath wants the devmaps presented as meaninglful device names
# so name them after their devmap name
SUBSYSTEM!="block", GOTO="end_mpath"

ENV{MPATH_SBIN_PATH}="/sbin"
TEST!="$env{MPATH_SBIN_PATH}/multipath", ENV{MPATH_SBIN_PATH}="/usr/sbin"

ACTION=="add", ENV{DEVTYPE}!="partition", \
ENV{DM_MULTIPATH_DEVICE_PATH}!="1", \
PROGRAM=="$env{MPATH_SBIN_PATH}/multipath -c $tempnode", \
ENV{DM_MULTIPATH_DEVICE_PATH}="1"

ENV{DM_MULTIPATH_DEVICE_PATH}=="1", ENV{DEVTYPE}!="partition", \
RUN+="/sbin/partx -d --nr 1-1024 $env{DEVNAME}"

RUN+="socket:/org/kernel/dm/multipath_event"
KERNEL!="dm-*", GOTO="end_mpath"
ACTION!="change", GOTO="end_mpath"
ENV{DM_UUID}=="mpath-?*|part[0-9]*-mpath-?*", OPTIONS+="link_priority=10"
ENV{DM_UUID}!="mpath-?*", GOTO="end_mpath"
ENV{DM_SUSPENDED}=="1", GOTO="end_mpath"
ENV{DM_ACTION}=="PATH_FAILED", GOTO="end_mpath"
RUN+="$env{MPATH_SBIN_PATH}/kpartx -a -p p $tempnode"
LABEL="end_mpath"


I am not sure if this is an issue with dracut which includes mkinitrd, an issue with the multipath drivers in the kernel or an issue with udev? My 3.4 kernel still works but I think I have been through 3 or 4 3.5 kernels and they are still the same. Any one have any thoughts or suggestions?


Does any one have any thoughts or suggetions? Thanks.

[SlowJet]

Hethertobefore, the kerenl guy said that a new kerenl befor rc3 was only for them to:

rc0 = get stuff into the git.
rc1 - make the stuff compile.
rc2 - Let's see if this bird can fly.

SJ

[Zotter]

OK - some one translate this into "captain dummy speak" here.

I'm seeing - what I think is this same error here - but I'm clueless as to what it is in this thread that's [SOLVED] it. Google-Fu got me this far - where to next?

[smr54]

Not sure if the solved part of it was that the next kernel fixed it or the fact that SlowJet's post indicated that as they were rc (release candidate) they wouldn't necessarily work. No solution to the actual problem is given in the post.

To the OP (Original Poster) if you see this, it would be helpful, as you can see, to explain how it was solved.