#1321 Issue closed: Recreate initrd/initramfs by default in any case

Labels: enhancement, fixed / solved / done, minor bug

jsmeix opened issue at 2017-04-20 13:55:

Currently "rear recover" recreates initrd/initramfs
only if some drivers changed, see the code in the
rebuild_initramfs scripts.

I think recreating initrd only if some drivers changed it insufficient.
It basically calls for errors later when booting the recreated system.

I think by default initrd should always be recreated to be on the safe side.
ReaR can never verify all possible reasons why initrd must be recreated.
Only in special known cases recreating initrd could be skipped
automatically by ReaR.

On the other hand when recreating initrd fails during "rear recover"
this should not be a hard error abort because often the recreated
system boots with the initrd that was restored form the backup, cf.
the LogPrint "WARNING ..." messages in the rebuild_initramfs scripts.

Probably best is to add a new boolean config variable


which defaults to "yes" if not specified by the user
so that by default it works fail safe but still the user has the
final power to decide whether or not ReaR recreates the initrd.

For background information see

schlomo commented at 2017-04-20 14:00:

I can't remember now why we didn't recreate the initrd by default back when I wrote this part. Maybe this is related to some historic SLES8/9 stuff which I forgot already.

Therefore I am all in favor. However, I would approach it from the other side: Always recreate the initrd and have a variable (e.g. NO_REBUILD_INITRAMFS) which can be set to force ReaR to trust the existing initrd.

That would underline the fact that we believe that it should always be generated.

jsmeix commented at 2017-04-20 14:16:

I do not like logically inverse working boolean variables
that lead to code like

if ! is_false "$NO_REBUILD_INITRAMFS" ; then

What exactly is that code meant to do?

I already got crazy when working on code that deals with
that NOBOOTLOADER thingy. At least for me I get too
easily the logic of inverse working boolean variables inverse.

In other words:
Usually I fail to implement code for inverse working boolean variables
correctly and then I fail to fix my bugs correctly ad infinitum...

schlomo commented at 2017-04-20 14:49:

I meant more like

is_true $NO_REBUILD_INITRAMFS && return

which to me is positive logic even though the variable denotes disabling something.

Otherwise, if it helps you, maybe just call it KEEP_INITRAMFS instead. Although I would not prefer that as it sounds too positive for something that we consider a bad idea.

jsmeix commented at 2017-04-21 11:38:

Of course for our initial intended use case

is_true $NO_REBUILD_INITRAMFS && return

the logic is clear and simple.

I meant when more sophisticated cases may appear later
(because of whatever reasons that I cannot foersee now)
then inverse working boolean variables easily cause bugs.

I think in practice it should not really matter if we use
because for normal use cases the user should not
bother with that setting and for experts who like to
not rebuild their initrd/initramfs both names are o.k.

jsmeix commented at 2017-05-17 14:22:

With https://github.com/rear/rear/pull/1367 merged
this issue should be fixed.

[Export of Github issue for rear/rear.]