Dracut Shell after kernel upgrade

[jeho]

Hello,

no substantial contribution currently beyond the experience, that the same OS-installation, but on a different hardware succeeded yesterday for me:

HP Proliant (HP SmartArray P400): failure
Supermicro, onboard SAS-controller without RAID: success

"Success" meaning: regular update installation and fully functional reboot.

OS installation almost identical (one machine management controller, other: host), in both cases the same kernel-/OS-update:

3.10.0-862.14.4.el7.x86_64 => kernel.x86_64 0:3.10.0-957.1.3.el7

Sorry for not being more specific, just wanted to post this in case it may ring s.th. for someone...

Best

J

[ariocwhite]

I'm running into the same issue... not at my computer ATT, but I am running Scientific Linux (CentOS derivative, I'm pretty sure, as a lot of RHEL instructions get messed up trying to make things work). I'm historically a Deb based tinkerer, and haven't really messed with kernels/drivers much yet.

What I'm seeing is a boot hang AFTER grub selecting the most recent kernel, then a spinning circle on colored screen like it is booting the login manager, but then dumps out to dracut and a bunch of error messages "can't find filesystem".

I am also running an HP server with P400 RAID. I found it cheap. I stuck more ram in it, and I would like to increase HDs on it for home server use, learning docker, and experimenting working towards my Cybersecurity degree, but now i need to fix this...

I tried using the Deb based linux versions unsuccessfully because of the P400 and faulty hpsa support, so now I'm using RHEL and family.
To get Scientific to run, I have been using cciss.cciss_allow_hpsa=1 hpsa.hpsa_simple_mode=1 hpsa.hpsa_allow_any=1
I also thought this was a permanent solution. Thanks for the training/update, and I would like to fix.

I saw a reference to downloading a el7 package... should I do that in the working previous kernel, install (rpm), then try to do a yum update ; yum upgrade? (if I'm dumb, correct me now, I'm used to apt update/dist-upgrade/upgrade)

[TrevorH]

Unfortunately the P400 controller is not supported by CentOS 7. There are currently 2 workarounds for this: one is to use hpsa_allow_any=1 kernel parameter/module option and the other is to install ELRepo's kmod-cciss. Both have disadvantages - the hpsa workaround is unsupported and may or may not work and, as you've just discovered, it appears that Redhat have broken it with 7.6 and since it's "unsupported" I am not sure if it will ever get fixed. The kmod-cciss workaround is also prone to breakage as it relies on the stable kernel ABI to allow it to work with multiple CentOS/RHEL kernels and Redhat often break that at a point release. In addition, both methods end up creating different device names I believe. I no longer have any HP hardware but I am fairly sure it creates devices of the form /dev/cciss/c0dX not /dev/sdX.

The P410 controllers are fully supported by hpsa...

[ariocwhite]

hmmm... so it looks like if i'm not willing to shell out the money for different hardware, i'll have to install the driver (in the process right now, actually), then be ready to update my grub to whatever it renames my partitions/drives... fun, but doable.
Now as far as upgrading the kernel again... what goes on there? I have the newer grub entry that doesn't work... once i install the driver, will it magically start working, or is it a kernel mod that needs to be put into a new kernel build?

[ariocwhite]

some details...

Code: Select all

Installed:
  kmod-cciss.x86_64 0:3.6.26-5.el7_5.elrepo

Complete!

[root@midgar] uname -a
Linux Midgar 3.10.0-862.14.4.el7.x86_64 #1 SMP Tue Sep 25 14:32:52 CDT 2018 x86_64 x86_64 x86_64 GNU/Linux

[root@midgar] more /boot/grub2/grub.cfg
(truncd)
...

menuentry 'Scientific Linux (3.10.0-957.1.3.el7.x86_64) 7.5 (Nitrogen)' --class scientific --class gnu-linux --class gnu
 --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-862.el7.x86_64-advanced-5ea8d20d-2d9a-4b2a-9428-6884732
a05de' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod xfs
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,ms
dos1 --hint='hd0,msdos1'  b75b558c-15b5-4828-811c-48adf6e2bde0
        else
          search --no-floppy --fs-uuid --set=root b75b558c-15b5-4828-811c-48adf6e2bde0
        fi
        linux16 /vmlinuz-3.10.0-957.1.3.el7.x86_64 root=/dev/mapper/scientific_midgar-root ro crashkernel=auto rd.lvm.lv
=scientific_midgar/root rd.lvm.lv=scientific_midgar/swap rhgb cciss.cciss_allow_hpsa=1 hpsa.hpsa_simple_mode=1 hpsa.hpsa
_allow_any=1 quiet LANG=en_US.UTF-8
        initrd16 /initramfs-3.10.0-957.1.3.el7.x86_64.img
}

[ariocwhite]

trying

Code: Select all

yum reinstall kernel

Installed:
  kernel.x86_64 0:3.10.0-957.1.3.el7

Complete!

[root@Midgar]# grub2-mkconfig -o /boot/grub2/grub.cfg

... lets hope this works

[ariocwhite]

UPDATE: nope. i must be missing something...

UPDATE: i looked into kmod... started poking around the kernel i'm trying to install... 3.10.0-957.1.3.el7.x86_64...
/lib/modules/...957 (no 1.3) had the directory extra/ and extra/kmod-kvdo... but no cciss
/lib/modules/...957.1.3... had cciss in "weak-updates"...

wait... am i being a goob here.. i'm trying to install kmod-cciss-3.6.26-5.el7_5.elrepo.x86_64.rpm.....

uname gave el7... should i be using kmod-cciss-3.6.26-3.el7.elrepo.x86_64.rpm??
i'll try that really quick...

UPDATE: nope. doesn't seem to matter. i also tried building a kernel... not sure i did that the right way, but that kernel didn't work... i guess i'm stuck with this kernel until i can try the next kernel they come out with... hopefully they fix it.

any other suggestions?

[grydan]

Hello same problem here for PROLIANT DL360 G5.
The last kernel 3.10.0-862.el7.x86_64 WORK well with the hpsa.hpsa_simple_mode=1 and hpsa.hpsa_allow_any=1

The new kernel 3.10.0-957.1.3.el7.x86_64 STOP WORK with P400 RAID...

Any news?

[tries]

Had the same issue, but got it working for me:

HP DL380 G5 (P400)
Kernel 3.10.0-957.21.3.el7.x86_64

With kernel options "hpsa.hpsa_simple_mode=1 hpsa.hpsa_allow_any=1" it was working until 3.10.0-862 but failed after updating the kernel to 3.10.0-957. Now, Removing the hpsa_simple_mode and only using hpsa_allow_any does work for me.

So I only use the following HPSA related module parameters, the P400 controller is recognized and working:
hpsa.hpsa_allow_any=1


Hope this may help,

/Thomas

[HankTheCrank]

I just went through this so I wanted to share my solution in case it helps someone else.

In my case, I did a

Code: Select all

yum update

and when I restarted the server, I ended up in the dracut shell. The kernel was updated as part of the update.

What happened was I have an iSCSI system installed that auto-mounted a bunch of volumes that I actually was not using. These volume mounts were included in the configuration of the new kernel, but are not present at boot time. Dracut timed out trying to mount these volumes.

My solution was to remove all the iSCSI mounts before I did the update. This worked.