#1592 Issue `closed`: Restore from burned ISO fails at or soon after "Running mkinitrd"¶

Labels: support / question, won't fix / can't fix / obsolete

exedor opened issue at 2017-11-22 04:10:¶

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): 2.1 through latest github
OS version (cat /etc/rear/os.conf or lsb_release -a): Fedora 26
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
/etc/rear/local.conf:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=iso://backup
OUTPUT_URL=file:///home/exedor/images/
ISO_MAX_SIZE=4400
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}"
'/backup'
'/home/exedor/images' )
COPY_AS_IS_EXCLUDE=( ${copy_as_is_exclude[@]}
'/backup'
'/home/exedor/images' )
Are you using legacy BIOS or UEFI boot?
Legacy BIOS
Brief description of the issue:
The ISO image is created. When I burn it to disk and then try and use it, the restore process gets to "Running mkinitrd..." and then gets stuck and does not proceed. There is no activity of any kind from system LEDs. It just gets stuck. I left it that way for a half hour, just to be sure.
Work-around, if any:
USB backup and restore works flawlessly so right now, that's the work around.

gdha commented at 2017-11-22 07:26:¶

@exedor Could you see in a second window what it was doing at that time? And, could you paste the last lines from the rear.log?

gdha commented at 2017-11-29 19:08:¶

I just restored a fedora 26:

Restored 3543 MiB in 191 seconds [avg. 18997 KiB/sec]
Restoring finished.
Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group
Patching '/mnt/local/etc/default/grub' instead of 'etc/sysconfig/grub'
Running mkinitrd...
Updated initrd with new drivers for kernel 4.11.12-100.fc24.x86_64+debug.
Running mkinitrd...
Updated initrd with new drivers for kernel 4.11.12-100.fc24.x86_64.
Running mkinitrd...
Updated initrd with new drivers for kernel 4.13.15-100.fc25.x86_64+debug.
Running mkinitrd...
Updated initrd with new drivers for kernel 4.13.15-100.fc25.x86_64.
Running mkinitrd...
Updated initrd with new drivers for kernel 4.13.15-200.fc26.x86_64+debug.
Running mkinitrd...
Updated initrd with new drivers for kernel 4.13.15-200.fc26.x86_64.
Skip installing GRUB Legacy boot loader because GRUB 2 is installed (grub-probe or grub2-probe exist).
Installing GRUB2 boot loader
Finished recovering your system. You can explore it under '/mnt/local'.

without any problems.

gdha commented at 2018-02-23 09:49:¶

We could not reproduce this problem the user had. No further feedback received - closing it - if needed it can be re-opened.

exedor commented at 2018-05-29 05:13:¶

OK, I'm finally getting back to this. I'm still having the same problem on several of the systems I'm trying to restore to. I have other systems with older Biostar motherboards and everything works fine. However I still get this behavior on a bunch of systems. The USB works great, but the ISO fails every time and hangs on this mkinitrd step. I have tried grabbing an alternate console and am unable to do so. What is the trick to making that work?

I can hit Ctrl-C and it tries to run mkinitrd again. Then I hit Ctrl-C again and then it finally stops. I've looked at the log before exiting and I'm not finding much that is useful. Can we re-open this?

jcarter3d commented at 2019-03-18 19:02:¶

I'm hitting this while trying to "rear recover" RHEL 7.6 images (on 10 machines).
Is there a work-around I can run after "rear recover" hangs on the "Running mkinitrd..." screen?

The previously mentioned work-arounds seem to be for those who which to build a new image. I'm just hoping to recover the images I already have for now.

exedor commented at 2019-03-20 19:06:¶

I'm happy someone else is finally running into this. We have gone to strictly USB image backup and restore and abandoned the much more cost effective option of using DVD disks. That at least kept us running while we work to address other far more pressing issues. Ever time I think I can get back to this to find root cause and provide more/better troubleshooting info to the devs, I get blind sided by some other urgent crisis :(

jsmeix commented at 2019-03-21 08:56:¶

@exedor
FYI two side notes regarding "USB image backup and restore":

See what the description about MIGRATION_MODE in default.conf
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/conf/default.conf
reads about "an ultimate disaster" that could happen when your USB disk
with your backup has same size as your target system harddisk, see
https://github.com/rear/rear/issues/1271
This issue is mitigated since ReaR 2.3 because since ReaR 2.3 there is
improved MIGRATION_MODE autodetection when the disk layout looks ambiguous
so that ReaR 2.3 is more fail-safe against recreating on a possibly wrong disk, cf.
http://relax-and-recover.org/documentation/release-notes-2-4

There is a general problem when the ReaR recovery system
was booted from a normal disk device like a USB disk, see
https://github.com/rear/rear/issues/1854

[Export of Github issue for rear/rear.]

#1592 Issue closed: Restore from burned ISO fails at or soon after "Running mkinitrd"¶