#22 Issue closed: Adjust /dev/disk/by-id/* after rear recover

Labels: enhancement

jhoekx opened issue at 2012-03-28 06:55:

From SF#2736744.

In the current SLES 10 SP2 at systems with e.g. HP smart array controller disks are mounted by persistent storage device names instead by device name, e.g.

/dev/disk/by-id/cciss-3600508b1001841554353423058520009-part1 /boot

instead of

/dev/cciss/c0d0p1

If REAR is used to recover a backup of this system to a almost identical system with a new hard drive (e.g. in case the disks are failed and replaced) the first reboot will fail because the persistent storage device names are not matching to the new disk.

REAR is aware of this and shows a message that you have manually adjust the settings in /etc/fstab and /boot/grub/menu.lst to match the new ID's.

Could you please add a feature that this settings are done by REAR after restore and before reboot?

proposal:

before Backup

Reported by Kai-Uwe Schurig

dagwieers commented at 2012-03-28 07:04:

I think it's safer to make Rear understand by-id entries and have them replace entries in /etc/fstab and /etc/grub.conf on-the-fly only during recovery. Rewriting by-id names to real devices is changing how a configuration is done on similar systems, and the proposal adds a separate interactive step which is unwanted.

Rear should do the right thing and make the configuration work in a similar setup it was working (in this case any reference to the old uuid should be replaced by the new uuid). A single search-and-replace by uuid would be safe enough (although I would add the relevant directories just as a safeguard ;-))

schlomo commented at 2012-03-28 16:52:

Or we just add mapping these kind of device names together with the disk
mapping. Might need some specialized handling for different distros as the
udev scripts are not standardized everywhere.

IMHO this would be the most user-friendly option.

hreif commented at 2012-07-25 10:55:

@schlomo: AFAIK This has been addressed with
dr/GNU/Linux/10_describe_diskbyid_mappings.sh
finalize/GNU/Linux/16_remove_diskbyid.sh
in 1.7.22d
But somehow those files went lost while integrating Heinlein P2V patches???

schlomo commented at 2012-07-27 09:09:

Yes, the merge process back then was a little bit messy. Please submit any
missing parts via our bug tracker, that would really help us a lot.

jhoekx commented at 2012-07-27 10:51:

The best way is to either create them as a gist and reference them here or add them to your github Rear fork and submit a pull request.

hreif commented at 2012-07-27 11:24:

Sorry to take the fast track lane. Its my last day.

I just send you the full RPM we are using so you can grab the mentioned
files

jhoekx commented at 2012-07-27 11:32:

Attachments do not work here.

My normal mail address can be found in my github profile. Same for the other contributors.

gdha commented at 2012-10-31 08:38:

@hreif did you mailed the RPM to Jeroen??

jhoekx commented at 2012-10-31 08:44:

Yes, I have it.

gdha commented at 2012-11-07 11:03:

@jhoekx were you able to inspect the diskbyid scripts? Are these usable?

jhoekx commented at 2012-11-07 11:37:

I briefly scanned them, but I don't remember them. I'll forward the mail to you.

gdha commented at 2012-11-07 19:04:

Added the scripts https://github.com/rear/rear/commit/ff879b6a399ca3be1c924292d2d8084ca85184f9

gdha commented at 2013-10-17 14:26:

Looks to me we can close this issue, no?

[Export of Github issue for rear/rear.]