New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Why does "rear recover" regenerate the original's system initrd in any case? #3162
Comments
Overhauled finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh Now it uses dracut by default and mkinitrd as fallback see #3152 Additionally improved the user messages (in particular the warnings) to make it more clear that the point is to decide if the recreated system will boot with the initrd 'as is' from the backup restore, cf. #3162 Furthermore removed the whole INITRD_MODULES code because INITRD_MODULES is not used and /etc/sysconfig/kernel does no longer exist since SLES12 so the INITRD_MODULES code is dead code.
I would check with SW RAID, I suspect some details of the recreated array may differ from the original (like UUIDs) and regenerating the initrd may be needed for picking up this. |
This may be the case also for other IDs in the system config files that may change, if the files are embedded in the ramdisk. We have a script running at the end that updates the IDs in known config files. |
@pcahyna |
Overhauled finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh Now it uses dracut by default and mkinitrd as fallback see rear#3152 Additionally improved the user messages (in particular the warnings) to make it more clear that the point is to decide if the recreated system will boot with the initrd 'as is' from the backup restore, cf. rear#3162 Furthermore removed the whole INITRD_MODULES code because INITRD_MODULES is not used and /etc/sysconfig/kernel does no longer exist since SLES12 so the INITRD_MODULES code is dead code.
Overhauled finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh Now it uses dracut by default and mkinitrd as fallback see rear#3152 Additionally improved the user messages (in particular the warnings) to make it more clear that the point is to decide if the recreated system will boot with the initrd 'as is' from the backup restore, cf. rear#3162 Furthermore removed the whole INITRD_MODULES code because INITRD_MODULES is not used and /etc/sysconfig/kernel does no longer exist since SLES12 so the INITRD_MODULES code is dead code.
just as side note, i also experiencing this mostly on systems with multipath setups. |
Stale issue message |
Triggered by
#3152
and
#3155
I am wondering
why "rear recover" regenerates
the original's system initrd in any case?
In particular why I am wondering see in my
#3152 (comment)
and see in my
#3155 (comment)
The default use case of "rear recover" is to recreate
on "Fully compatible replacement hardware"
(where "hardware" could be also virtual hardware), cf.
https://en.opensuse.org/SDB:Disaster_Recovery#Fully_compatible_replacement_hardware_is_needed
On "fully compatible replacement hardware"
the initrd 'as is' from the original system
together with the kernel 'as is' from the original system
(that both together are restored 'as is' from the backup)
must still work
(otherwise it is no "fully compatible replacement hardware").
So for the default use case of "rear recover"
there is no need to regenerate the initrd.
But regenerating the initrd needs relatively long time
so "rear recover" is slower than actually needed
AND
regenerating the original's system initrd
during "rear recover" may generate the new initrd
with (possibly subtle but severe) differences
compared to the original's system initrd
so regenerating the initrd in any case
may do more harm than good in practice
for the default use case of "rear recover".
The text was updated successfully, but these errors were encountered: