#610 Issue closed: recovery iso image fails to boot on ibm powervm lpar

Labels: bug, support / question

harikum opened issue at 2015-07-03 16:11:

Environment: IBM PowerVM Lpar on Power8 hardware
OS: SLES11SP3
Rear 1.17.1

local.conf:

OUTPUT=ISO
BACKUP=NETFS
NETFS_URL=nfs://nfs_host/backup/rear/
BACKUP_PROG_INCLUDE=( '/' )
BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' '/var/lib/rear/output/*' '/media/*'  )

"rear -v mkbackup" runs successfully and creates the bootable iso and the backup.tar.gz file

however the lpar to be recovered is unable to boot from the 'rear-hostname.iso' image, message "no operating system found " is displayed on the console, no errors or any other references.

here is the output of rear validate on the system.

Version:     Relax-and-Recover 1.17.1 / Git
Validation:  SUSE_LINUX/11/ppc64
Submitted:   Hari Mahadevan hari@mahadevan.net USA
Date:        2015-07-03
Features:    ISO
Comment:     rescue disk fails to load ( SMS message "no operating system found message ", this occurs  when attempting to recover a SLES 11Sp3 lpar, The boot iso 'rear-hostname'.iso get created as part of 'rear -v mkbackup'

The same process works fine on a x86 vmware virtual machine.

Anything unique with the Power8 Lpars with SLES11Sp3?

appreciate your response.

jayfurmanek commented at 2015-07-06 04:44:

What is your storage? If you are booting from a SAN, you'll need to start with defining BOOT_FROM_SAN=y as well as AUTOEXCLUDE_MULTIPATH=n in your config file.

I could be wrong, but I bet your VMWare env is not the same. Many VMWare environments use a clustered file system and not an NPIV, multipath'd boot from SAN environment. Booting directly from the SAN from virtual fibre channel is a bit more complicated.

Any more details to share? Can you post the mkbackup log?

jayfurmanek commented at 2015-07-06 04:46:

Also, take a look at issue #572 . It might help you get your configuration set up correctly.

harikum commented at 2015-07-06 12:54:

EMC San Storage

I will test with BOOT_FROM_SAN=y and AUTOEXCLUDE_MULTIPATH=n options and update with the logs.

harikum commented at 2015-07-06 14:09:

updated the Rear local.conf to include options
BOOT_FROM_SAN=y
AUTOEXCLUDE_MULTIPATH=n

boot fails with an error message now..

IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM STARTING SOFTWARE IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM PLEASE WAIT... IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
Detected bad memory access to address: ffffffffffffffff
Package path = /packages/boot-mgr

                  .----------------------------------.
                  |  No Operating Systems Installed  |
                  `----------------------------------'

schlomo commented at 2015-07-06 16:41:

AFAIKT an LPAR is some kind of virtualized environment. Are you sure that the ISO that is built by ReaR is actually made for that? Can you try booting the hardware system from that ISO?

Also, are there other ways how to boot Linux on LPAR? For example by providing a kernel and initrd directly (like with XEN)? If yes, then I would advice to use that and not to rely on the "ISO" wrapping.

harikum commented at 2015-07-06 17:29:

Yes LPAR is a virtualised environment on IBM's Power hypervisor/hardware.

the ISO image was created by rear (rear -v mkbackup) and the same iso was mapped to a vSCSI device on the lpar, and the iso os the backing device that presents as a cdrom for the lpar.

the same process using an SLES 11 ISO was used to build the SLES 11 OS on the lpar. so the booting from the SLES ISO works fine.

schlomo commented at 2015-07-06 18:57:

I see. IMHO the fact that the vendor-shipped SLES11 ISO works unfortunately does not tell us anything about the ReaR ISO.

ReaR uses yaboot to make the ISO bootable, the code is in output/ISO/Linux-ppc64/30_create_yaboot.sh. PPC64 is not so wide spread and AFAIKT none of the ReaR developers has access to that.

Bottom line is that it might be that we cannot help you directly. I would, however, strongly advice to ask on the ReaR mailing list as there might be still some PPC64 users around. You might also search the GitHub issues for PPC and contact their authors directly.

And, I still think it would be interesting to know if the ReaR ISO works on the raw hardware. That test would help you to narrow down where to look further.

jayfurmanek commented at 2015-07-06 19:42:

I think we'll need the logs to see what is happening. I have access to ppc64 hardware, but I don't have a SAN to test on. The create_yaboot.sh script should work. It works for me using RHEL on ppc64 on local storage, anyway.

Also, schlomo, on ppc64 gear running PowerVM, you actually don't ever have access to the raw hardware. The hypervisor is in the firmware and OS's are always virtualized (LPAR'd). It's changed a bit with the new OpenPower servers though, which do have a raw hardware mode.

Can you post the rear/var/log/rear/rear-hostname-log file? That will tell us if it created the PReP partition at least.

schlomo commented at 2015-07-06 19:44:

Ah, good point. My PPC knowledge is indeed very outdated. Mostly from installing SUSE 7 on an old PowerPC Mac :-) But, yaboot was already state of the art back then.

jayfurmanek commented at 2015-07-06 19:50:

Always good to keep learning right? :) Yaboot was good for it's day, but grub2 has surpassed it in design and function. This is reflected in the latest distros for PPC (RHEL7, SLES12, Ubuntu) all moving to grub2 for the bootloader. The PReP partition still exists, however.

I've not tested REAR in a grub2 PPC distro yet. I'll have to do that and open any issues I find..

jayfurmanek commented at 2015-07-07 06:06:

I think I found the issue here - I haven't worked up a patch just yet though.
In SLES, the yaboot binary is at: /lib/lilo/pmac/yaboot, not in /etc/yaboot/yaboot like in Red Hat based distros.
The code in output/ISO/Linux-ppc64/30_create_yaboot.sh will need to account for the different location based on distro. The created ISO looks good otherwise, it's just missing the bootloader.

As a quick workaround, you can change line 23 to point to /lib/lilo/pmac/yaboot instead of /etc/yaboot/yaboot. That should get a working bootable ISO.

gdha commented at 2015-07-07 12:30:

@jayfurmanek perhaps make a special function like find_syslinux_file (usr/share/rear/lib/bootloader-functions.sh) for it like we did for finding syslinux executable.

jayfurmanek commented at 2015-07-07 14:33:

That's a good idea. That /lib/bootloader-functions seems like a good place for that, but looking in that file I see mostly syslinux related stuff. Any preference on where that function should live?

schlomo commented at 2015-07-07 14:40:

You can put it into the same file, just make sure that the function carries a self-explanatory name.

jayfurmanek commented at 2015-07-09 20:57:

harikum,

Can you try to check out the latest code and try again. The boot media should work now. On my system with local storage I can recover a SLES 11 system just fine now.

acsacpact commented at 2015-07-13 13:03:

I am also facing same issue, Yaboot file (/etc/yaboot.conf) not updated with rear iso and path of it.

can you please guide where I can get the latest code,so that I can try out.

acsacpact commented at 2015-07-13 13:56:

Can you share the latest code rpm for the suse 11 sp3 for PPC64.. I could not able to make rpm from the source code.Getting below error and not able to get th git package rpm from the SLES 11 iso iamge also.

vwdcqv-uxapp140:~/rear-latest/rear-latest # make rpm
which: no git in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/ibm/java-ppc64-71/bin/)
rm -f rear-1.17.1-git201507130000.tar.gz
rm -f build-stamp
make -C doc clean
make[1]: Entering directory /root/rear-latest/rear-latest/doc' rm -f unconv.8 *.html *.xml make -C user-guide clean make[2]: Entering directory/root/rear-latest/rear-latest/doc/user-guide'
rm -f .html *.svg *.xml
make[2]: Leaving directory /root/rear-latest/rear-latest/doc/user-guide' make[1]: Leaving directory/root/rear-latest/rear-latest/doc'
== Validating scripts and configuration ==
find etc/ usr/share/rear/conf/ -name '.conf' | xargs -n 1 bash -n
bash -n usr/sbin/rear
find . -name '.sh' | xargs -n 1 bash -n
== Prepare manual ==
make -C doc man
make[1]: Entering directory /root/rear-latest/rear-latest/doc' make[1]: Nothing to be done forman'.
make[1]: Leaving directory `/root/rear-latest/rear-latest/doc'
Nothing to do.
== Building archive rear-1.17.1-git201507130000 ==
git checkout master
/bin/bash: git: command not found
make: ** [rear-1.17.1-git201507130000.tar.gz] Error 127

vwdcqv-uxapp140:/rear-latest/rear-latest # make install
which: no git in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/ibm/java-ppc64-71/bin/)
== Validating scripts and configuration ==
find etc/ usr/share/rear/conf/ -name '.conf' | xargs -n 1 bash -n
bash -n usr/sbin/rear
find . -name '.sh' | xargs -n 1 bash -n
== Prepare manual ==
make -C doc man
make[1]: Entering directory /root/rear-latest/rear-latest/doc' make[1]: Nothing to be done forman'.
make[1]: Leaving directory /root/rear-latest/rear-latest/doc' == Installing configuration == install -d -m0700 /etc/rear/ [[ ! -e /etc/rear/local.conf ]] && \ install -Dp -m0600 etc/rear/local.conf /etc/rear/local.conf make: [install-config] Error 1 (ignored) [[ ! -e /etc/rear/os.conf && -e etc/rear/os.conf ]] && \ install -Dp -m0600 etc/rear/os.conf /etc/rear/os.conf make: [install-config] Error 1 (ignored) find /etc/rear/ -name '.gitignore' -exec rm -rf {} \; &>/dev/null Nothing to do. == Installing binary == install -Dp -m0755 usr/sbin/rear /usr/sbin/rear sed -i -e 's,^CONFIG_DIR=.*,CONFIG_DIR="/etc/rear",' \ -e 's,^SHARE_DIR=.*,SHARE_DIR="/usr/share/rear",' \ -e 's,^VAR_DIR=.*,VAR_DIR="/var/lib/rear",' \ /usr/sbin/rear Nothing to do. == Installing scripts == install -d -m0755 /usr/share/rear/ cp -a usr/share/rear/. /usr/share/rear/ find /usr/share/rear/ -name '.gitignore' -exec rm -rf {} \; &>/dev/null == Installing working directory == install -d -m0755 /var/lib/rear/ install -d -m0755 /var/log/rear/ == Installing documentation == make -C doc install make[1]: Entering directory/root/rear-latest/rear-latest/doc'
install -Dp -m0644 rear.8 /usr/share/man/man8/rear.8
make[1]: Leaving directory `/root/rear-latest/rear-latest/doc'
sed -i -e 's,/etc,/etc,'
-e 's,/usr/sbin,/usr/sbin,'
-e 's,/usr/share,/usr/share,'
-e 's,/usr/share/doc/packages,/usr/share/doc,'
/usr/share/man/man8/rear.8
vwdcqv-uxapp140:/rear-latest/rear-latest #

harikum commented at 2015-07-13 14:06:

jay, no luck, i used the latest code for output/ISO/Linux-ppc64/30_create_yaboot.sh and still running into the same issue, unable to boot off the iso.

Detected bad memory access to address: ffffffffffffffff
Package path = /packages/boot-mgr
.----------------------------------.
| No Operating Systems Installed |
`----------------------------------'

jayfurmanek commented at 2015-07-13 14:51:

acsacpact,

Do you need to create the RPM? Why not just do a quick git clone and use that? Also, from your output, it looks like you need to install git.

jayfurmanek commented at 2015-07-13 15:03:

harikum,

Did you do a full checkout? The 30_create_yaboot.sh file is not the only file that changed. You'll have to generate a new ISO as well.

I never saw that error, though...but seeing as you are on Power8, maybe try explicitly putting the LPAR in Power7 compat mode. SLES 11 doesn't support Power8 until the next SP release.

acsacpact commented at 2015-07-13 17:08:

HI Jay,
Thanks for your quick response..
Can you guide me how i can get the quick git clone of it.. please help with steps.

Regards
Srinivasan AC

jayfurmanek commented at 2015-07-13 17:10:

install git from the OS's repositories, then do:
git clone https://github.com/rear/rear.git

Then you can run it from that directory.

acsacpact commented at 2015-07-13 17:32:

I have downloaded those files in zip format and moved to the server.. still getting below error.Can you please suggest on the same.

vwdcqv-uxapp140:/rear-latest/rear-latest # make rpm
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
rm -f rear-1.17.1-git201507130000.tar.gz
rm -f build-stamp
make -C doc clean
make[1]: Entering directory /root/rear-latest/rear-latest/doc' rm -f unconv.8 *.html *.xml make -C user-guide clean make[2]: Entering directory/root/rear-latest/rear-latest/doc/user-guide'
rm -f .html *.svg *.xml
make[2]: Leaving directory /root/rear-latest/rear-latest/doc/user-guide' make[1]: Leaving directory/root/rear-latest/rear-latest/doc'
== Validating scripts and configuration ==
find etc/ usr/share/rear/conf/ -name '.conf' | xargs -n 1 bash -n
bash -n usr/sbin/rear
find . -name '.sh' | xargs -n 1 bash -n
== Prepare manual ==
make -C doc man
make[1]: Entering directory /root/rear-latest/rear-latest/doc' make[1]: Nothing to be done forman'.
make[1]: Leaving directory `/root/rear-latest/rear-latest/doc'
Nothing to do.
== Building archive rear-1.17.1-git201507130000 ==
git checkout
fatal: Not a git repository (or any of the parent directories): .git
make: ** [rear-1.17.1-git201507130000.tar.gz] Error 128
vwdcqv-uxapp140:/rear-latest/rear-latest # ls -lrt
total 68
drwxr-xr-x 4 root root 4096 Jul 9 09:05 usr
drwxr-xr-x 6 root root 4096 Jul 9 09:05 packaging
drwxr-xr-x 4 root root 4096 Jul 9 09:05 etc
drwxr-xr-x 4 root root 4096 Jul 9 09:05 doc
-rw-r--r-- 1 root root 8601 Jul 9 09:05 README.adoc
-rw-r--r-- 1 root root 8998 Jul 9 09:05 Makefile
-rw-r--r-- 1 root root 18010 Jul 9 09:05 COPYING
-rw-r--r-- 1 root root 91 Jul 9 09:05 AUTHORS
-rw-r--r-- 1 root root 36 Jul 9 09:05 .gitignore
vwdcqv-uxapp140:~/rear-latest/rear-latest #

acsacpact commented at 2015-07-13 17:32:

I dont have the direct access to internet from the system,its via proxy

vwdcqv-uxapp140:~/rear-latest/rear-latest # git clone https://github.com/rear/rear.git
Cloning into 'rear'...

fatal: unable to access 'https://github.com/rear/rear.git/': Failed connect to github.com:443; Operation now in progress
vwdcqv-uxapp140:~/rear-latest/rear-latest #

jayfurmanek commented at 2015-07-13 17:41:

Not to be mean, but this log is for issue #610 and is probably not place for these basic questions.

You don't need to make the the RPM, nothing needs compiled, just use REAR from that very directory. (./usr/sbin/rear)

acsacpact commented at 2015-07-13 17:56:

I understand its very basic questions and I already installed stable version (rear-1.17.1-1) and did the rear -v mkbackup and it completed successfully. But when I try to reboot and test the recover, yaboot not even showing the rear recovery in boot image list.. then I found this issue link and suggested to get latest code(rear-1.18) but I could able to get the rpm

please help to get it resolve the issue. Shall I remove the rear-1.17.1-1 package from the linux system and how I can install the rear-1.18 and do the backup again and test the recovery.

I am new to this Linux platform, If there some basic please excuse me.

jayfurmanek commented at 2015-07-13 18:13:

acsacpact commented at 2015-07-13 18:44:

Thanks.. its portable package can be run without installing.. Now I understand...;)

And I have below configuration on the local.conf file. Do I need update anything else to update the /etc/yaboot.conf to get the my rear boot image on it? because I don’t see rescue boot image, how we see it on x86_64 hardware( /boot/grub/menu.lst)..

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.192.115.12/as400linux-backup/backup-quality140/"
BACKUP_PROG_INCLUDE=( '/' )
BACKUP_PROG_EXCLUDE=( '/tmp/' '/dev/shm/' '/var/lib/rear/output/' '/media/' '/as400linux-backup/*' )
BOOT_FROM_SAN=y
AUTOEXCLUDE_MULTIPATH=n

acsacpact commented at 2015-07-13 19:03:

When I check the rear step by step option ,could see the "/rear-latest/rear-latest/usr/share/rear/output/ISO/Linux-ppc64/30_create_yaboot.sh" file, but look like it not getting executing it..

Source output/ISO/Linux-ppc64/30_create_yaboot.sh
Source output/ISO/Linux-ppc64/80_create_isofs.sh

acsacpact commented at 2015-07-13 19:15:

On the latest master.zip files, still i could see the following Linux-ppc64.conf file referen to the wrong path of yaboot command. Can you check and suggest on the same.

usr/share/rear/conf/Linux-ppc64.conf:/usr/lib/yaboot/yaboot
usr/share/rear/conf/Linux-ppc64.conf:/usr/lib/yaboot/ofboot
usr/share/rear/conf/Linux-ppc64.conf:/usr/lib/yaboot/yaboot.debug
usr/share/rear/conf/Linux-ppc64.conf:/usr/lib/yaboot/addnote

vwdcqv-uxapp140:/rear-latest/rear-latest # usr/sbin/rear -v mkbackup
Relax-and-Recover 1.17.1 / Git
Using log file: /root/rear-latest/rear-latest/var/log/rear/rear-vwdcqv-uxapp140.log
Creating disk layout
Creating root filesystem layout
TIP: To login as root via ssh you need to set up /root/.ssh/authorized_keys or SSH_ROOT_PASSWORD in your configuration file
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Creating initramfs
Making ISO image
Wrote ISO Image /root/rear-latest/rear-latest/var/lib/rear/output/rear-vwdcqv-uxapp140.iso (74M)
Copying resulting files to nfs location
Encrypting disabled
Creating tar archive '/tmp/rear.d9VJn2WVZ1cq2g6/outputfs/vwdcqv-uxapp140/backup.tar.gz'
Archived 2121 MiB [avg 6664 KiB/sec]OK
Archived 2121 MiB in 327 seconds [avg 6643 KiB/sec]
vwdcqv-uxapp140:/rear-latest/rear-latest #

jayfurmanek commented at 2015-07-13 20:00:

It looks like it's finding a yaboot on your system. What is the contents of the generated ISO? Is there a yaboot binary on it?

acsacpact commented at 2015-07-14 08:50:

This is what shows in the ISO...

server name:/tmp # cd /reariso/
server name:/reariso # ls -lrt
total 74387
-rw-r--r-- 1 root root 20574055 Jun 14 2013 kernel
-rw------- 1 root root 411830 Jul 13 20:33 yaboot
drwx------ 3 root root 2048 Jul 13 20:33 ppc
-rw-r--r-- 1 root root 55180934 Jul 13 20:33 initrd.cgz
drwx------ 2 root root 2048 Jul 13 20:33 etc
vwdcqv-uxapp140:/reariso # cat etc/yaboot.conf
init-message = "\nRelax-and-Recover boot\n\n"
timeout=100
default=Relax-and-Recover

image=kernel
label=Relax-and-Recover
initrd=initrd.cgz
append=" root=/dev/ram0 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=hvc0 selinux=0"

server name:/reariso #

acsacpact commented at 2015-07-14 16:53:

Can you let me know how to fix the issue.

Regards
Srini

jayfurmanek commented at 2015-07-14 17:42:

Your ISO looks ok to me. Does it boot?

acsacpact commented at 2015-07-14 18:13:

I dont want to test this ISO, I need to boot the same LAPR into rear recover mode to test the backup.tar.gz can be restored on the same server.

How in the x86 hardware, when we add the GRUBRESCUE=y in the local.conf file, the rear -v mkbackup modify the /boot/grub/menu.lst with rear recover kernel option in that file and we can recover the system and restore the backup.tar.gz file to the same SuSE Linux system.

similarly I am looking option in the IBM Power LAPR that yaboot.conf file to get the another boot for the rear recover to restore the backup to the same LPAR.

Will this supported or not ?

or I need to boot from the rear ISO, then Only I can recover it even the Same server ?

harikum commented at 2015-07-14 23:59:

@jayfurmanek, Yes i did run a fresh 'mkback' to generate a new ISO after updating 30_create_yaboot.sh file.

my kernel version is '3.0.101-0.42.1.7881.0.PTF-default, this is updated on top of a SLES11SP3 build. I didn't have to modify the lpar definition switch to comparability mode to perform the original builds. Not sure why this will be required to recover?

jayfurmanek commented at 2015-07-15 07:14:

harikum,
The kernel will negotiate to Power7 mode, but the yaboot bootloader may be getting confused. Trying it with the entire LPAR set to Power7 mode might help with your problem.

jayfurmanek commented at 2015-07-15 07:18:

@acsacpact
There is no GRUBRESCUE=y option for yaboot in Rear. You've told Rear to create an ISO and it did.
You can recover using that ISO to the same LPAR or to a different one (assuming you are not mounting using UUIDs in the /etc/fstab, which SLES likes to do by default)

acsacpact commented at 2015-07-16 19:28:

@Jay,

After I reboot the system with my recovered image, getting below error. Can you suggest how to fix it

Something we need to do to fix the PRep boot image or the boot list.

IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
PReP-BOOT : Unable to load full PReP image.
Loaded 0 out of 64c00 bytes.

I have attached the rear -v recover output for the reference.

only below warning message in the below output.
"More than five entries cannot be specified in the bootlist"

RESCUE vwdcpv-uxapp131:~ # rear -v recover
Relax-and-Recover 1.17.1 / Git
Using log file: /var/log/rear/rear-vwdcpv-uxapp131.log
NOTICE: Will do driver migration
Calculating backup archive size
Backup archive size is 2.8G /tmp/rear.k7CO0G7gIOqpn5u/outputfs/vwdcpv-uxapp131/backup.tar.gz (compressed)
Comparing disks.
Disk configuration is identical, proceeding with restore.
Start system layout restoration.
Creating LVM PV /dev/mapper/36005076300810a318800000000000016
0 logical volume(s) in volume group "appvg" now active
Restoring LVM VG appvg
Creating partitions for disk /dev/mapper/36005076300810a318800000000000015 (msdos)
Creating swap on /dev/mapper/36005076300810a318800000000000015_part2
Creating ext3-filesystem / on /dev/mapper/36005076300810a318800000000000015_part3
Mounting filesystem /
Creating ext3-filesystem /usr/local on /dev/mapper/appvg-appvol
Mounting filesystem /usr/local
Disk layout created.
Decrypting disabled
Restoring from '/tmp/rear.k7CO0G7gIOqpn5u/outputfs/vwdcpv-uxapp131/backup.tar.gz'
Restored 9445 MiB [avg 72721 KiB/sec]OK
Restored 9445 MiB in 134 seconds [avg 72179 KiB/sec]
Installing PPC PReP Boot partition.
Boot partitions found: /dev/sda1
/dev/sdc1
/dev/sde1
/dev/sdg1
/dev/sdi1
/dev/sdk1
/dev/sdm1
/dev/sdo1
/dev/mapper/36005076300810a318800000000000015p1.
Initializing boot partition /dev/sda1.
Initializing boot partition /dev/sdc1.
Initializing boot partition /dev/sde1.
Initializing boot partition /dev/sdg1.
Initializing boot partition /dev/sdi1.
Initializing boot partition /dev/sdk1.
Initializing boot partition /dev/sdm1.
Initializing boot partition /dev/sdo1.
Initializing boot partition /dev/mapper/36005076300810a318800000000000015p1.
Boot device list is /dev/mapper/36005076300810a318800000000000015p
/dev/sda
/dev/sdc
/dev/sde
/dev/sdg
/dev/sdi
/dev/sdk
/dev/sdm
/dev/sdo.
More than five entries cannot be specified in the bootlist

WARNING ! You are mounting some devices by ID. Please be aware that the IDs
are hardware dependant and that you might have to adjust your fstab to match
the new IDs. Currently your system has the following disks with LUN IDs:
36005076300810a318800000000000015 /dev/sda 109568MB
36005076300810a318800000000000015 /dev/sda1 0MB
36005076300810a318800000000000015 /dev/sda2 2047MB
36005076300810a318800000000000015 /dev/sda3 107325MB
36005076300810a318800000000000016 /dev/sdb 109568MB
36005076300810a318800000000000015 /dev/sdc 109568MB
36005076300810a318800000000000015 /dev/sdc1 0MB
36005076300810a318800000000000015 /dev/sdc2 2047MB
36005076300810a318800000000000015 /dev/sdc3 107325MB
36005076300810a318800000000000016 /dev/sdd 109568MB
36005076300810a318800000000000015 /dev/sde 109568MB
36005076300810a318800000000000015 /dev/sde1 0MB
36005076300810a318800000000000015 /dev/sde2 2047MB
36005076300810a318800000000000015 /dev/sde3 107325MB
36005076300810a318800000000000016 /dev/sdf 109568MB
36005076300810a318800000000000015 /dev/sdg 109568MB
36005076300810a318800000000000015 /dev/sdg1 0MB
36005076300810a318800000000000015 /dev/sdg2 2047MB
36005076300810a318800000000000015 /dev/sdg3 107325MB
36005076300810a318800000000000015 /dev/sdi 109568MB
36005076300810a318800000000000015 /dev/sdi1 0MB
36005076300810a318800000000000015 /dev/sdi2 2047MB
36005076300810a318800000000000015 /dev/sdi3 107325MB
36005076300810a318800000000000016 /dev/sdh 109568MB
36005076300810a318800000000000016 /dev/sdj 109568MB
36005076300810a318800000000000015 /dev/sdk 109568MB
36005076300810a318800000000000015 /dev/sdk1 0MB
36005076300810a318800000000000015 /dev/sdk2 2047MB
36005076300810a318800000000000015 /dev/sdk3 107325MB
36005076300810a318800000000000016 /dev/sdl 109568MB
36005076300810a318800000000000015 /dev/sdm 109568MB
36005076300810a318800000000000015 /dev/sdm1 0MB
36005076300810a318800000000000015 /dev/sdm2 2047MB
36005076300810a318800000000000015 /dev/sdm3 107325MB
36005076300810a318800000000000016 /dev/sdn 109568MB
36005076300810a318800000000000015 /dev/sdo 109568MB
36005076300810a318800000000000015 /dev/sdo1 0MB
36005076300810a318800000000000015 /dev/sdo2 2047MB
36005076300810a318800000000000015 /dev/sdo3 107325MB
36005076300810a318800000000000016 /dev/sdp 109568MB
36005076300810a318800000000000015 /dev/dm-0 109568MB
36005076300810a318800000000000016 /dev/dm-1 109568MB
36005076300810a318800000000000016 /dev/dm-5 109468MB
36005076300810a318800000000000015 /dev/dm-2 0MB
36005076300810a318800000000000015 /dev/dm-3 2047MB
36005076300810a318800000000000015 /dev/dm-4 107325MB

Finished recovering your system. You can explore it under '/mnt/local'.

RESCUE vwdcpv-uxapp131:~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/36005076300810a318800000000000015_part3 104G 3.8G 99G 4% /mnt/local
/dev/mapper/appvg-appvol 106G 6.1G 95G 6% /mnt/local/usr/local

jayfurmanek commented at 2015-07-16 19:44:

ok, so the ISO worked and you got to the rescue shell..and the recover functioned.That's good.

Is this on a different system/LPAR than the original? SLES sets up fstab and bootloader config based on LUN UUID. If the LUNs are different, the UUIDs will be different. The WARNING in there is referring to that:

WARNING ! You are mounting some devices by ID. Please be aware that the IDs
are hardware dependant and that you might have to adjust your fstab to match
the new IDs. Currently your system has the following disks with LUN IDs:

Can you post the yaboot.conf you are using (the one that gets put on the recovered system)?

jayfurmanek commented at 2015-07-16 19:56:

@acsacpact
Can you open a new issue for this? You've verified that the fix for issue #610 does indeed work. It's likely you are having a multipath/SAN boot issue now. Thanks!

acsacpact commented at 2015-07-16 20:24:

@Jay,

After I do the automatic repair of the system while boot from the OS DVD, server booted normally now.. Thanks for the support..

I hope rear recover not writing the boot loader correctly to the disk.

jay commented at 2015-07-16 20:29:

@acsacpact Can you please not @jay , the github notification system requires the full username.

gdha commented at 2015-07-24 09:39:

@acsacpact can we close this issue?

acsacpact commented at 2015-07-24 13:27:

@gdha
Yes.. thank you

ihidouri commented at 2016-11-18 11:54:

hello, please I'm facing the same issue, and I'm trying to find the solution between all these comments...
My Power8 LPAR couldn't boot with ISo rear mkrescue (Detected bad memory access to address: ffffffffffffffff Package path = /packages/boot-mgr)

With vmware VMs have no problem.

Thank you

[Export of Github issue for rear/rear.]