#1335 Issue closed: ReaR PXE setup for SLES11 to boot HP ProLiant with UEFI¶
Labels: support / question, fixed / solved / done
sko341 opened issue at 2017-04-27 17:40:¶
Relax-and-Recover (ReaR) Issue¶
Can someone please help me configure rear for DR with PXE. Idea is to store rear rescue image to PXE server, and in event of disaster, recover via pxe boot. Sharing of local.conf configuration for this setup will be highly appreciated.
- rear version
Relax-and-Recover 2.00 / Git - OS version
SLES 11 SP4
Thanks
didacog commented at 2017-04-27 18:02:¶
Hi,
Maybe you can take a look at DRLM (www.drlm.org) to manage your PXE rear setup with central managent of rear configs, scheduling and more... ;)
Regards,
gozora commented at 2017-04-27 18:05:¶
@didacog you was the first thing on my mind when I've read subject of this issue :-)
gozora commented at 2017-04-27 18:14:¶
@SuneelOad I've found this.
Maybe it helps.
V.
sko341 commented at 2017-04-27 22:05:¶
@gozora: thanks for sharing, that helped in creating rescue image on PXE server. But I still can not see rescue image in pxe boot options. Here is local.conf:
OUTPUT=PXE
OUTPUT_PREFIX_PXE=$HOSTNAME
BACKUP=NETFS
BACKUP_URL=nfs://x.x.x.x/opt/rear
PXE_TFTP_URL=http://x.x.x.x/tftpboot
PXE_CONFIG_URL=http://x.x.x.x/tftpboot/pxelinux.cfg
gdha commented at 2017-04-28 10:10:¶
@SuneelOad You should check the PXE config files at
http://10.48.187.202/tftpboot/pxelinux.cfg
location.
Was the upload successful of the config files? Check the rear log to be
sure.
sko341 commented at 2017-04-28 15:38:¶
@gdha PXE config files were not uploading at
http://x.x.x.x/tftpboot/pxelinux.cfg,
although in logs it says "Created pxelinux config 'rear-xxxx' and
symlinks for IP adresses in
http://x.x.x.x/tftpboot/pxelinux.cfg".
But when I am changing it to nfs share at:
PXE_TFTP_URL=nfs://x.x.x.x/opt/rear/tftpboot
PXE_CONFIG_URL=nfs://x.x.x.x/opt/rear/tftpboot/pxelinux.cfg
then config files are creating but even then I still can not see rescue
image in pxe boot options.
gozora commented at 2017-04-28 17:05:¶
Maybe I got it all wrong (I never used ReaR with PXE), but is "rescue
image" created with PXE at all?
Shouldn't PXE just provide initrd and kernel for client booting?
V.
sko341 commented at 2017-04-28 17:17:¶
@gozora you are right, PXE is just providing initrd and kernel for client booting.
sko341 commented at 2017-04-28 20:45:¶
I am able to boot from PXE, now rear recover is failing with following
error:
ERROR: Mount command 'Mount -v -t nfs -o rw,noatime x.x.x.x:/opt/rear
/tmp/rear.vBU7wCBHSxHI51f/outputfs failed.
Also, i can not ping to nfs server, looks like network is not working,
but i can boot via PXE (network works in this case) . Any help please!
gozora commented at 2017-04-28 21:09:¶
Again just a guess, 'ifconfig <dev_name> inet <ipaddress>
netmask 255.0.0.0;rear recover`
sko341 commented at 2017-04-28 21:16:¶
Thanks @gozora that didnt help.
forgot to mention, I am trying to create rescue image for physical
server (successful) and then PXE booting to Virtual machine (physical to
virtual migration), and PXE booting is also working but while recover it
shows network unreachable, i guess this is some kind of driver issue.
But how to fix it, any help!
gozora commented at 2017-04-28 21:21:¶
Do you see some network interfaces in ifconfig -a output?
sko341 commented at 2017-04-28 21:24:¶
yes, it say UP. But i cannot even ping to gateway.
gozora commented at 2017-04-28 21:27:¶
Can you paste output here?
sko341 commented at 2017-04-28 21:47:¶
please see here:
gozora commented at 2017-04-28 21:54:¶
Ok try, ifconfig eth6 inet <ipaddress> netmask 255.0.0.0; rear recover
gozora commented at 2017-04-28 22:03:¶
Thinking of it, you might really have drivers missing when
migrating...
Try to search ReaR issues for "howto include modules" to recovery
system.
schlomo commented at 2017-05-01 13:58:¶
I would be surprised at a driver problem as you actually see a NIC in
the VM. Do you use DHCP on the physical server? If so then maybe there
was an issue picking that up. To check try to add USE_DHCLIENT=y and
create a new rescue system to force the rescue system to use DHCP.
I would also expect the rescue system to take you through the network reconfiguration where you would have to choose the network card.
sko341 commented at 2017-05-01 21:46:¶
@gozora "ifconfig eth6 inet
sko341 commented at 2017-05-02 00:03:¶
and here is error message if i am trying recover on same physical
server:
any help...
icebal commented at 2017-05-05 21:00:¶
See issue #214 on this. SLES has a patched version of mkisofs and causes issues with uefo. The current solution is located at this link: http://www.it3.be/2015/10/27/uefi-iso-boot-with-ebiso/
gdha commented at 2017-05-09 11:31:¶
@SuneelOad Are your questions answered?
sko341 commented at 2017-05-10 19:53:¶
@gdha nope, still trying to solve the issue :(
icebal commented at 2017-05-11 00:15:¶
@SuneelOad you can also try with installing xorriso and run rear
mkbackup -v and see if it is throwing the flag USING_EFI_BOOTLOADER=1.
if it is, it is creating a efi compatible disk. if it is not, you can
set it manually in the config.
edit - this is for ISO, not PXE like you are trying, my bad....
sko341 commented at 2017-05-12 16:42:¶
After running rear -v recover i am getting this error:
Any help, Please!
gozora commented at 2017-05-12 17:06:¶
Hello @SuneelOad,
2 things ...
-
In my copy of ReaR (cloned from upstream) I have 220_install_elilo.sh instead of yours 620_install_elilo.sh, did you somehow modify your copy of ReaR ?
-
Do you have file called /sbin/elilo on your original system?
V.
sko341 commented at 2017-05-12 17:10:¶
Hi @gozora:
- I got rear from git: git clone https://github.com/rear/rear.git, and i didn't modified anything other than local.conf file.
- yes, I have /sbin/elilo in my original HP Proliant server running SLES 11.4
Thanks
sko341 commented at 2017-05-12 23:02:¶
Does REAR work with PXE ( HP proliant running sles 11.x) , anyone tried?
sko341 commented at 2017-05-13 00:02:¶
tried to restore on same server but still getting same error while rear recover, as above : "Error: could not find elilo executables". Pasting local.conf again:
OUTPUT=PXE
OUTPUT_PREFIX_PXE=$HOSTNAME
BACKUP=NETFS
BACKUP_URL=nfs://x.x.x.x/opt/rear
PXE_TFTP_URL=nfs://x.x.x.x/tftpboot
PXE_CONFIG_URL=nfs://x.x.x.x/tftpboot/pxelinux.cfg
ISO_MKISOFS_BIN=/usr/bin/ebiso
USE_DHCLIENT=y
Any help!
gdha commented at 2017-05-13 05:54:¶
@SuneelOad I wouldn't know why PXE booting wouldn't work on HPE Proliant systems. The rear config looks OK to me, and I guess that PXE booting works? Or am I wrong?
Could you paste the output of head /var/lib/rear/recovery/* ?
You could run once rear -dDv mkrescue and verify the rear log to see
whether the elilo executable was copied to the rescue image, and to
double check you can do a find /tmp/rear.xxxx -name elilo (replace the
xxxx with what you see in the rear output at the end)
razorfish-sl commented at 2017-05-13 22:23:¶
you may need more information.
WHICH proliant & WHICH gen.
I'm having issues with proliant now........ not even got as far as you.
jsmeix commented at 2017-05-15 09:21:¶
@gozora
regarding things like
220_install_elilo.sh versus 620_install_elilo.sh
see
https://github.com/rear/rear/issues/1331
and
https://github.com/rear/rear/pull/1323
therein
https://github.com/rear/rear/pull/1323#issuecomment-298067993
and the matching commit
https://github.com/rear/rear/pull/1323/commits/968a6bcea58e7687f9b56774b1bf06cbb8ca00b1
gozora commented at 2017-05-15 10:27:¶
@jsmeix, Yes stupid me did not read message after git pull so I
thought that I'm working with most recent version ...
You asked to pull from the remote 'rear', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
Thanks!
V.
sko341 commented at 2017-05-15 23:13:¶
Thank you all for your help, I can now restore and server is working
fine after restore :) only change i made was to download rear packages
from
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/SLE_12_SP1/x86_64/
, rather than using git clone.
So far, I can backup/restore from Physical to Physical (HP Proliant
DL380 G9: P2P) and from Virtual to Virtual (V2V), but I still have
problems in P2V. In this case restore is finished successfully but when
reboots, it says no OS found, any help here is appreciated. Thanks
jsmeix commented at 2017-05-16 07:23:¶
@SuneelOad
your above
https://github.com/rear/rear/issues/1335#issuecomment-301630756
looks somewhat scaring because it means that
some older ReaR version works for you while
the current ReaR GitHub master does no longer work for you
i.e. it looks like a regression somewhere in the current ReaR.
Under
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/SLE_12_SP1/x86_64/
there is
ebiso-0.2.5-1.x86_64.rpm
plus several ReaR versions
rear-1.17.2-1.x86_64.rpm
rear-1.18-3.x86_64.rpm
rear-1.19-2.x86_64.rpm
rear-2.00-1.x86_64.rpm
Which exact ReaR version does work for you?
Regarding P2P and V2V works while P2V does not work:
I guess with P2P and V2V you run "rear recover"
on the same physical or virtual hardware as
what you used for "rear mkbackup".
In contrast for P2V you do a system migration
from some physical hardware where "rear mkbackup" was run
to some (obviously different) virtual hardware where "rear recover"
is run.
In general system migration with ReaR is tricky, cf.
https://github.com/rear/rear/issues/1155#issuecomment-271236931
sko341 commented at 2017-05-16 16:05:¶
@jsmeix
I installed ebiso-0.2.5-1.x86_64.rpm and rear-2.00-1.x86_64.rpm, which
worked for me. On physical server I reinstall OS from SLES 11.4 to SLES
12.2 and installed above rpm packages rather than git, and it worked
(P2P).
On Virtual server (running SLES 11.4) , i didnt do any change other than
installing above rpm packages without git clone, and that worked too
(V2V).
And thanks for P2V link, I'll give that a try.
Thanks
gozora commented at 2017-05-16 18:21:¶
@jsmeix
looks somewhat scaring because it means that
some older ReaR version works for you while
the current ReaR GitHub master does no longer work for you
i.e. it looks like a regression somewhere in the current ReaR.
I just successfully finished test recovery of my SLES11 SP3 with latest
upstream commit 8ce891f .
So I don't think any regression was introduced.
Following configuration was used:
BACKUP=NETFS
OUTPUT=ISO
BACKUP_URL=nfs://beta/mnt/rear
OUTPUT_URL=nfs://beta/mnt/rear/iso
ONLY_INCLUDE_VG=( "vg00" )
EXCLUDE_BACKUP=( ${EXCLUDE_BACKUP[@]} fs:/crash fs:/usr/sap fs:/oracle )
BACKUP_PROG_EXCLUDE=( ${BACKUP_PROG_EXCLUDE[@]} '/mnt/*' )
ISO_MKISOFS_BIN=/usr/bin/ebiso
EXCLUDE_MD=( $(grep -o -E '^md[0-9]+' /proc/mdstat) ) # exclude all md devices
GRUB_RESCUE=n
COPY_AS_IS=( ${COPY_AS_IS[@]} /sbin/sysctl /etc/sysctl.conf /sbin/vconfig /sbin/if* /etc/sysconfig/network /sbin/shutdown.wrap )
@SuneelOad
So far, I can backup/restore from Physical to Physical (HP Proliant DL380 G9: P2P) and from Virtual to Virtual (V2V), but I still have problems in P2V. In this case restore is finished successfully but when reboots, it says no OS found, any help here is appreciated.
During your P2V recovery, are your source and destination servers using SAME boot method (UEFI/Legacy boot) ?
V.
sko341 commented at 2017-05-16 19:53:¶
@gozora no both are different boot methods, i.e. physical uses UEFI and VM is grub.
Thanks,
gozora commented at 2017-05-16 20:01:¶
@SuneelOad
As far as I know, ReaR can't handle restores from UEFI to legacy boot
(grub) and vice versa.
(@schlomo, @gdha, @jsmeix correct me if I'm wrong)
You'd need to do some manual "magic" to make such migration work ...
V.
jsmeix commented at 2017-05-17 09:13:¶
Changing the bootloader is another "migration" thing
that cannot work automatically - as far as I can imagine -
because re-installing the bootloader on the recreated system
happens after backup restore (during the 'finalize' stage)
by using the restored bootloader config files from the backup
to that changing the bootloader on the recreated system
requires changes of the bootloader config files and that
does not happen by ReaR.
This means - as far as I can imagine - changing the bootloader
on the recreated system must be done manually from within
the still running ReaR recovery system after "rear recover"
had finished.
I think this can be done basically in the same way
as I do it in my script for
"Generic system installation with the plain SUSE installation system"
in
https://en.opensuse.org/SDB:Disaster_Recovery
For example after adapting the restored bootloader config files
the actual bootloader installation could be done via something
like (replace "/dev/sdXn" as needed):
target_system_filesystem_root="/mnt/local" bootloader_install_device="/dev/sdXn" # Make /proc /sys /dev from the installation system # or from the ReaR recovery system # available in the target system: for mountpoint_directory in proc sys dev do mkdir $target_system_filesystem_root/$mountpoint_directory done mount -t proc none $target_system_filesystem_root/proc mount -t sysfs sys $target_system_filesystem_root/sys mount -o bind /dev $target_system_filesystem_root/dev # Make initrd verbosely in the target system: chroot $target_system_filesystem_root /bin/bash --login -c "/sbin/mkinitrd -v" # Install bootloader in the target system: # Make bootloader configuration in the target system: chroot $target_system_filesystem_root /bin/bash --login -c "/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg" # Install bootloader in the target system: chroot $target_system_filesystem_root /usr/sbin/grub2-install --force $bootloader_install_device
That has worked for me on SLES12 on a simple virtual machine.
On SLES11 things are probably a bit different and
on HP ProLiant hardware things are perhaps even more different.
As far as I know the only part of a system migration where
ReaR has some (limited) support is disk layout migration.
In particular migrating from a single disk to a bigger single disk
should usually work (except some exceptions ;-)
But I think one cannot expect that e.g. migrating from
one single 600 GiB traditional spinning harddisk
to two 400 GiB SSDs will "just work" automatically
or the other way round migrating a LVM setup
that uses several traditional spinning harddisks
to a single big virtual disk on a virtual machine.
jsmeix commented at 2017-05-17 12:05:¶
I tested my above
https://github.com/rear/rear/issues/1335#issuecomment-302032824
and adapted it so that it now works for me one SLES12-SP2
because I found out that I need some adaptions,
mainly I need sometimes a bash login shell for 'chroot' i.e.
chroot $target_system_filesystem_root /bin/bash --login -c "..."
cf.
https://github.com/rear/rear/issues/862
and
https://github.com/rear/rear/pull/1171
and the resulting problems and bad consequences
https://github.com/rear/rear/issues/862#issuecomment-274068914
https://github.com/rear/rear/issues/862#issuecomment-282039428
https://github.com/rear/rear/pull/1345#issuecomment-299798204
Furthermore I tried to avoid that "rear recover" installs
a bootloader at all but it seems that is not easily possible
because setting in the recovery system in local.conf
NOBOOTLOADER=1
and also in the recovery system
# mv /var/lib/rear/recovery/bootloader /var/lib/rear/recovery/bootloader.orig
did not avoid that "rear recover" installs a bootloader
GRUB2 in my case via finalize/Linux-i386/620_install_grub2.sh
gdha commented at 2017-08-16 09:21:¶
@sko341 is your question answered sufficiently or do you still have other concerns at this point in time?
Hardcore-fs commented at 2018-01-18 09:22:¶
lets close it for now
[Export of Github issue for rear/rear.]