#1710 Issue closed: Rescue system start hangup for RHEL 7.4 on PPC 64 LE Power8 BareMetal (Petitboot v1.4.4)

Labels: support / question, fixed / solved / done, special hardware or VM

mmeier9 opened issue at 2018-01-25 15:38:

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): Relax-and-Recover 2.3 / Git

  • OS version (cat /etc/rear/os.conf or lsb_release -a): Red Hat Enterprise Linux Server release 7.4 (Maipo) (it is RHEL 7.4 for ppc64 LE)

  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

  • Are you using legacy BIOS or UEFI boot? no. we have petitboot loader

  • Brief description of the issue: The backup works fine for both the iso and the tar file. The restore of the iso, however, boots and runs for a little bit but then stops at "Relax-and-Recover rescue system is ready", followed by "[OK] Found device /dev/hvc0]" and finally followed by "[OK] Started Initialize Rescue System" where it hangs forever.

  • Work-around, if any: none at this time...

Thanks in advance for any help you can provide on this issue.

jsmeix commented at 2018-01-25 16:07:

could you have a look what goes on here?

In particular I know nothing at all about "petitboot loader".
I guess the bootloader of the original system
is not related to this particular issue here.

schabrolles commented at 2018-01-26 09:04:

@mmeier9 could you confirm you are running RHEL 7.4 on a Power BareMetal ?
If yes, I'll try to replicate your setup to see if I got the same issue?

mmeier9 commented at 2018-01-26 12:21:

Yes, we are running RHEL 7.4 ppc64 le on a Power8 BareMetal which uses Petitboot v1.4.4 loader.

schabrolles commented at 2018-02-10 12:53:


I've reproduced the issue with CentOS 7.4 LE (should be the same for RHEL).
There some issue during startup when starting DBUS... (don't know why it failed in BareMetal, but not with PowerVM/KVM guest).

I need more time in order to find the root cause (and may some help around systemd/dbus)

jsmeix commented at 2018-02-12 10:39:

only FYI regarding "dbus in the ReaR recovery system" cf.
and subsequent comment.

mmeier9 commented at 2018-02-13 19:35:

@schabrolles, That's great you were able to reproduce the issue with CentOS 7.4 LE. I hope you find the root cause and a way to make the restore of the iso rescue system work. Thanks for your ongoing efforts.

schabrolles commented at 2018-02-27 11:27:

I finally finally succeed to make dbus working in recovery.
We just need to be sure that dbus user and group are created inside the recovery image.
=> Systemd is now working properly and can detect and startup the serial console automatically.

I just added the following in my local.conf

CLONE_GROUPS=( "${CLONE_GROUPS[@]}" "dbus" )
CLONE_USERS=( "${CLONE_USERS[@]}" "dbus" )

I think we should add the dbus user/group by default if they exisit... may be in usr/share/rear/prep/GNU/Linux/280_include_systemd.sh. What do you think ?

@mmeier9, just wait a bit before trying on your system... I found another bug related to grub2 when running in baremetal. (see PR #1742)

gdha commented at 2018-02-27 11:34:

@schabrolles adding dbus is a great idea (do it by default I would say)

schabrolles commented at 2018-02-27 12:03:

@gdha, thanks for your feedback

Do you mean we should add dbus user directly in /data/scripts/Linux/rear/usr/share/rear/conf/GNU/Linux.conf ?
Is it safe to add it here? I just wonder what happens if the user dbus is not present on the system?

gdha commented at 2018-02-27 16:49:

@schabrolles if the account is not present it will be skipped - as simple as that.

schabrolles commented at 2018-02-27 17:19:

Just waiting for @jsmeix quick review on those 2 PR before merging (I want to to avoid any side-effect)

schabrolles commented at 2018-02-28 12:33:

@mmeier9, all the changes are now merged into master.
Could you please check to validate?

schabrolles commented at 2018-05-08 07:18:

@mmeier9 ,

Any news? Could you please check if the new version of rear solves your issue?

mmeier9 commented at 2018-05-10 17:31:

Hello, I'm trying to get some downtime for our Power8 system to test the REAR utility that I just downloaded from the github master website. Thanks for your efforts. Will let you know how it goes once we get some time to test.

schabrolles commented at 2018-05-23 07:04:

@mmeier9 any news ?

mmeier9 commented at 2018-05-23 15:35:

Hi, I was able to test successfully with the new updated rear, on the Power 8 Baremetal server booting from the iso created by the rear mkrescue command.

I did not have the backup tar file available (lack of time to do this) to test the rear recover but I imagine that part will probably work.

One question...once the server booted from the Rear rescue iso file, I got the system prompt and logged in as root. When I issued "df -k" I did not see the filesystems as before...is that expected and will the filesystems/partitions something the rear recover execution would set up?

Thank you for your efforts and for solving the issue with the rescue iso not booting correctly!!

schabrolles commented at 2018-05-23 15:57:

@mmeier9 thanks for the feedback and having close this issue.

One question...once the server booted from the Rear rescue iso file, I got the system prompt and logged in as root. When I issued "df -k" I did not see the filesystems as before...is that expected and will the filesystems/partitions something the rear recover execution would set up?

df -k should show the bootable media fs, not the FS on your real disk...
Those FS (your FS) will be recreated by rear during the recovery (rear recover). Then the recreated layout will be mounted in /mnt/local and data will be restored. At the end of the process, you can have access to the /mnt/local FS in order to manually change some files (if needed) before rebooting.

[Export of Github issue for rear/rear.]