#1384 Issue closed: REAR iso maps scsi controllers in different order than native SUSE on VMWare with different cntrollers

Labels: bug, fixed / solved / done, Dedicated Priority Support

dzegelman opened issue at 2017-06-13 09:41:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • rear version (/usr/sbin/rear -V): 1.19
  • OS version (cat /etc/rear/os.conf or lsb_release -a): SUSE Linux x64 11 SP3
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf): default
  • Are you using legacy BIOS or UEFI boot? BIOS, VMware
  • Brief description of the issue: rear recovery iso has different order of scsi hosts initialization what creates problem to recover. When booting from REAR iso lsscsi gives different ids for scsi controllers. Hosts has 4 various controllers LSI and Paravirtual
  • Work-around, if any: No workaround found

schlomo commented at 2017-06-13 15:03:

Please provide both from the working source and the troubled rescue system

  • dmesg which shows all the SCSI relevant parts, both about drivers and devices
  • lspci
  • lsscsi -kds
  • lsmod

dzegelman commented at 2017-06-13 15:39:

Thanks a lot for the answer.

Original Situation VMWare SUSE 11 Enterprise SP3 with shared drives running Oracle Database with ASM:
rn2inssv268:~ # lsscsi -H
[0] mptspi
[1] ata_piix
[2] ata_piix
[3] vmw_pvscsi
[4] vmw_pvscsi
[5] vmw_pvscsi
rn2inssv268:~ #

SCSI adapters order is correct like in a vmx file

RESCUE statsus (rear 1.17, 1.19, 1.21 was tested):
[0] vmw_pvscsi
[1] vmw_pvscsi
[2] vmw_pvscsi
[3] mptspi
[4] ata_piix
[5] ata_piix

Order is different. All other required information is attached.

Thanks a lot in advance,

Dan Zegelman

From: Schlomo Schapiro [mailto:notifications@github.com]
Sent: Dienstag, 13. Juni 2017 17:03
To: rear/rear rear@noreply.github.com
Cc: Dan Zegelman danz@envops.com; Author author@noreply.github.com
Subject: Re: [rear/rear] REAR iso maps scsi controllers in different order than native SUSE on VMWare with different cntrollers (#1384)

Please provide both from the working source and the troubled rescue system

  • dmesg which shows all the SCSI relevant parts, both about drivers and devices
  • lspci
  • lsscsi -kds
  • lsmod

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/rear/rear/issues/1384#issuecomment-308146031, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATUxL49gVxTRFbF2JKJArd6da7BegYR8ks5sDqSsgaJpZM4N4PSN.

schlomo commented at 2017-06-13 15:49:

Did you send this via email? I think that GitHub strips attachments. Please upload directly via the GitHub web UI.

dzegelman commented at 2017-06-13 15:53:

Requested files uploaded

dzegelman commented at 2017-06-13 15:56:

dmesg.orig.docx
lsmod.rescue.docx
lspci.orig.docx
lspci.rescue.docx
lsscsi.orig.docx
lsscsi.rescue.docx
dmesg.orig.docx
dmesg.rescue.docx
lsmod.orig.docx

schlomo commented at 2017-06-15 07:06:

The source system loads all the storage modules in the initrd and has in /etc/sysconfig/kernel the following entry (actually with more modules, but those count for this issue):

INITRD_MODULES="mptspi vmw_pvscsi"

The ReaR rescue system however loads the modules via udev and does not know about this order. I think that we should pick up this information automatically via something like this:

MODULES_LOAD=( "${MODULES_LOAD[@]}"
  $(
    INITRD_MODULES=
    source /etc/sysconfig/kernel
    echo $INITRD_MODULES
  )
)

@jsmeix do you know for which SUSE/SLES versions this would work?

schlomo commented at 2017-06-19 06:04:

Note: May be also related to #1327

dzegelman commented at 2017-06-19 08:22:

Yes, we had behavior mentioned in #1327, it was relevant only for disks remapping and we overcome it by pressing "y" through recovery flow :) and later hacked scripts to avoid it. Can we implement any workaround for now? Thanks, Dan

schlomo commented at 2017-06-19 08:59:

After reading the change in #1327 I realized that there we only added --force to the wipefs call and not to the mkfs.ext? calls. I'll have a look into fixing this.

jsmeix commented at 2017-06-20 09:38:

I think the whole module loading in the recovery system
currently works too much automated that leads to
unwanted results. For details see
https://github.com/rear/rear/pull/909#issuecomment-309693663

[Export of Github issue for rear/rear.]