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 grub bootloader for USB #2655

Merged
merged 4 commits into from Jul 20, 2021
Merged

Conversation

DEvil0000
Copy link
Contributor

  • Type: New Feature / Enhancement
  • Impact: Normal
  • Reference to related issue (URL): partially OUTPUT=USB bug summary #2648
  • How was this pull request tested?

tested output usb with:

  1. USB_BOOTLOADER=
  2. USB_BOOTLOADER=grub
    on apu2 board (coreboot/seabios) - no efi
  • Brief description of the changes in this pull request:
    added option to write grub bootloader to usb (no efi)
    it may not be perfect but a good starting point

# in prep/USB/Linux-i386/350_check_usb_disk.sh

[ "$RAW_USB_DEVICE" -a "$REAL_USB_DEVICE" ]
BugIfError "RAW_USB_DEVICE and REAL_USB_DEVICE should be already set"
Copy link
Member

Choose a reason for hiding this comment

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

Better avoid the ...IfError functions.
They do not work fail-safe, see the comment in
usr/share/rear/lib/_input-output-functions.sh
about "Using the ...IfError functions can result unexpected behaviour in certain cases"
currently at
https://github.com/rear/rear/blob/master/usr/share/rear/lib/_input-output-functions.sh#L773

We try to replace the ...IfError functions by plain bash code
where we find them when we change code
but we keep them as is in old code that we do not touch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I carried the check over from somewhere else. Will change it

Copy link
Member

Choose a reason for hiding this comment

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

I can imagine wherefrom you copied it ;-)
cf. #2644 (comment)

In particular the USB bootloader setup code is rather old code
e.g. 50% of the code in output/USB/Linux-i386/300_create_extlinux.sh
is 10 years old (from 2011 according to what 'git blame' shows)
so large parts of the USB bootloader setup code is not in compliance with
https://github.com/rear/rear/wiki/Coding-Style

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was not 100% sure how to rewrite that so please double check my commit for that

grub_version=$($GRUB_INSTALL --version | awk '{print $NF}' | cut -c1-1)

case ${grub_version} in
0)
Copy link
Member

Choose a reason for hiding this comment

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

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.

See my comments at the code places

@jsmeix
Copy link
Member

jsmeix commented Jul 14, 2021

@DEvil0000
thank you for this very much missing enhancement!

I appreciate the new USB_BOOTLOADER config variable
because - at least for me - it was an endless confusion
what "install a bootloader" actually means in ReaR
because in ReaR there are two separated bootloader install actions:

Installing the bootloader of the ReaR recovery system during "rear mkrescue"
versus
(re)-installing the bootloader of the recreated system during "rear recover".

With clearly named config variables like USB_BOOTLOADER
it is now at least clear what bootloader will be used
for the ReaR recovery system when it is made with OUTPUT=USB

@jsmeix jsmeix requested a review from a team July 14, 2021 09:29
@jsmeix jsmeix self-assigned this Jul 14, 2021
@jsmeix jsmeix added the enhancement Adaptions and new features label Jul 14, 2021
@jsmeix jsmeix added this to the ReaR v2.7 milestone Jul 14, 2021
@@ -0,0 +1,64 @@
# only run for grub
if [ -z $USB_BOOTLOADER ] && [[ ! $USB_BOOTLOADER =~ grub ]]; then
return 0
Copy link
Member

Choose a reason for hiding this comment

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

I do not undrestand the condition. I think

if [ -z $USB_BOOTLOADER ] && [[ ! $USB_BOOTLOADER =~ grub ]]

means

if $USB_BOOTLOADER is empty AND $USB_BOOTLOADER is not "grub"

but I assume output/USB/Linux-i386/300_create_grub.s should be skipped

if $USB_BOOTLOADER is empty OR $USB_BOOTLOADER is not "grub"

e.g.

# USB_BOOTLOADER='' ; if [ -z $USB_BOOTLOADER ] && [[ ! $USB_BOOTLOADER =~ grub ]] ; then echo no grub ; else echo grub ; fi
no grub

# USB_BOOTLOADER='grub' ; if [ -z $USB_BOOTLOADER ] && [[ ! $USB_BOOTLOADER =~ grub ]] ; then echo no grub ; else echo grub ; fi
grub

# USB_BOOTLOADER='foo' ; if [ -z $USB_BOOTLOADER ] && [[ ! $USB_BOOTLOADER =~ grub ]] ; then echo no grub ; else echo grub ; fi
grub

I think the test should be simply

if $USB_BOOTLOADER is not "grub"

i.e.

# Skip when USB_BOOTLOADER is not 'grub':
test "$USB_BOOTLOADER" = "grub" || return 0

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the empty is in there for empty beeing previous behaviour as described in the conf file comment.
the -z is very common and readable bash to me for empty checks.
the not equal check van be written differently of course.

@@ -1,3 +1,8 @@
# Only run for syslinux and extlinux
if [ ! -z $USB_BOOTLOADER ] && [[ ! $USB_BOOTLOADER =~ syslinux|extlinux ]]; then
Copy link
Member

Choose a reason for hiding this comment

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

I do not see where USB_BOOTLOADER is set to syslinux or extlinux.
Similar as https://github.com/rear/rear/pull/2655/files#r672040064
I think the test should be simplified to

# Skip if USB_BOOTLOADER is 'grub'
# see its counterpart in output/USB/Linux-i386/300_create_grub.sh
test "$USB_BOOTLOADER" = "grub" && return

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it does not need to be set since empty is previous behaviour but may be set by config

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.

I think the tests are not right.

@@ -41,7 +41,7 @@ if has_binary grub-install grub2-install; then
# What version of grub are we using
# substr() for awk did not work as expected for this reason cut was used
# First charecter should be enough to identify grub version
grub_version=$($GRUB_INSTALL --version | awk '{print $NF}' | cut -c1-1)
grub_version=$(( $GRUB_INSTALL --version | awk '{print $NF}' | cut -c1-1 ))
Copy link
Member

Choose a reason for hiding this comment

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

The paired parenthesis are for the case cases
not for the command substitution.

@jsmeix
Copy link
Member

jsmeix commented Jul 19, 2021

@DEvil0000
if you like and if you agree
I could do my requested changes
directly in your pull request code here.

@DEvil0000
Copy link
Contributor Author

feel free to do changes.
Do you need write access to the branch at PR source?

@jsmeix
Copy link
Member

jsmeix commented Jul 19, 2021

I have write access - this is why I asked you for permit.
I have write access because the pull request sources
are already within the ReaR upstream GitHub area,
e.g. one of your commits has URL

https://github.com/rear/rear/pull/2655/commits/249a977119251d0ce766aca7bf84514c301acca2

so the pull request sources already belong to
github.com/rear/rear where I have write access.

@jsmeix
Copy link
Member

jsmeix commented Jul 19, 2021

Strange.
I can no longer change pull request code via the GitHub web interface.
I know I could do this in the past.

@rear/contributors
if there are no objections I would like to merge it as is tomorrow morning and
then I will further adapt and enhance things via a subsequent pull request from me.

Because USB_BOOTLOADER is a new config variable
we are free to implement how it should behave.

Currently I am thinking about something like:

  • USB_BOOTLOADER empty or unset (the default): Automatism what USB bootloader is used
  • USB_BOOTLOADER="extlinux": Enforce using syslinux/extlinux as USB bootloader
  • USB_BOOTLOADER="grub": Enforce using grub2 as USB bootloader
  • USB_BOOTLOADER="efi": Enforce EFI boot for USB

This is currently only some offhanded idea...

@DEvil0000
Copy link
Contributor Author

keep in mind that efi is not very specific - it may be used with different bootloaders and efi payloads and so on.

@jsmeix
Copy link
Member

jsmeix commented Jul 19, 2021

Yes, I have had a look at output/USB/Linux-i386/100_create_efiboot.sh
and because of what I saw there I intentionally proposed the unspecific

  • USB_BOOTLOADER="efi": Enforce EFI boot for USB

to basically run output/USB/Linux-i386/100_create_efiboot.sh as is.

If needed we may later further enhance things like

  • USB_BOOTLOADER="efi": Enforce EFI boot for USB (automatism what bootloader is used)
  • USB_BOOTLOADER="efi grub": Enforce EFI boot for USB with grub2 as bootloader
  • USB_BOOTLOADER="efi elilo": Enforce EFI boot for USB with elilo as bootloader

@jsmeix
Copy link
Member

jsmeix commented Jul 19, 2021

I think EFI boot setup and BIOS boot setup
would normally exclude each other
but I fail to see how
output/USB/Linux-i386/100_create_efiboot.sh
and
output/USB/Linux-i386/300_create_extlinux.sh
exclude each other.

What I can see is that output/USB/Linux-i386/100_create_efiboot.sh
is only run when USING_UEFI_BOOTLOADER is true
but I fail to see how output/USB/Linux-i386/300_create_extlinux.sh
is not run when USING_UEFI_BOOTLOADER is true.

So - as far as I can currently see from plain looking at the code - it seems
output/USB/Linux-i386/300_create_extlinux.sh
is run in any case - in particular also on systems with UEFI firmware.

I wonder if that makes sense?

@DEvil0000
Copy link
Contributor Author

I did not test or change that configuration combination / path in software.

There may be good reasons for this. In case of elilo.efi it does not run the grub config part in 100_create_efiboot.sh what makes me believe this case needs some syslinux/extlinux config then.
Also there is still the option of creating a boot device which can boot from legacy bios and efi method but I think thats not what was intended here. I am however not familiar with this.

@jsmeix
Copy link
Member

jsmeix commented Jul 20, 2021

@DEvil0000
in your output/USB/Linux-i386/300_create_grub.sh there is

USB_REAR_DIR="$BUILD_DIR/outputfs/$USB_PREFIX"
if [ ! -d "$USB_REAR_DIR" ]; then
    mkdir -p $v "$USB_REAR_DIR" >/dev/null || Error "Could not create USB ReaR dir [$USB_REAR_DIR] !"
fi

but it seems USB_REAR_DIR is nowhere used
so I would like to know why that directory is created there
i.e. what the reason behind is why that directory is created?

USB_REAR_DIR also appears in output/USB/Linux-i386/300_create_extlinux.sh
but there it is used to write syslinux things there.

Is creating USB_REAR_DIR in output/USB/Linux-i386/300_create_grub.sh
perhaps only an obsolete leftover from some copy&paste?

@DEvil0000
Copy link
Contributor Author

Maybe the directory USB_REAR_DIR should be created elsewhere but it is used to store the kernel and initrd later as well as parts of syslinux config if syslinux is used. For one of the following scripts it needed to exist.

@jsmeix
Copy link
Member

jsmeix commented Jul 21, 2021

@DEvil0000
thank you for the info!

What a mess that old USB related code is!
The global looking variable USB_REAR_DIR is not used globally
but the $BUILD_DIR/outputfs/$USB_PREFIX directory is needed
so for now I at least explained things via
b20858a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adaptions and new features fixed / solved / done
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants