#1627 Issue closed: Drive UUIDs didn't change after rear recover to the new hardware server

Labels: support / question, not ReaR / invalid

VitalySolntsev opened issue at 2017-12-07 15:44:

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): 1.17.2 and 2.2-5

  • OS version (lsb_release -a):
    LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch
    Distributor ID: CloudLinuxServer
    Description: CloudLinux Server release 6.9 (Igor Volk)

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

  • Are you using legacy BIOS or UEFI boot? Legacy SeaBIOS

  • Brief description of the issue:
    We have made rear backup on live hardware server with "rear -v mkbackup".
    After that, we restored it on other server in KVM environment.
    After restoration, the new server did not boot.
    It seems, that device UUIDs changed after booting, but not changed in configuration files.

boot2017-12-05-15-43-09

disklayout.conf.txt

  • Work-around, if any: Replace UUIDs for all local disks in files /mnt/local/etc/fstab and /mnt/local/boot/grub/grub.conf to mount points in format /dev/vda3, /dev/vda1 etc.

gozora commented at 2017-12-07 16:50:

@VitalySolntsev can you please paste here output of uname -o from your system ?

V.

VitalySolntsev commented at 2017-12-08 05:26:

uname -o
GNU/Linux
uname -a
Linux ourdomain 3.10.0-714.10.2.lve1.4.75.el6h.x86_64 #1 SMP Fri Nov 3 06:17:50 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

jsmeix commented at 2017-12-11 16:18:

@VitalySolntsev
I wonder why you think the UUIDs should change?

What normally has a UUID is only filesystems.

Normally there is no such thing as a "drive UUID"
except exceptional cases.

The filesystem UUID is set via mkfs commands
usually via the -U option.

During "rear mkrescue/mkbackup" the filesystem UUIDs
are saved in var/lib/rear/layout/disklayout.conf

During "rear recover" the filesystems (and swap) get
recreated with their saved UUIDs e.g. via command like

mkfs -t ... -U $old_uuid /dev/sda2
mkswap -U $old_uuid /dev/sda1

Accordingly when filesystems are referenced by UUID in
config files no adaptions should be needed in those files.

From your screenshot in your
https://github.com/rear/rear/issues/1627#issue-280177064
it is not clear to me why the kernel panic
is caused by wrong UUIDs.

In general regarding
"Debugging issues with Relax-and-Recover"
you may have a look at
https://en.opensuse.org/SDB:Disaster_Recovery

I.e. run "rear -d -D recover" and inspect the log file
what exactly happens regarding UUIDs in your case
and/or if something else looks suspicious that could
also let the kernel fail to run init.

gdha commented at 2017-12-11 16:41:

Is this not related to https://bugzilla.kernel.org/show_bug.cgi?id=60758 ?

jsmeix commented at 2017-12-12 10:09:

At least for now I set the "not ReaR" label to this issue
until there is evidence that the root cause is in ReaR.

VitalySolntsev commented at 2017-12-18 18:21:

It seems like in disklayout.conf
disklayout.conf.txt
UUIDs the same as in source system
fstab-from_source.txt
UUIDs setted correctly by tune2fs on target system
blkid-target

However, in l/etc/fstab and grub.com other UUIDs
fstab.txt
grub.conf.txt

Of course, with other UUIDs the system will not boot (it doesn`t matter with 3.1 or 2.6 kernel)
Why are other UUIDs used?
Which part in detailed log should I look for?

jsmeix commented at 2017-12-19 10:19:

@VitalySolntsev
off the top of my head I cannot explain
why in your case the recreated fstab
(i.e. /mnt/local/etc/fstab in the recovery system after "rear recover")
seems to be different compared to /etc/fstab on the original system.

For me on SLES12 both are identical:
Original system:

f48:~/rear.master # md5sum /etc/fstab
58d7d80046c13ad8159adbdf502fcfcb  /etc/fstab

On replacement hardware in the recovery system after "rear recover":

RESCUE f48:~ # md5sum /mnt/local/etc/fstab
58d7d80046c13ad8159adbdf502fcfcb  /mnt/local/etc/fstab

I see in your fstab files comments like

# HEADER: This file was autogenerated at ...
# HEADER: by puppet ...
...
# Created by anaconda on ...

with different dates in those comments
in your fstab on your original system
https://github.com/rear/rear/files/1568969/fstab-from_source.txt
compared to your other fstab
https://github.com/rear/rear/files/1568978/fstab.txt

I think this indicates that your other fstab is not the one
from your original system (because ReaR scripts won't
change the dates in those comments) but your other fstab
might be perhaps an outdated one in your backup?

You get all what there is in your backup restored
during "rear recover", cf. the comment about
BACKUP_RESTORE_MOVE_AWAY in default.conf
but it won't help to move away the restored fstab
because then you don't have any fstab (it is not recreated
from scratch by ReaR - the fstab is only adapted if needed).

I use neither puppet nor anaconda so that I cannot help
with such tools.
My blind guess is that perhaps those tools might somehow
interfere here?

The scripts in ReaR may modify files like fstab
and grub.conf at the end of "rear recover" are the
scripts of the 'finalize' stage, i.e. the scripts in
usr/share/rear/finalize

You may check in your "rear -D recover" log file
what the 'finalize' scripts do in your particular case.

Run "rear -s recover" to see what scripts are run
in your particular case.

jsmeix commented at 2017-12-20 14:26:

I close this issue because as far as I can imagine
the root cause is (with probability one) not in ReaR.
Of course the issue can be reopened when there is
some evidence that the root cause is acually in ReaR.

[Export of Github issue for rear/rear.]