#1311 PR merged: Use dracut to rebuild initrd for RHEL on POWER¶
Labels: enhancement, fixed / solved / done
schabrolles opened issue at 2017-04-17 13:43:¶
Here is a first proposal of a 500_rebuild_initramfs.sh script for RHEL
(based on dracut).
To avoid any side effect, I put it in
finalize/RedHatEntrepriseServer/ppc64le.
But we will have a lot of duplicates soon as we may need the same kind
of file for ppc64, x86_64 and other...
I think the way to manage the rebuilding of initramfs could be the same
per distro... what do you think ?
jsmeix commented at 2017-04-19 13:15:¶
@schabrolles
in general use symbolic links for duplicated files
e.g. like what we currently already have
usr/share/rear/finalize/SUSE_LINUX/ppc64/500_rebuild_initramfs.sh -> ../i386/170_rebuild_initramfs.sh
There is a general problem with how the SourceStage function
in lib/framework-functions.sh sources files
cf.
https://github.com/rear/rear/pull/1241#issue-214078298
The SourceStage function basically sources all scripts
that match below a directory so that one cannot have
a generic default script like
usr/share/rear/finalize/default/500_rebuild_initramfs.sh
plus distribution/architecture specific scripts like
usr/share/rear/finalize/SUSE_LINUX/ppc64/500_rebuild_initramfs.sh
or
usr/share/rear/finalize/RedHatEnterpriseServer/ppc64/500_rebuild_initramfs.sh
that are run instead of the generic default script:
# echo hello >usr/share/rear/finalize/default/170_rebuild_initramfs.sh # usr/sbin/rear -s recover | grep rebuild_initramfs Source finalize/SUSE_LINUX/i386/170_rebuild_initramfs.sh Source finalize/default/170_rebuild_initramfs.sh
Therefore we cannot have generic default scripts
but must use specific scripts for all Linux distributions
and architectures even if most of them would be identical.
jsmeix commented at 2017-04-19 13:20:¶
@schabrolles
perhaps for RHEL and similar distributions (e.g Fedora and Centos)
it helps to also clean up the SetOSVendorAndVersion function
as I did in
https://github.com/rear/rear/pull/1241
for SUSE
to get common OS_VENDOR string?
jsmeix commented at 2017-04-19 13:26:¶
FWIW:
The root cause why I did the SetOSVendorAndVersion
cleanup for SUSE was that
usr/share/rear/finalize/SUSE_LINUX/i386/170_rebuild_initramfs.sh
was not run "out of the box" by ReaR - i.e. when plain ReaR was
installed without an appropriate /etc/rear/os.conf file that contains
OS_VENDOR=SUSE_LINUX
schlomo commented at 2017-04-19 13:47:¶
@schabrolles even though probably only RHEL is used on PPC, maybe better put your additions in /Fedora/ subdirectories to be together with the other generic RHEL/Fedora scripts. That will also enable CentOS users to benefit from your improvement.
@jsmeix let's keep the OS_MASTER_VENDOR discussion in #1241
The current concept is based on additive thinking, we go from very generic (default) to distro & version OR distro & arch specific (RedHatEnterpriseServer/7 OR RedHatEnterpriseServer/i386) with several steps inbetween. The idea is to put each script in a "as generic as possible" place.
schabrolles commented at 2017-04-20 09:50:¶
@schlomo As you've suggested, I've moved the build_initrd files for POWER to Fedora directory and it works.
Right now, initrd is rebuilded only on storage driver changes:
# Skip if there is nothing to do.
# During "rear recover" 260_recovery_storage_drivers.sh creates $TMP_DIR/storage_drivers
if ! test -s $TMP_DIR/storage_drivers ; then
Log "Skip recreating initrd: No needed storage drivers ('$TMP_DIR/storage_drivers' is empty)"
return 0
fi
# During "rear mkbackup/mkrescue" 260_storage_drivers.sh creates $VAR_DIR/recovery/storage_drivers
if cmp -s $TMP_DIR/storage_drivers $VAR_DIR/recovery/storage_drivers ; then
Log "Skip recreating initrd: '$TMP_DIR/storage_drivers' and '$VAR_DIR/recovery/storage_drivers' are the same"
return 0
fi
But in the case we migrate from systemA to systemB (booth
BOOT_OVER_SAN), driver will be the same, but wwids will have changed.
=> Need to update initramfs to update /etc/multipath/wwids file.
Can we use is_true $MIGRATION_MODE || return 0 instead ?
jsmeix commented at 2017-04-20 09:51:¶
Regarding
https://github.com/rear/rear/pull/1311#issuecomment-295276076
"The current concept is based on additive thinking"
that causes
https://github.com/rear/rear/pull/1311#issuecomment-295266258
"we cannot have generic default scripts"
I created
https://github.com/rear/rear/issues/1320
jsmeix commented at 2017-04-20 10:08:¶
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
REBUILD_INITRAMFS=""
which defaults to "yes" if not specified be 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.
jsmeix commented at 2017-04-20 13:57:¶
Regarding when ReaR should recreate initrd/initramfs I made
https://github.com/rear/rear/issues/1321
to get that issue separated from this issue here
so that this issue here can be merged soon.
jsmeix commented at 2017-04-20 14:24:¶
@schabrolles
for now ignore the issue in
https://github.com/rear/rear/pull/1311#issuecomment-295657734
so that this pull request can be merged soon.
When it is merged (i.e. when all current pull requests that
change rebuild_initramfs scripts are merged) I will implement
https://github.com/rear/rear/issues/1321
(which also needs changes in all rebuild_initramfs scripts).
schabrolles commented at 2017-04-20 14:28:¶
@jsmeix I don't know if I can use a link to
finalize/Fedora/i386/170_rebuild_initramfs.sh as the 2 script doesn't
look the same here.
finalize/Fedora/i386/500_rebuild_initramfs.sh use dracut, but not
finalize/Fedora/i386/170_rebuild_initramfs.sh.
dracut seems to be the prefered way to regenerate initrd in rhel... but
I don't know the reason why
finalize/Fedora/i386/170_rebuild_initramfs.sh is not using it.... (may
be there is a good one ...)
jsmeix commented at 2017-04-20 14:35:¶
I think mkinitrd is the traditional executable to recreate the initrd
which still works also when dracut is used so that mkinitrd is the
generically working way to recreate the initrd also on old systems
where no dracut is used.
schabrolles commented at 2017-04-20 14:41:¶
Ok, So let me try to use i386/170_rebuild_initramfs based on mkinitrd,
I will add my multipath addition and test it on POWER.
If it work, we can use only one script for all.
schabrolles commented at 2017-04-21 12:04:¶
@jsmeix it seems to work well by using link :
finalize/SUSE_LINUX/ppc64/500_rebuild_initramfs.sh -> ../i386/500_rebuild_initramfs.sh
and
finalize/SUSE_LINUX/ppc64le/500_rebuild_initramfs.sh -> ../i386/500_rebuild_initramfs.sh
finalize/Fedora/ppc64/500_rebuild_initramfs.sh -> ../i386/500_rebuild_initramfs.sh
and
finalize/Fedora/ppc64le/500_rebuild_initramfs.sh -> ../i386/500_rebuild_initramfs.sh
tested with RHEL6 (ppc64) and RHEL7.2 (ppc64le).
schabrolles commented at 2017-04-24 11:14:¶
@jsmeix I would like to move the multipath configuration (before
creating ramdisk) to a separated script usable by other distro/arch
finalize/GNU/Linux/430_create_multipath.sh.
This should simplify the 500_rebuild_initramfs.sh and let it focus on
rebuilding initramfs.
jsmeix commented at 2017-04-24 12:13:¶
@schabrolles
I fully agree to use separated scripts for separated tasks
and I do very much appreciate all your cleanup and
improvements here.
schabrolles commented at 2017-04-25 10:01:¶
@jsmeix I like it !!! Let me test it and if it works I'll push the change.
jsmeix commented at 2017-04-25 10:48:¶
@schabrolles
and see my above comment
https://github.com/rear/rear/pull/1311#pullrequestreview-33787588
"LogPrint messages missing when programs in chroot fail".
Ultimately it is your decision whether or not to show
LogPrint messages when something failed
or error out in such cases
or ignore when something failed (as it is now).
From plain looking at 430_create_multipath_config.sh
it seems the code therein works somehow like
if MULTIPATH_SETUP_NEEDED ; then
do_stuff_to_setup_multipath
fi
which looks as if on the one hand it is required
that do_stuff_to_setup_multipath runs successfully
but on the other hand it is silently ignored when it fails.
schabrolles commented at 2017-04-25 13:41:¶
@jsmeix thanks for your comments, I've updated the code (and correct a bug by the way ... /proc was missing !!).
Please have a look to this updated version, tested against SLES11 SLE12, RHEL 6 & RHEL7
jsmeix commented at 2017-04-25 13:54:¶
When there are no objections
I will merge it soon...
[Export of Github issue for rear/rear.]