First boot after restore on FC21 fails trying to find UUID originally generated by mkfs before tune2fs changes it #851
Description
- rear version (/usr/sbin/rear -V): rear-1.18-1.git201605271003
- OS version (cat /etc/rear/os.conf or lsb_release -a): Fedora 21
- rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
USB_RETAIN_BACKUP_NR=1
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}"
'/backup'
'/sys'
'/root/.ssh/known_hosts'
'/root/.ssh/known_hosts2'
'/root/.ccache'
'/root/.gem'
'/selinux'
'/var/cache/ccache'
'/var/cache/yum'
'/var/cache/man'
'/usr/local/src'
'/usr/share/doc'
'/usr/share/man'
'/usr/share/gtk-doc'
'/usr/share/info'
'/usr/src/*'
'/usr/lib/modules/3.8.13-ds'
'/var/log/messages'
'/var/log/maillog'
'/var/log/Xorg.0.log'
'/var/log/Xorg.0.log.old'
'/var/log/secure'
'/var/log/journal'
'/var/log/audit'
'/var/log/wtmp'
'/var/log/lastlog'
'/dev'
'/proc'
'/var/lib/rear/output' )
COPY_AS_IS_EXCLUDE=( ${copy_as_is_exclude[@]}
'/backup'
'/sys'
'/root/.ssh/known_hosts'
'/root/.ssh/known_hosts2'
'/root/.ccache'
'/root/.gem'
'/selinux'
'/var/cache/ccache'
'/var/cache/yum'
'/var/cache/man'
'/usr/local/src'
'/usr/share/doc'
'/usr/share/man'
'/usr/share/gtk-doc'
'/usr/share/info'
'/usr/src/*'
'/var/log/messages'
'/var/log/maillog'
'/var/log/Xorg.0.log'
'/var/log/Xorg.0.log.old'
'/var/log/secure'
'/var/log/journal'
'/var/log/audit'
'/var/log/wtmp'
'/var/log/lastlog'
'/dev'
'/proc'
'/var/lib/rear/output' )
USE_DHCLIENT=No
USE_STATIC_NETWORKING=Yes
TMPDIR="/home/sim/release-1-9-40/devel/install/images/temp"
- Brief description of the issue:
This is only a problem on a system with an identical disk drive. The initrd image of the restored system fails to boot after completing restore because it is still looking for the UUID's that were allocated when the filesystem was created and used prior to the call to tune2fs to change them back to what they were on the backed up system. This makes no sense unless something is monitoring the disk for changes and then automatically updating initrd but therein lies the mystery.
- Work-around, if any:
1: Let dracut go to its emergency shell (takes around 5 minutes)
2: Mount root file system somewhere
3: chroot to mounted root file system
4: mount /boot at its respective mount point
5: run dracut -f /boot/initrd_image_filename
6: reboot