Red Hat Bugzilla – Bug 1539063
Cannot restore backup of system disk when using multipath+software raid
Last modified: 2018-10-30 07:44:02 EDT
Description of problem: Trying to restore a backup of a system booting with multipath + software raid, at the rescue prompt, after starting multipathd or executing "rear recover", the multipath devices are not found. This is due to mdadm building the array at boot, preventing multipath from grabbing the disks later. Version-Release number of selected component (if applicable): rear-2.00 How reproducible: Always Steps to Reproduce: 1. Setup a VM with 4 SCSI disks (2 images only to have multipath) 2. Install the system with rootvg on RAID1 on the 2 multipath disks 3. Create a rescue image ("rear mkrescue") 4. Boot the rescue image 5. Run "multipathd" and "multipath -l" Actual results: No multipath device listed Additional info: The workaround is to delete the md device: mdadm --stop /dev/mdX
The proposed workaround is not sufficient, because as soon as the disk is touched (e.g. via parted), the MD array will be rebuilt. The fix (on RHEL at least) is to disable the automatic array creationg udev rule /lib/udev/rules.d/65-md-incremental.rules by creating an empty file /etc/udev/rules.d/65-md-incremental.rules This can be done by appending "touch etc/udev/rules.d/65-md-incremental.rules" to /usr/share/rear/build/GNU/Linux/110_touch_empty_files.sh: # cat /usr/share/rear/build/GNU/Linux/110_touch_empty_files.sh ... touch etc/udev/rules.d/65-md-incremental.rules popd >&8
Pull Request: https://github.com/rear/rear/pull/1819
1539063 merged upstream in 2.4/89dbd45e1ad37f49421c7154813f972cb2b63a0e
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3293