#1822 Issue closed: Restore from burned ISO fails at or soon after "Running mkinitrd..."¶
Labels: support / question, fixed / solved / done
exedor opened issue at 2018-05-31 16:55:¶
Hello, I posted this a while back under issue #1592. I tried to reopen that one but couldn't. I'm still having the same problem even with the latest versions. It works on one of my platforms, but not on the rest of them. I'm happy to do what it takes to track down the problem, but there doesn't seem to be much info in the log files. It was suggested that I use an alternate "window" (I'm assuming that meant linux virtual console) while it is running. I tired switching to another virtual console when the restore hangs, but either none were active or the OS wouldn't let me do it at that time. If I hit Ctrl-C, it does stop and then try to run mkinitrd again but just immediately hangs at that step. If I hit Ctrl-C a second time, it finishes, but will not finish booting after the reboot.
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 but I would really like to get the ISO working. I'm pretty sure
it's hardware platform dependent. I have this problem on both a Gigabyte
GA-Q170M-D3H-GSM motherboard and an ASUS Prime H270M-PLUS.
jsmeix commented at 2018-06-05 13:44:¶
@exedor
without a "rear -d -D recover" debug log file
(at least the whole content after "Running mkinitrd...")
we cannot know what goes on on your particular system
in your particular environment, cf.
https://github.com/rear/rear/issues/1592#issuecomment-346265248
See "Debugging issues with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery
I don't know what
rear version (/usr/sbin/rear -V): 2.1 through latest github
actually is.
I recommend to use our current ReaR upstream GitHub master code
because that is the only place where we fix bugs - i.e. bugs in older
ReaR versions are not fixed by us (i.e. by ReaR upstream).
Bugs in older ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported)
by the Linux distributor wherefrom you got your older ReaR version.
To use our current ReaR upstream GitHub master code
do the following:
Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:
# git clone https://github.com/rear/rear.git # mv rear rear.github.master # cd rear.github.master # vi etc/rear/local.conf # usr/sbin/rear -D mkbackup
Note the relative paths "etc/rear/" and "usr/sbin/".
jsmeix commented at 2018-06-05 14:08:¶
@exedor
in current ReaR there is the config variable REBUILD_INITRAMFS, see
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2326
so that with REBUILD_INITRAMFS="no" you could explicitly skip
rebuilding the initramfs/initrd as a workaround for this issue.
When you do "rear recover" on fully compatible hardware it often works
without rebuilding the initramfs/initrd - then the initramfs/initrd
that was restored form the backup gets used (i.e. the exact same
initramfs/initrd that was used on the original system).
jsmeix commented at 2018-06-11 12:57:¶
@exedor
because of your "thumbs up" emoji I assume
the issue is sufficiently fixed for your particular case
so that I close it hereby.
It can be reopened if this particular issue is not yet fixed.
But new separated issues should be reported separatedly.
exedor commented at 2018-06-11 16:32:¶
No, not fixed. The thumbs up was that there was even a work-around available. Nevertheless, I do need to resolve the problem because I do restores to multiple platforms and the initrd generated for one doesn't work on the others.
I tried the latest git, but couldn't use it because it currently isn't resizing properly when restored into drives smaller than the original used to create the backup.
Sorry for the confusion. By "2.1 through latest github" I meant the affected rear versions are 2.1 through latest on github (or at least the latest usable.) I am currently running 2.3-1 stable RPM.
I'll get a log file and update the ticket.
jsmeix commented at 2018-06-12 07:26:¶
@exedor
we (i.e. at ReaR upstream) won't fix issues in released ReaR versions
so that you basically must use our current ReaR upstream GitHub master
code
if you like to get things properly fixed by us here.
I cannot understand what you mean with "currently isn't resizing
properly
when restored into drives smaller than the original used" because
I intentionally made major changes to the partition resizing code
in current ReaR upstream GitHub master code to avoid really bad
automated resizing results that had happened before, see
https://github.com/rear/rear/issues/1731
https://github.com/rear/rear/pull/1733
https://github.com/rear/rear/issues/102
For a summary see the ReaR 2.4 release notes
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-4.md
that read (excerpts)
Version 2.4 (June 2018) ... New features, bigger enhancements, and possibly backward incompatible changes: Major rework and changed default behaviour how ReaR behaves in migration mode when partitions can or must be resized to fit on replacement disks with different size. The new default behaviour is that only the partition end value of the last partition on a disk (and therefore its partition size) may get changed if really needed but no partition start value gets changed to avoid changes of the partition alignment. The new 420_autoresize_last_partitions script implements the new behaviour and the old 400_autoresize_disks was renamed into 430_autoresize_all_partitions to still provide the old behaviour if that is explicitly requested by the user but the old behaviour may result unexpected changes of arbitrary partitions on a disk. The new config variables AUTORESIZE_PARTITIONS AUTORESIZE_EXCLUDE_PARTITIONS AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE determine how ReaR behaves in migration mode when partitions can or must be resized. With AUTORESIZE_PARTITIONS='yes' the old behaviour is done. With AUTORESIZE_PARTITIONS='no' no partition is resized by ReaR. With the default AUTORESIZE_PARTITIONS='' at most the last active partition on each active disk gets resized but only if really needed which also depends on the settings of the other config variables above. For details see default.conf and the two 'autoresize' scripts. For some examples see https://github.com/rear/rear/pull/1733
If you are unable to make partition resizing work as you need it
with our current ReaR upstream GitHub master code and
(as needed) with the new config variables
AUTORESIZE_PARTITIONS
AUTORESIZE_EXCLUDE_PARTITIONS
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE
AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
things must be fixed in our current ReaR upstream GitHub master code.
jsmeix commented at 2018-07-17 08:40:¶
@exedor
regarding your
https://github.com/rear/rear/issues/1822#issuecomment-396304632
where you wrote
I do restores to multiple platforms and the initrd generated for one doesn't work on the others
In general this does not work and is not supported by ReaR
where "not supported" means here that ReaR is not intended
to make this "just work".
In general migrating a system onto different hardware
does not "just work", cf. "Inappropriate expectations" at
https://en.opensuse.org/SDB:Disaster_Recovery
On the other hand ReaR supports to migrate a system onto different
hardware
but here "supports" means that ReaR provides a lot that should help
you
to get such a task done but it does not mean that it would "just work"
without
possibly laborious manual settings and adaptions with trial and error
legwork
until you made things work for you in your particular case.
ReaR could be too laborious to migrate a single system onto different
hardware.
I think in this case a new installation from scratch is perhaps
easier.
But when you have to migrate many old systems onto new (different)
hardware
where the new hardware is basically same for all those systems, then
ReaR
could help you a lot to somewhat automate such a migration.
In general it does not work when you made the recovery ISO image
on one kind of machine and try to use that on another kind of machine.
In general it does not work to boot or use a ReaR recovery system
that was created on one kind of machine on another kind of machine.
In general the ReaR recovery system is specific for the machine
where it was created, see the section
"Fully compatible replacement hardware is needed" in
https://en.opensuse.org/SDB:Disaster_Recovery
When you intend to recreate a system on a different platform
you do a migration - i.e. you use ReaR in its migration mode.
To make the ReaR recovery system work on different hardware
you should at least have all kernel modules and firmware files
included in the ReaR recovery system, cf. the sections about
MODULES and FIRMWARE_FILES in usr/share/rear/conf/default.conf
I never tried but I think things will not at all work when you change
the way how the system boots for example from BIOS to UEFI, cf.
https://github.com/rear/rear/issues/1437
In general regarding migrating a system you may have a look at
http://lists.relax-and-recover.org/pipermail/rear-users/2018-February/003528.html
and follow the links therein.
jsmeix commented at 2018-09-28 07:26:¶
I assume things were sufficiently explained.
[Export of Github issue for rear/rear.]