#858 Issue closed: some latest commit(s) make rear fail to launch the recovery system on SLE12¶
Labels: support / question, not ReaR / invalid
jsmeix opened issue at 2016-06-02 15:51:¶
Latest rear master on a SLE12-SP1
x86_64 kvm/qemu virtual machine with BIOS:
Some Git commit after the Git commit
bd3d2ac41c7ed04352abd28de16b9493aff40683
result that the rear recovery system hangs up
during its startup phase so that it never reaches
the shell prompt (where one would log in as root
and run "rear recover").
I.e. it boots but then during (I guess systemd's)
startup procedure it hangs up.
The Git commit
bd3d2ac41c7ed04352abd28de16b9493aff40683
is the last one which I have in my rear118a RPM package on
https://build.opensuse.org/package/show/home:jsmeix/rear118a
which works on my above mentioned SLE12-SP1 machine.
My problem is that I have no clue how I could debug
such kind of low-level issues when I even cannot log in
at the rear recovery system.
@gdha
could you help me how to debug such issues?
gdha commented at 2016-06-03 07:51:¶
@jsmeix Do you have an idea in which stage it hangs? What was the last
line you saw on the screen?
From which media did you boot (iso or ramdisk)?
Most changes were on UEFI (not your area of testing), multipath (not
used in your case I think?), BACKUP schemes checks, perhaps the
skel/default/etc/scripts/run-sshd modifucation?
Otherwise, try a dirdiff between the last good base and the master?
jsmeix commented at 2016-06-03 09:43:¶
I will provide a screenshot soon...
I boot my virtual kvm/qemu machine from
its virtual CD-ROM drive where I have
in the host system the rear-
connected to the virtual CD-ROM drive.
In this case here (not too many commits)
I can (and will) do a bisecting until I found
the commit that makes it fail.
jsmeix commented at 2016-06-03 11:11:¶
Screenshot:
gdha commented at 2016-06-03 11:27:¶
@jsmeix perhaps check https://github.com/rear/rear/pull/844 commit.
jsmeix commented at 2016-06-03 15:06:¶
After several futile attemts to find an older commit
where it works again I come to the conclusion
that something got somehow messed up
on my test system.
On a new from scratch installed SLES12-SP1 system
(same kind of kvm/qemu virtual machine)
everything "just works" with the current master.
Accordingly I close the issue as "false alarm".
@gdha
many thanks for your time!
FYI:
If I remember correctly this is the second time
where rear failed on a test system after many tests.
I have the dim feeling it is relatively easily possible
to somehow mess up rear or even something in
the system when doing a lot to and fro with rear.
Of course I cannot reproduce reight now what
exactly got somehow messed up.
[Export of Github issue for rear/rear.]