#1983 PR `closed`: Moved 400_guess_kernel.sh to earlier stage¶

Labels: enhancement, cleanup, won't fix / can't fix / obsolete, minor bug

gozora opened issue at 2018-11-27 09:19:¶

Pull Request Details:¶

Type: Enhancement
Impact: Low
Reference to related issue (URL): NA
How was this pull request tested?
rear mkrescue
Brief description of the changes in this pull request:
I've moved 400_guess_kernel.sh from pack to prep stage, to get access to KERNEL_FILE variable earlier.
This will be helpful for future EFISTUB support, where KERNEL_FILE could be checked for EFISTUB functionality in earlier stage and throw error a bit sooner ...

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

As far as I see the 400_guess_kernel.sh script
does nothing else than to set the KERNEL_FILE variable
so that on first glance it seems to be o.k. when 400_guess_kernel.sh
is moved to the 'prep' stage because what it does matches
https://github.com/rear/rear/blob/master/usr/share/rear/prep/README

BUT:

It seems the code in the 400_guess_kernel.sh script also appears
in our various 300_copy_kernel.sh scripts which makes this issue
related to https://github.com/rear/rear/issues/1851
so that we have one single piece of code
where the KERNEL_FILE variable is set.

Interestingly 400_guess_kernel.sh is run after 300_copy_kernel.sh
which - offhandedly - looks just plain wrong to me...

@gozora
in which subsequent stage do you actually need the KERNEL_FILE value?

FYI:

The stages during rear mkbackup:

# usr/sbin/rear -s mkbackup | grep '^Source ' | cut -d '/' -f1 | uniq
Source conf
Source init
Source prep
Source layout
Source rescue
Source build
Source pack
Source output
Source backup

Unfortunately the 'prep' stage is the only one with a README file
that explains its intent a bit.

The scripts that contain KERNEL_FILE:

# find usr/sbin/rear usr/share/rear -type f | xargs grep -l "KERNEL_FILE"
usr/share/rear/backup/NETFS/default/500_make_backup.sh
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/GNU/Linux/400_guess_kernel.sh
usr/share/rear/pack/Linux-i386/300_copy_kernel.sh
usr/share/rear/output/ISO/Linux-ppc64le/800_create_isofs.sh
usr/share/rear/output/ISO/Linux-ia64/300_create_bootimg.sh
usr/share/rear/output/ISO/Linux-i386/800_create_isofs.sh
usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh
usr/share/rear/output/default/940_grub_rescue.sh
usr/share/rear/output/default/940_grub2_rescue.sh
usr/share/rear/output/RAWDISK/Linux-i386/280_create_bootable_disk_image.sh
usr/share/rear/output/RAWDISK/Linux-i386/270_create_grub2_efi_bootloader.sh
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh
usr/share/rear/output/USB/Linux-i386/830_copy_kernel_initrd.sh
usr/share/rear/output/PXE/default/800_copy_to_tftp.sh
usr/share/rear/output/RAMDISK/Linux-i386/900_copy_ramdisk.sh
usr/share/rear/conf/default.conf

gozora commented at 2018-11-28 11:07:¶

Hello @jsmeix,

TLDR;
Anywhere before /usr/share/rear/build/GNU/Linux/100_copy_as_is.sh

Recently I was writing restore code for boot entry using efibootmgr in rear recover stage.
Since efibootmgr requires information about file to boot (which is Linux kernel in our case), I've decided to store information about kernel (available during backup) in /var/lib/rear/.
Problem here is, that /var/lib/rear is copied into $ROOTFS_DIR in build stage and $KERNEL_FILE becomes available in later pack stage ...

V.

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

@gozora
I will try to do a pull request that cleans up how KERNEL_FILE is set, cf.
https://github.com/rear/rear/issues/1851#issuecomment-442419363

Because we are in development phase of ReaR 2.5
I think I should do such a cleanup soon so that we could
get feedback from users who use current ReaR upstream
if my cleanup causes regressions on this or that architecture
and/or on this or that Linux distribution where I don't test it myself.