Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added mods for slackware support - mkbackup working with UEFI/USB #1849

Closed
wants to merge 1 commit into from

Conversation

wdmsde
Copy link
Contributor

@wdmsde wdmsde commented Jul 2, 2018

Pull Request Details:
  • Type: Enhancement

  • Impact: Normal

  • Reference to related issue (URL):
    http://lists.relax-and-recover.org/pipermail/rear-users/2018-July/003572.html

  • How was this pull request tested?
    Tested on laptop running Slackware 14.2 with UEFI. Used "rear -v mkbackup" to USB drive. The USB drive booted OK but I did not test recover function yet. The backup tar was available on the drive.

  • Brief description of the changes in this pull request:
    Added code to support Slackware 14.2 distribution. This was a brute force approach and my mktemp changes may break compatibility with other OSs. Requesting feedback to improve quality.

@jsmeix jsmeix requested a review from gozora July 3, 2018 11:12
@@ -88,7 +89,8 @@ EOF

# Create bootloader, this overwrite BOOTX64.efi copied in previous step ...
# Fail if BOOTX64.efi can't be created
${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O x86_64-efi linux part_gpt ext2 normal gfxterm gfxterm_background gfxterm_menu test all_video loadenv fat
# Slackware grub doesnt have gfxterm_background or gfxterm_menu...
${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O x86_64-efi linux part_gpt ext2 normal gfxterm gfxmenu test all_video loadenv fat
Copy link
Member

@jsmeix jsmeix Jul 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here a test for Slackware and conditional code execution is needed
like you did it in your usr/share/rear/pack/Linux-i386/300_copy_kernel.sh

# add slackware test on top to prevent error because
# slackware grub doesnt have gfxterm_background or gfxterm_menu...
if [ -f /etc/slackware-version ] ; then
    ${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O x86_64-efi linux part_gpt ext2 normal gfxterm gfxmenu test all_video loadenv fat
else
    ${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O x86_64-efi linux part_gpt ext2 normal gfxterm gfxterm_background gfxterm_menu test all_video loadenv fat
fi

or perhaps even cleaner by using a meaningful variable for the GRUB modules like

grub_modules="x86_64-efi linux part_gpt ext2 normal gfxterm gfxmenu test all_video loadenv fat"
# slackware grub doesnt have gfxterm_background or gfxterm_menu
test -f /etc/slackware-version || grub_modules="$grub_modules gfxterm_background gfxterm_menu"
# Create bootloader, this overwrite BOOTX64.efi copied in previous step ...
# Fail if BOOTX64.efi can't be created
${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O $grub_modules

The actual test for Slackware should be done via the usually
used variables like OS_MASTER_VENDOR, see my other comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing modules that are currently used and tested was my only concern. If this code can be re-written so it does not interfere with existing distributions, I have not problems left with this PR.

V.

@@ -10,7 +10,13 @@
# Using another kernel is a TODO for now

if [ ! -s "$KERNEL_FILE" ]; then
if [ -r "/boot/vmlinuz-$KERNEL_VERSION" ]; then
# add slackware test on top to prevent error on get_kernel_version
if [ -f /etc/slackware-version ]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test for Slackware should be done via the usually used variables
OS_MASTER_VENDOR OS_VENDOR OS_VENDOR_VERSION and so on,
see the SetOSVendorAndVersion function in usr/share/rear/lib/config-functions.sh
how those variables are set.

Perhaps those variables are already set right for Slackware by that function
perhaps you need to add support to get them set right for Slackware to that function.
To find out to what values those variables are set in your particular case
run rear dump for example in my case on SLES15 I get (excerpts):

# usr/sbin/rear -D dump
...
This is a 'Linux-x86_64' system, compatible with 'Linux-i386'.
System definition:
                                    ARCH = Linux-i386
                                      OS = GNU/Linux
                        OS_MASTER_VENDOR = SUSE
                       OS_MASTER_VERSION = 15
                   OS_MASTER_VENDOR_ARCH = SUSE/i386
                OS_MASTER_VENDOR_VERSION = SUSE/15
           OS_MASTER_VENDOR_VERSION_ARCH = SUSE/15/i386
                               OS_VENDOR = SUSE_LINUX
                              OS_VERSION = 15
                          OS_VENDOR_ARCH = SUSE_LINUX/i386
                       OS_VENDOR_VERSION = SUSE_LINUX/15
                  OS_VENDOR_VERSION_ARCH = SUSE_LINUX/15/i386

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

@jsmeix jsmeix self-assigned this Jul 3, 2018
@jsmeix jsmeix added the enhancement Adaptions and new features label Jul 3, 2018
@jsmeix jsmeix added this to the ReaR v2.5 milestone Jul 3, 2018
@jsmeix
Copy link
Member

jsmeix commented Jul 3, 2018

@gozora
I requested your review here because it is about UEFI.

@jsmeix jsmeix requested a review from schlomo July 3, 2018 11:35
@jsmeix
Copy link
Member

jsmeix commented Jul 3, 2018

@schlomo
I requested your review here because currently it shows

Merging is blocked
The target branch requires all commits to be signed.

but this is a pull request from an external contributor.

I would like to know how we should handle pull requests from external contributors.

I would prefer when external contributors are not forced to sign their pull requests.

I would prefer when it is sufficient that pull requests from external contributors
are reviewed by us and if the changes are o.k. for us that then we can merge it.

Is that possible or would that contradict our improved security in
#1419

Copy link
Member

@jsmeix jsmeix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wdmsde
many thanks for your pull request!
See my comments for my requested changes.

@wdmsde
Copy link
Contributor Author

wdmsde commented Jul 3, 2018 via email

@wdmsde
Copy link
Contributor Author

wdmsde commented Jul 3, 2018 via email

@gozora
Copy link
Member

gozora commented Jul 3, 2018

Hello @wdmsde,

I used the
process of muntzing to reduce the grub modules and would like you to
consider that the eliminated modules were not required and maybe should be
left out?

I'd prefer not to messing up with existing code and keep modules as they are, at lest for non-Slackware distributions. We did not had issues with non-booting ReaR recovery system because "this and that" for a quite a long time, and I really like it that way ;-).

V.

@@ -88,7 +89,8 @@ EOF

# Create bootloader, this overwrite BOOTX64.efi copied in previous step ...
# Fail if BOOTX64.efi can't be created
${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O x86_64-efi linux part_gpt ext2 normal gfxterm gfxterm_background gfxterm_menu test all_video loadenv fat
# Slackware grub doesnt have gfxterm_background or gfxterm_menu...
${GRUB_MKIMAGE} -o ${EFI_DST}/BOOTX64.efi -p ${EFI_DIR} -O x86_64-efi linux part_gpt ext2 normal gfxterm gfxmenu test all_video loadenv fat
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing modules that are currently used and tested was my only concern. If this code can be re-written so it does not interfere with existing distributions, I have not problems left with this PR.

V.

@gozora
Copy link
Member

gozora commented Jul 3, 2018

@schlomo @jsmeix

requested your review here because currently it shows
Merging is blocked
The target branch requires all commits to be signed.

Interestingly enough, when I have this PR open on my phone, I have "Merge pull request" button active.... :-)

V.

@jsmeix
Copy link
Member

jsmeix commented Jul 4, 2018

@schlomo @gdha
I assigned this pull request to you because I cannot merge it,
cf. #1849 (comment)
and #1850 (comment)

@jsmeix
Copy link
Member

jsmeix commented Jul 4, 2018

@wdmsde
regarding your
#1849 (comment)

You are right.
For this pull request just follow the existing convention in the current code.

Unfortunately sometimes the ReaR code is such a mess
that has grown over the time where things need to be cleaned up.
We try to do as much as we can as time permits but as long as things work
there is no pressure to clean up code that works - "never change ..." ;-)
Right now I did #1851
to clean up our various 300_copy_kernel.sh scripts as time permits in the future.

@wdmsde
Copy link
Contributor Author

wdmsde commented Jul 5, 2018 via email

@jsmeix
Copy link
Member

jsmeix commented Jul 9, 2018

Superseded by #1853

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants