#757 Issue `closed`: OS doesn't boot after recover¶

Labels: support / question

yunsr opened issue at 2016-01-18 09:38:¶

I could successfully created backup (mkbackup) of OS (SUSE 11 SP3 with rear-1.17.2-1) and sent to NFS share.

My site.conf:

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://#######/reear"
BACKUP_OPTIONS="nolock"
NETFS_KEEP_OLD_BACKUP_COPY=yes
ONLY_INCLUDE_VG=( vg0 )
AUTOEXCLUDE_MULTIPATH=n

I'm try to recover my system and recover ended successfully.

....fi;
    done < "${TMP_DIR}/backup.splitted"; kill -9 $(cat "${TMP_DIR}/cat_pid"); rm "${TMP_DIR}/cat_pid"; rm "${TMP_DIR}/backup.splitted"; rm "${TMP_DIR}/backup.md5";
fi )
/usr/share/rear/lib/_input-output-functions.sh: line 65: kill: (8294) - No such process
2016-01-15 14:49:19 Finished in 868 seconds
2016-01-15 14:49:19 Removing build area /tmp/rear.tqtCIeb4j8Oukef
rmdir: removing directory, `/tmp/rear.tqtCIeb4j8Oukef'
2016-01-15 14:49:19 End of program reached*

But in recover log I get the following errors:

*......2016-01-15 14:49:14 Installing GRUB boot loader


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename. ]
grub> device (hd0) /dev/mapper/mpatha
grub> root (hd0,-1)

**Error 11: Unrecognized device string
grub> setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0)**

Error 12: Invalid device requested
grub> quit
2016-01-15 14:49:14 Including finalize/Linux-i386/22_install_elilo.sh
2016-01-15 14:49:14 Including finalize/Linux-i386/22_install_grub2.sh
2016-01-15 14:49:14 Including finalize/Linux-i386/23_run_efibootmgr.sh
2016-01-15 14:49:14 Including finalize/GNU/Linux/30_create_mac_mapping.sh*

And in next step OS didn't boot from recovered system disk! (server boots in 'Red Screen' with illegal opcode)
If you can guide me the right direction, it would be much appreciated.

Thanks

gozora commented at 2016-01-18 09:43:¶

Hi,
Seeing "Red screen" term, I guess you are using some kind of HP(e) hw....

Try to boot system using Standard SLES11 ISO to Rescue mode, and trigger:

/usr/sbin/grub-install.unsupported <path_to_your_bood_disk>

yunsr commented at 2016-01-18 10:11:¶

Ok, but why Rear improperly setup bootloader?

gozora commented at 2016-01-18 10:15:¶

Not sure if this is fault of ReaR ...
I've faced something similar in the past (but only with particular Generation of HW), unfortunately I didn't had time for deeper investigation.

gdha commented at 2016-01-18 10:18:¶

The grub tries to setup a multipath device:

grub> device (hd0) /dev/mapper/mpatha

Is this correct?

yunsr commented at 2016-01-18 10:21:¶

yes it's correct

gdha commented at 2016-01-18 12:03:¶

I think grub does not understand /dev/mapper/mpatha - perhaps it should be /dev/disk/by-id/scsi-...
That could explain the error by grub

pavoldomin commented at 2016-01-18 12:45:¶

It's also worth testing with the recent snapshot version, as there were some improvements since the August version.

yunsr commented at 2016-01-18 14:50:¶

I think grub does not understand /dev/mapper/mpatha - perhaps it should be /dev/disk/by-id/scsi-...
That could explain the error by grub

it's seems to be true about grub. So we must to boot using Standard SLES11 ISO and reinstall bootloader after OS recover? there are no other options in rear to solve this issue?

gdha commented at 2016-01-19 08:03:¶

@yunsr SAN boot disks are not yet 100% fully integrated into rear. I cannot do it blindly without doing hands-on. If no-one do it for us then the community (customers) can buy time do implement this for them (remotely or on-site).

gdha commented at 2016-01-19 08:04:¶

@yunsr PS I have changed the title accordingly, if that was ok for you?

yunsr commented at 2016-01-19 08:31:¶

I have changed the title accordingly, if that was ok for you?

It's not true. We havn't Boot from SAN in our case. Boot partition reside on local disk but it was named as mpath device.

gdha commented at 2016-01-19 10:18:¶

@yunsr Check your cat /proc/cmdline output. To avoid internal disks being recognized as mpath devices add multipath=off to the initrd/kernel parameters

yunsr commented at 2016-01-20 11:35:¶

I think grub does not understand /dev/mapper/mpatha - perhaps it should be /dev/disk/by-id/scsi-...
That could explain the error by grub

Could you tell pls why after recovery OS ReaR:

in /mnt/local/boot/grub original device.map and menu.lst move to device.map.rearbak, menu.lst.rearbak. It's not correct configs
also rear changed /mnt/local/etc/sysconfig/kernel
How i can disable it ?

As solution was written script which was added to rear config with POST_RECOVERY_SCRIPT option.
This script recover original menu.lst,device.map,/etc/sysconfig/kernel and run grub-install
After that everything is okay, OS booted successfully

gdha commented at 2016-01-20 13:01:¶

The target disk device must be a different one then the original one. That is the reason why disk migration happens and therefore a different UUID is in use. Did you executed a diff and those 2 files?

yunsr commented at 2016-01-20 14:46:¶

The target disk device must be a different one then the original one. That is the reason why disk >migration happens and therefore a different UUID is in use.

I agree with you (or when restoring to a new disk will be new UUID).
Take another attempt and after recover used Rear generated device.map and menu.lst. Only run grub-install. System booted without any problems.

gdha commented at 2016-01-25 09:21:¶

@ypid Are your questions being answered? If yes, please close this issue. If not, tell us what is not yet clear.

ypid commented at 2016-01-25 09:22:¶

@gdha I did not open the issue 😉

gdha commented at 2016-01-25 10:03:¶

@yunsr Are your questions being answered? If yes, please close this issue.

[Export of Github issue for rear/rear.]

#757 Issue closed: OS doesn't boot after recover¶