#1851 Issue `closed`: The various 300_copy_kernel.sh scripts should be cleaned up¶

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

jsmeix opened issue at 2018-07-04 08:09:¶

In current ReaR master code we have various 300_copy_kernel.sh scripts

# find usr/share/rear/ | grep 300_copy_kernel.sh
usr/share/rear/pack/Fedora/ia64/300_copy_kernel.sh
usr/share/rear/pack/Linux-ppc64le/300_copy_kernel.sh
usr/share/rear/pack/Linux-i386/300_copy_kernel.sh
usr/share/rear/pack/Linux-ppc64/300_copy_kernel.sh
usr/share/rear/pack/Debian/ia64/300_copy_kernel.sh

that get run in a Linux distribution dependant way via their sub directories
according to the $ARCH variable (and other general variables)
by the SourceStage function (in usr/share/rear/lib/framework-functions.sh).

Additionally usr/share/rear/pack/Linux-i386/300_copy_kernel.sh
and usr/share/rear/pack/Linux-ppc64le/300_copy_kernel.sh
and usr/share/rear/pack/Linux-ppc64/300_copy_kernel.sh
contain Linux distribution dependant cases by code like

    if [ -r "/boot/vmlinuz-$KERNEL_VERSION" ]; then
        ...
    elif [ -f /etc/redhat-release ]; then
        ...
    elif [ -f /etc/debian_version ]; then
        ...
    elif [ -f /etc/arch-release ]; then
        ...
    elif [ -f /etc/gentoo-release ]; then
        ...

But to distinguish Linux distribution dependant cases usually the variables
OS_MASTER_VENDOR OS_VENDOR OS_VENDOR_VERSION and so on
should be used see the SetOSVendorAndVersion function
in usr/share/rear/lib/config-functions.sh how those variables are set.
For example how those variables are used see the get_part_device_name_format function
in usr/share/rear/lib/layout-functions.sh that contains (excerpt):

            case $OS_MASTER_VENDOR in
                (SUSE)
                    ...
                ;;
                (Fedora)
                    ...
                ;;
                (Debian)
                    ...
                ;;
                (*)
                    ....
                ;;
            esac

cf. https://github.com/rear/rear/pull/1849#discussion_r199773522
Accordingly this way should also be used in this case here if possible.

gdha commented at 2018-07-19 11:43:¶

@jsmeix then we should also move this script to the default sub-directory.

jsmeix commented at 2018-07-19 11:52:¶

@gdha
I didn't had a closer look how those scrips are same and where they differ
and I guess I won't find time for that before ReaR 2.5 gets released but
because current things work there is no hurry (therefore 'ReaR future').

jsmeix commented at 2018-11-28 10:20:¶

https://github.com/rear/rear/pull/1983#issuecomment-442395004
indicates that the current mess is a minor bug because
400_guess_kernel.sh is run after 300_copy_kernel.sh
which - offhandedly - looks just plain wrong to me...

gozora commented at 2018-11-28 10:53:¶

@jsmeix,

Comparing 300_copy_kernel.sh and 400_guess_kernel.sh, the output looks somehow similar:

diff $r/pack/Linux-i386/300_copy_kernel.sh $r/pack/GNU/Linux/400_guess_kernel.sh
1c1
< # 300_copy_kernel.sh
---
> # 400_guess_kernel.sh
3c3
< # copy kernel for Relax-and-Recover
---
> # guess kernel if not set yet or error out, for diverse Architectures (arm, aarch64, etc.)
8,11d7
< # find and copy kernel
< # we only try to find the currently running kernel
< # Using another kernel is a TODO for now
< 
13,23c9
<     # add slackware test on top to prevent error on get_kernel_version
<     if [ -f /etc/slackware-version ]; then
<         # check under /boot/efi/EFI/Slackware
<         if [ -f "/boot/efi/EFI/Slackware/vmlinuz" ]; then
<            KERNEL_FILE="/boot/efi/EFI/Slackware/vmlinuz"
<         elif [ -r "/boot/vmlinuz-$KERNEL_VERSION" ]; then
<             KERNEL_FILE="/boot/vmlinuz-$KERNEL_VERSION"
<         else 
<            Error "Could not find a matching kernel in /boot/efi/EFI/Slackware or /boot!"
<         fi
<     elif [ -r "/boot/vmlinuz-$KERNEL_VERSION" ]; then
---
>     if [ -r "/boot/vmlinuz-$KERNEL_VERSION" ]; then
61a48,57
> 
> [ -s "$KERNEL_FILE" ]
> StopIfError "Could not find a suitable kernel. Maybe you have to set KERNEL_FILE [$KERNEL_FILE] ?"
> 
> if [ -L $KERNEL_FILE ]; then
>     KERNEL_FILE=$(readlink -f $KERNEL_FILE)
> fi
> 
> Log "Guessed kernel $KERNEL_FILE"
>

These files serves similar purpose, and could be IMHO merged.

V.

jsmeix commented at 2018-11-28 11:47:¶

Because of
https://github.com/rear/rear/pull/1983#issuecomment-442408993
I think we should set the KERNEL_FILE variable in the 'prep' stage
in a single script that does "the right thing"
and remove our current various 300_copy_kernel.sh scripts
(except output/USB/Linux-i386/830_copy_kernel_initrd.sh)
i.e. remove

usr/share/rear/pack/Fedora/ia64/300_copy_kernel.sh
usr/share/rear/pack/Linux-ppc64/300_copy_kernel.sh
usr/share/rear/pack/Debian/ia64/300_copy_kernel.sh
usr/share/rear/pack/Linux-ppc64le/300_copy_kernel.sh
usr/share/rear/pack/Linux-i386/300_copy_kernel.sh

because they do not copy the kernel into the recovery system
but only also set the KERNEL_FILE variable in various ways.

jsmeix commented at 2018-11-28 15:10:¶

https://github.com/rear/rear/pull/1985
intends to get this issue (plus https://github.com/rear/rear/pull/1983) fixed.

jsmeix commented at 2018-11-29 15:55:¶

With https://github.com/rear/rear/pull/1985 merged
this issue is hopefully fixed - if not I will of course fix regressions.

[Export of Github issue for rear/rear.]

#1851 Issue closed: The various 300_copy_kernel.sh scripts should be cleaned up¶