PDA

View Full Version : [SOLVED] init rams fs issues since kernel 3.5


jvillain
1st June 2012, 11:29 PM
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
2nd June 2012, 02:44 AM
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
12th August 2012, 06:12 AM
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
12th August 2012, 06:56 AM
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.

Yarovoye Instagram Photos - Chandrapur Photos - East Ridge