[opensuse] LVM devices not being recognized by kdump initrd
Hello guys: I'm running suse 12 in a HP Proliant DL580 G9 server which is currently having some strange issues. I've recently configured kdump (using YaST and Low+High mem values) but I'm unable to make it work. Everytime I try to execute a SysRq (echo c > /proc/sysrq-trigger9 to make my system crash and kdump to get started, I get an error like this: Starting Setup Virtual Console... [OK] Started Setup Virtual Console. Starting Dracut Emergency Shell... Warning: /dev/mapper/3600508b1001c0dff3dd8a8f270cec052_part1 does not exist Warning: /dev/mapper/vg00-lvcrash does not exist Warning: /dev/mapper/vg00-lvroot does not exist Warning: /dev/mapper/vg00-lvswap does not exist Warning: /dev/mapper/vg00-lvswap02 does not exist Warning: /dev/vg00/lvcrash does not exist Warning: /dev/vg00/lvroot does not exist Warning: /dev/vg00/lvswap does not exist Warning: /dev/vg00/lvswap02 does not exist Warning: Boot has failed. To debug this issue add "rd.shell rd.debug" to the kernel command line. [FAILED] Failed to start Dracut Emergency Shell. See "systemctl status dracut-emergency.service" for details. [OK] Started dracut initqueue hook. [OK] Reached target Initrd Root File System. [OK] Starting Reload Configuration from the Real Root... [OK] Reached target Remote File Systems (Pre). [OK] Reached target Remote File Systems. [OK] Started Reload Configuration from the Real Root. [OK] Reached target Initrd File Systems. Those Warning messages refer to LVM and/or multipath devices not being recognized. It seems that kdump initrd file does not contain the appropriate kernel modules or maybe some internal script is failing to recognize my LVM devices. My volume group vg00 resides in a local disk (no SAN), however the underlying disk appears in the output of "multipath -ll" command as if it were a SAN disk. Take a look at this: 3600508b1001c0dff3dd8a8f270cec052 dm-0 HP,LOGICAL VOLUME size=1.6T features='1 queue_if_no_path' hwhandler='0' wp=rw `-+- policy='service-time 0' prio=1 status=active `- 0:1:0:0 sda 8:0 active ready running What I've tried so far: 1. Uncompress kdump initrd file to see if dm-mod and dm-multipath modules are included. I confirm that those modules exist inside such ramdisk file. 2. Add (then remove) root_no_dm=1 and root_no_mpath=1 to /etc/sysconfig/kdump followed by a "mkdumprd -f" and "rckdump restart". I had no luck, my vg00 is not recognized yet. 3. Rebuild the kdump initrd by runnnig "mkdumprd -f -i lvm2" trying to force lvm2 module to be included. No luck. I wonder if you can help me, maybe give me some ideas or similar experieces you've had before. Thanks in advance for your time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26.12.2017 17:00, Jason Voorhees wrote:
My volume group vg00 resides in a local disk (no SAN), however the underlying disk appears in the output of "multipath -ll" command as if it were a SAN disk. Take a look at this:
3600508b1001c0dff3dd8a8f270cec052 dm-0 HP,LOGICAL VOLUME size=1.6T features='1 queue_if_no_path' hwhandler='0' wp=rw `-+- policy='service-time 0' prio=1 status=active `- 0:1:0:0 sda 8:0 active ready running
Hi, i have almost no experience with kdump, but it looks like the "local" disk of your HP server is in fact a logical volume of a built in raid controller. I think the cciss kernel module needs to be part of your kdump initrd. You should check that.
Ooh, good point. In fact, it's hpsa (not cciss) the kernel module being used. I'm going to take a look at it in the contents of the ramdisk image. Thanks Florian, I'll let you know the results On Tue, Dec 26, 2017 at 7:27 PM, Florian Gleixner <flo@redflo.de> wrote:
On 26.12.2017 17:00, Jason Voorhees wrote:
My volume group vg00 resides in a local disk (no SAN), however the underlying disk appears in the output of "multipath -ll" command as if it were a SAN disk. Take a look at this:
3600508b1001c0dff3dd8a8f270cec052 dm-0 HP,LOGICAL VOLUME size=1.6T features='1 queue_if_no_path' hwhandler='0' wp=rw `-+- policy='service-time 0' prio=1 status=active `- 0:1:0:0 sda 8:0 active ready running
Hi,
i have almost no experience with kdump, but it looks like the "local" disk of your HP server is in fact a logical volume of a built in raid controller. I think the cciss kernel module needs to be part of your kdump initrd. You should check that.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi: On Wed, Dec 27, 2017 at 11:49 AM, Jason Voorhees <jvoorhees1@gmail.com> wrote:
Ooh, good point. In fact, it's hpsa (not cciss) the kernel module being used. I'm going to take a look at it in the contents of the ramdisk image.
I confirm that hpsa driver is already included in the initrd image. I'll continue looking for a solution. I hope someone can share any suggestion. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Jason Voorhees wrote:
Hi:
On Wed, Dec 27, 2017 at 11:49 AM, Jason Voorhees <jvoorhees1@gmail.com> wrote:
Ooh, good point. In fact, it's hpsa (not cciss) the kernel module being used. I'm going to take a look at it in the contents of the ramdisk image.
I confirm that hpsa driver is already included in the initrd image. I'll continue looking for a solution.
It looks like LVM isn't being started ? -- Per Jessen, Zürich (1.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Florian Gleixner
-
Jason Voorhees
-
Per Jessen