#2873 PR `merged`: Fix initrd regeneration on s390x and Fedora/RHEL¶

Labels: enhancement, cleanup, fixed / solved / done

lzaoral opened issue at 2022-09-29 14:09:¶

Relax-and-Recover (ReaR) Pull Request Template¶

Please fill in the following items before submitting a new pull request:

Pull Request Details:¶

Type: Bug Fix
Impact: Normal
How was this pull request tested? RHEL 9 on s390x z/VM
Brief description of the changes in this pull request:

For some reason, the 550_rebuild_initramfs.sh script was not included for s390x on Fedora/RHEL so the initrd was not regenerated after backup restore on this architecture.

Since all other architectures were actually using the same script, let's just move it one level up to fix this bug and to also simplify the directory structure a bit.

pcahyna commented at 2022-09-29 14:19:¶

The symlinks ( ppc, ppc64le ) to the script have been introduced in #1311 and s390 was then forgotten, because support for that arch got introduced later. I have read https://github.com/rear/rear/pull/1311#issuecomment-295266258 and I don't think that the issue described there prevents moving the file up and removing the symlinks, and it is IMO the right thing to do, because there is nothing architecture-dependent in initrd regeneration. It will prevent this from being forgotten again when a new architecture support is added (think ARM).

jsmeix commented at 2022-09-30 12:09:¶

Regarding my
https://github.com/rear/rear/pull/1311#issuecomment-295266258
What I had meant was that we cannot have specific scripts
that replace "default" scripts because all scripts will be run.

I think the crucial point is whether or not
there is nothing architecture-dependent in initrd regeneration.

The problem is when there are already architecture-dependent
sub-directories it indicates that there is something
architecture-dependent in initrd regeneration
or that likely ther can be something
architecture-dependent in initrd regeneration
so a contributor for some specific architecture
will follow what is already there.
As far as I understand
https://github.com/rear/rear/pull/1311/files
it means that a architecture-dependent sub-directory
usr/share/rear/finalize/Fedora/i386/
had been already there.

jsmeix commented at 2022-09-30 12:14:¶

By the way:
We may clean up all of those symlinks
for the three different cases:

# find usr/share/rear -ls | grep 550_rebuild_initramfs

... -rw-r--r-- ... 5397 ...usr/share/rear/finalize/Fedora/i386/550_rebuild_initramfs.sh
... lrwxrwxrwx ...   32 ... usr/share/rear/finalize/Fedora/ppc64le/550_rebuild_initramfs.sh -> ../i386/550_rebuild_initramfs.sh
... lrwxrwxrwx ...   32 ... usr/share/rear/finalize/Fedora/ppc64/550_rebuild_initramfs.sh -> ../i386/550_rebuild_initramfs.sh

... -rw-r--r-- ... 5660 ... usr/share/rear/finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh
... lrwxrwxrwx ...   32 ... usr/share/rear/finalize/SUSE_LINUX/ppc64le/550_rebuild_initramfs.sh -> ../i386/550_rebuild_initramfs.sh
... lrwxrwxrwx ...   32 ... usr/share/rear/finalize/SUSE_LINUX/ppc64/550_rebuild_initramfs.sh -> ../i386/550_rebuild_initramfs.sh

... -rw-r--r-- ... 4454 ... usr/share/rear/finalize/Debian/i386/550_rebuild_initramfs.sh
... lrwxrwxrwx ...   32 ... usr/share/rear/finalize/Debian/ppc64le/550_rebuild_initramfs.sh -> ../i386/550_rebuild_initramfs.sh

pcahyna commented at 2022-09-30 12:19:¶

Yes, it had been already there, so I don't blame the authors of #1311 for following the example. It has been since the beginning when it was introduced (as usr/share/rear/finalize/SUSE_LINUX/i386/17_rebuild_initramfs.sh) and I believe that even then it was not necessary, because it did not contain anything architecture-specific.

jsmeix commented at 2022-09-30 12:41:¶

Further unifying the actual scripts

finalize/Fedora/i386/550_rebuild_initramfs.sh
finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh
finalize/Debian/i386/550_rebuild_initramfs.sh

into one or two (as far as possible with reasonable effort)
should be a separated cleanup task (as time permits).

jsmeix commented at 2022-09-30 12:49:¶

In general I am against the Linux distribution specific
sub-directories which we currently have in ReaR
because usually same kind of things are
rather same on different Linux distributions
so in general I prefer one generic script
that has Linux distribution specific differences
only where needed.

In contrast when different kind of things are used
(e.g. legacy GRUB versus GRUB2 or BIOS versus UEFI)
then usually separated different scripts should be used.

jsmeix commented at 2022-10-05 10:03:¶

@pcahyna
I assigned this pull request to you
because in its current form it belongs only
to things in .../finalize/Fedora/...
so you could merge it as you like.

pcahyna commented at 2022-10-12 15:02:¶

Hi @jsmeix , thanks for looking. We can check the differences between Fedora and SUSE scripts and determine if they are needed or not (some tests on both sides will be required).

[Export of Github issue for rear/rear.]

#2873 PR merged: Fix initrd regeneration on s390x and Fedora/RHEL¶