[rear-users] Problems with SLES15 SP1 with boot from iSCSI disks

[Johannes Meixner]

Hello,

I have zero personal experience with iSCSI
and also not with a specific HPE SYNERGY660 system
so there is nothing what I could do to directly help you,
but perhaps others could able to help you directly.

When you do not yet use our latest ReaR upstream
GitHub master code, have a look at the section
"Testing current ReaR upstream GitHub master code" at
https://en.opensuse.org/SDB:Disaster_Recovery

In general we at ReaR upstream prefer when issues are
reported to us as GitHub issues via the [New issue] button at
https://github.com/rear/rear/issues

This leads you automatically to our issue template at
https://raw.githubusercontent.com/rear/rear/master/.github/ISSUE_TEMPLATE.md
where we list what info we usually like to get.

Usually we need debug logs i.e. made with "rear -d -D mkbackup"
plus "rear -d -D recover" when there are issues during "rear recover"
plus your disklayout.conf file and things like that,
see "Debugging issues with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery

The main advantage of GitHub issues over plain e-mails
is the much better GitHub user interface that helps a lot
when several people need to work together on an issue.

Furthermore have a look at the section
"SUSE support for Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery


Only FYI, perhaps it might help you:

Regarding how to debug issues during startup of the
ReaR recovery system:

When you boot the ReaR recovery system on "usual hardware"
you should get the recovery system bootloader menue where
you can add the kernel command line parameter ' debug'.

This way the recovery system startup scripts are run
one by one (you need to press Enter to run each one)
with the bash 'set -x' option set so that you get the
commands of each script printed on the terminal/console.

This can help to find out the root cause when things go wrong
during recovery system startup.

The recovery system setup scripts are in etc/scripts/system-setup.d

When there are issues with networking setup during recovery system startup:

The main networking setup script is
/etc/scripts/system-setup.d/60-network-devices.sh
that is generated during "rear mkrescue/mkbackup" by
https://github.com/rear/rear/blob/master/usr/share/rear/rescue/GNU/Linux/310_network_devices.sh

See the usr/share/rear/rescue/GNU/Linux/310_network_devices.sh script
for details how networking setup happens in the recovery system.

Furthermore there is NETWORKING_PREPARATION_COMMANDS that could help
to set up special networking in the ReaR recovery system, see
the NETWORKING_PREPARATION_COMMANDS description in default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf

Finally you could use KEEP_BUILD_DIR="yes" (see its description in default.conf)
to inspect the contents of the ReaR recovery system on your
original system in /tmp/rear.XXXXXXXXXXXXXXX/rootfs
after is was made there by "rear -d -D mkrescue/mkbackup" and
you can test things to a certain extent inside the ReaR recovery system
on your original system via "chroot /tmp/rear.XXXXXXXXXXXXXXX/rootfs".


On Mar 27 14:15 Sander, Ulrich wrote (excerpt):

> Hello all!
> We have some new Servers for our HANA project. They are from HPE the model is SYNERGY660.
> We had in the past worked successfully with rear on HP-Blades (BL460c)
> with local disks and with SLES12 SP3.
> Now it is different: we have iSCSI boot and we had setup the servers with SLES15 SP1.
> We have setup two different versions: one with multipath and lvm and one without.
>
> The installation of SLES works fine and the rear mkbackup (version 2.41)
> is also working properly on both versions.
> The problem starts when we want to recover.
>
> First of all we have to manually connect the iSCSI-disks with setup the network interfaces,
> starting iscsid, login to the target.
>
> The version with multipath and lvm runs after the restore at the final boot into an
> error "lvmid not found" at the grub level and we get a prompt for a grub rescue shell.
>
> The version without multipath/lvm also does not succeed: here the trouble starts at the
> recovery process: the disklayout.sh is "empty" (so there is some coding but no fs descriptions).
> This means during creation of the iso file something went wrong.
> We had changed in the local.conf the EXCLUDE_MULTIPATH to "Y" and started a new mkbackup.
> But even with the new iso image the error was identical.
>
> Regarding these two errors the second one is more relevant to rear.
> The first error probably comes from a different area because we are also not able
> to boot the servers from a backup lun.
>
> Does anyone has experience with iSCSI boot and rear?
>
> Rgds
> Ulrich Sander


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer