#1842 Issue closed: ReaR 2.4 and probably some earlier versions do no longer work on SLES10

Labels: documentation, fixed / solved / done

jsmeix opened issue at 2018-06-25 13:39:

  • ReaR version ("/usr/sbin/rear -V"):
    ReaR 2.4 and probably some earlier versions

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
    SLES10

  • System architecture (x86 compatible or POWER and/or what kind of virtual machine):
    x86 compatible (x86_64)

  • Are you using BIOS or UEFI or another way to boot?
    BIOS

  • Brief description of the issue:
    ReaR 2.4 and probably some earlier versions do no longer work on SLES10.

The ReaR recovery system ISO boot menue is not the "usual" one
where one can select boot entries via a ncurses-like UI with cursor keys,
instead it is a rather simple plain text thingy.
Manually typing rear makes it boot.

I get lots of LVM related entries in disklayout.conf
regardless that I have no LVM on my test system.
Most LVM related entries in disklayout.conf are commented
but some are active and that let "rear recover" fail.
Manually commenting all LVM related entries in disklayout.conf helps.

In diskrestore.sh there are non working parted calls (wrong syntax - easy to see).
Manually adapting them in diskrestore.sh helps.

  • Work-around, if any:
    Enforcing migration mode via export MIGRATION_MODE=yes before rear recover
    and then manually adapting disklayout.conf and diskrestore.sh at the matching dialogs
    helps to make rear recover working successfully even on SLES10,
    at least on a simple SLES10 system as my test system
    with a single 20GiB disk with ext3 and DHCP networking.

jsmeix commented at 2018-06-25 13:45:

This issue is no bug in current ReaR because
since ReaR 1.17 we had dropped officially support for SLES10,
see the doc/rear-release-notes.txt diff in
https://github.com/rear/rear/commit/86009877e7ae15d768d9eb3b6d0e660118dfdf42

For the next ReaR 2.5 I will explicitly tell in its release notes
that it does not work on SLES10, see also
https://github.com/rear/rear/pull/1765#issuecomment-381520313
and in general see
https://github.com/rear/rear/issues/1390

gdha commented at 2018-06-25 15:07:

@jsmeix Perhaps, by the end of this year we can also drop builds on OBS of SLES10 and RHEL5 (as they are not supported anymore [officially])?

jsmeix commented at 2018-06-25 15:21:

@gdha
it is perfectly fine for me to no longer officially build for officially unsupported targets
because that avoids false expectations by the users.

Inofficially a user can download any latest ReaR package
and forcefully install that on his officially unsupported system, cf.
https://github.com/rear/rear/issues/1837#issuecomment-399076717
because ReaR is only bash scripts so that it should not matter
in practice for what specific version of a distribution it was built.

Alternatively a user can git clone our latest GitHub master code and
therein he can even go back step by step until a certain git commit
where that state still works on his officially unsupported system, cf.
https://github.com/rear/rear/issues/1841#issuecomment-399884811

jsmeix commented at 2018-09-27 15:07:

I documented in the release notes for the upcoming ReaR 2.5
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-5.md
that ReaR-2.4 (and probably also some earlier versions)
is known to no longer work reasonably well for SLES 9 and 10, cf.
https://github.com/rear/rear.github.com/commit/72ce3e18f5220055d7852ef18cf5341ec1f64125

[Export of Github issue for rear/rear.]