#2276 Issue `closed`: How to modify recovery system UEFI bootloader to boot the "normal" system by default?¶

Labels: enhancement, support / question, fixed / solved / done

Jorman opened issue at 2019-11-13 21:44:¶

Hi, I'm on Debian Buster and I just discovered rear, so rear is 2.4 for me
I followed some instruction to make a disk and till here, no problem

OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000

The problem came when I reboot the system, because the bios see the attached disk and start it before the "real" boot disk.
Unfortunately I can't change the disk boot order inside the bios so, how can I "force" the grub menu on rear disk in order to have the default start set to my system disk instead starting the rear one?
I searched a bit but I can't find exactly the solution.
I hope to leave the hdd attached to my system and put under cron the creation/update of the rear disk, in order to not have worry about any system problem

Any idea?

J

jsmeix commented at 2019-11-14 13:30:¶

@Jorman
on my test system the ReaR recovery system boot menu default entry is

Boot First Local disk (hd0)

I assume in your case it is the same default
but in your case that First Local disk
is not the "normal" system disk but the disk
where the ReaR recovery system is.

So you like to have the next ReaR recovery system boot menu entry

Boot Second Local disk (hd1)

as default ReaR recovery system boot menu entry.

The ReaR recovery system does not use GRUB to boot but syslinux.

The matching code to set up syslinux for the ReaR recovery system
is in usr/share/rear/lib/bootloader-functions.sh
the function make_syslinux_config
https://github.com/rear/rear/blob/master/usr/share/rear/lib/bootloader-functions.sh#L185
therein in particular the part about Use chain booting for booting disk
https://github.com/rear/rear/blob/master/usr/share/rear/lib/bootloader-functions.sh#L297
where the syslinux default boot menu entry is defined
depending on the syslinux target flavour.

I think you need to change that code because as far as I see
the ReaR recovery system default boot menu entry is hardcoded there.

Jorman commented at 2019-11-14 19:37:¶

Hi @jsmeix and thanks for your reply.
Apologize me if I'm not using all correct words, ReaR is pretty new for me.
My system always use first a botable usb so, when I reboot the system, ReaR recovery disk start.
I see the code and I also see this:
https://github.com/rear/rear/blob/2f66b904fdc1f69d31f1c9fa64e13a0964c21a38/usr/share/rear/lib/bootloader-functions.sh#L316-L321
So, maybe there's a way to "force" ReaR to extlinux? Maybe a single line to add to configuration?

What do you think?

J

jsmeix commented at 2019-11-15 11:00:¶

I enhanced my make_syslinux_config function
in usr/share/rear/lib/bootloader-functions.sh
as follows (excerpt):

    # Use chain booting for booting disk, if chain.c32 is available
    if [[ -r "$SYSLINUX_DIR/chain.c32" ]]; then
        cp $v "$SYSLINUX_DIR/chain.c32" "$BOOT_DIR/chain.c32" >&2

        echo "say boothd0 - boot first local disk"
        echo "label boothd0"
        syslinux_menu "label Boot First ^Local disk (hd0)"
        if [[ "$flavour" == "isolinux" ]] && [ "$ISO_DEFAULT" == "boothd" ] ; then
            # for isolinux local boot means boot from first disk
            echo "default boothd0"
            syslinux_menu "default"
        fi
        if test "boothd0" = "$ISO_DEFAULT" ; then
            # the user has explicitly specified to boot via boothd0 by default
            echo "default boothd0"
            syslinux_menu "default"
        fi
        echo "kernel chain.c32"
        echo "append hd0"
        echo ""

        echo "say boothd1 - boot second local disk"
        echo "label boothd1"
        syslinux_menu "label Boot ^Second Local disk (hd1)"
        if [[ "$flavour" == "extlinux" ]] && [ "$ISO_DEFAULT" == "boothd" ]; then
            # for extlinux local boot means boot from second disk because the boot disk became the first disk
            # which usually allows us to access the original first disk as second disk
            echo "default boothd1"
            syslinux_menu "default"
        fi
        if test "boothd1" = "$ISO_DEFAULT" ; then
            # the user has explicitly specified to boot via boothd1 by default
            echo "default boothd1"
            syslinux_menu "default"
        fi
        echo "kernel chain.c32"
        echo "append hd1"
        echo ""

    fi

i.e. I only added the parts

    if test "boothd0" = "$ISO_DEFAULT" ; then
        # the user has explicitly specified to boot via boothd0 by default
        echo "default boothd0"
        syslinux_menu "default"
    fi

and

    if test "boothd1" = "$ISO_DEFAULT" ; then
        # the user has explicitly specified to boot via boothd1 by default
        echo "default boothd1"
        syslinux_menu "default"
    fi

Now I can set in my etc/rear/local.conf

ISO_DEFAULT="boothd1"

to enforce that the boothd1 entry is used by default.

With also KEEP_BUILD_DIR="yes" in etc/rear/local.conf
I can compare the result of the default ISO_DEFAULT=boothd
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L663
with the result when ISO_DEFAULT="boothd1" is specified
which is in my case:

# diff -U2 /tmp/rear.NBwgusoCAP0TAzj/tmp/isolinux/isolinux.cfg /tmp/rear.KWNoc5BX2UthLxW/tmp/isolinux/isolinux.cfg
...
@@ -45,6 +45,4 @@
 label boothd0
 MENU label Boot First ^Local disk (hd0)
-default boothd0
-MENU default
 kernel chain.c32
 append hd0
@@ -53,4 +51,6 @@
 label boothd1
 MENU label Boot ^Second Local disk (hd1)
+default boothd1
+MENU default
 kernel chain.c32
 append hd1

@Jorman
do the same additions to your make_syslinux_config function
in your usr/share/rear/lib/bootloader-functions.sh and
set ISO_DEFAULT="boothd1" in your /etc/rear/local.conf
and re-run rear mkrescue and tell us if now it boots
from the second harddisk by default.

An addedum on Tue Dec 17 14:22:03 CET 2019:

Using ISO_DEFAULT="boothd1" in /etc/rear/local.conf
cannot work in case of OUTPUT=USB because
ISO_DEFAULT is only for OUTPUT=ISO
as the ISO prefix indicates and as documented in default.conf

For OUTPUT=USB the syslinux bootloader configuration happens via
output/USB/Linux-i386/300_create_extlinux.sh
where the default USB boot entry is hardcoded in a different way

    # Use chain booting for booting disk, if chain.c32 is available
    if syslinux_has "chain.c32"; then
        syslinux_write <<EOF
ontimeout boothd1
label boothd1
    say boothd1 - boot second local disk
    menu label Boot ^Local disk (hd1)
    menu default
    kernel chain.c32
    append hd1

label bootlocal
    say bootlocal - boot second local bios disk
    menu label Boot ^BIOS disk (0x81)
    text help
Use this when booting from local disk 0x81 does not work !
    endtext
    localboot 0x81

EOF

https://github.com/rear/rear/pull/2303
intends to enhance the recovery system BIOS boot default settings
for OUTPUT=USB and OUTPUT=ISO according to what
is described above in this particular issue comment.

With https://github.com/rear/rear/pull/2303 merged via
https://github.com/rear/rear/commit/a02ad4e5f3d1fc9299330287a4ba0c624e7d010c
the recovery system BIOS boot default settings for USB and ISO
are enhanced and documented in default.conf:

For OUTPUT=ISO the user can now explicitly specify
what to boot by default when booting the ISO on BIOS systems via
ISO_DEFAULT="boothd0" to boot from the first disk and
ISO_DEFAULT="boothd1" to boot from the second disk.

For OUTPUT=USB the user can now explicitly specify
what to boot by default when booting the disk on BIOS systems via
USB_BIOS_BOOT_DEFAULT="boothd0" to boot from the first disk.
The default USB_BIOS_BOOT_DEFAULT="" boots the second disk.

Jorman commented at 2019-11-15 12:29:¶

Wow, thanks!
I'll do the same modification and I'll try out the results!

Jorman commented at 2019-11-21 21:34:¶

Hi, I tried but for now is not working like expected.
I'm testing it on a headless systems so without monitor I can't say what happen during boot.
The only I can say now is that I made the modifications and then rear -v mkbackup
How can I check where's the problem?
Now the rear disk is not mounted (so if the system reboot start normally) and this's my configuration

$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda             8:0    0   1,8T  0 disk
└─sda1          8:1    0   1,8T  0 part  /data/Magia
sdb             8:16   0   3,7T  0 disk
└─sdb1          8:17   0   3,7T  0 part
  └─md0         9:0    0   3,7T  0 raid1
    ├─vg0-lv1 253:0    0  18,6G  0 lvm   /
    ├─vg0-lv0 253:1    0   2,9G  0 lvm   [SWAP]
    ├─vg0-lv2 253:2    0   4,7G  0 lvm   /home
    └─vg0-lv3 253:3    0   3,6T  0 lvm   /data
sdc             8:32   0   3,7T  0 disk
└─sdc1          8:33   0   3,7T  0 part
  └─md0         9:0    0   3,7T  0 raid1
    ├─vg0-lv1 253:0    0  18,6G  0 lvm   /
    ├─vg0-lv0 253:1    0   2,9G  0 lvm   [SWAP]
    ├─vg0-lv2 253:2    0   4,7G  0 lvm   /home
    └─vg0-lv3 253:3    0   3,6T  0 lvm   /data
sdd             8:48   0   1,8T  0 disk
└─sdd1          8:49   0   1,8T  0 part  /data/Sharing
sde             8:64   1   492M  0 disk
└─sde1          8:65   1   490M  0 part  /boot/efi
sdg             8:96   0 931,5G  0 disk
└─sdg1          8:97   0 931,5G  0 part

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vg0-lv1 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdc1 during installation
UUID=4BA7-208C  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/vg0-lv3 /data           ext4    nosuid,user_xattr 0       2
/dev/mapper/vg0-lv2 /home           ext4    defaults        0       2
/dev/mapper/vg0-lv0 none            swap    sw              0       0
UUID=3624EB3324EAF531 /data/Magia ntfs auto,nosuid,user_xattr,nofail 0       2
UUID=F00473F20473BA64 /data/Travel ntfs auto,nosuid,user_xattr,nofail 0       2
UUID=0be8c5c6-84a2-4236-9337-c12f41024344 /data/Sharing ext4 defaults,nofail 0       2

Do you've some idea?

jsmeix commented at 2019-11-26 11:01:¶

@Jorman
in your initial https://github.com/rear/rear/issues/2276#issue-522490145
you wrote bios
but now I see in your
https://github.com/rear/rear/issues/2276#issuecomment-557282250
/boot/efi

Jorman commented at 2019-11-26 12:28:¶

You right, my mistake, I get used to call it always bios, but is not the same!
Sorry if this caused some confusion to you, was not my intent
The machine has an old bios uefi capable, I think is CSM function, but I can't enter in bios anymore.
My disk layout are GPT and the boot is from efi

$ ls -lah /boot
totale 50M
drwxr-xr-x  4 root root 4,0K nov 17 06:42 .
drwxr-xr-x 19 root root 4,0K nov 24 09:13 ..
-rw-r--r--  1 root root 202K nov 11 01:30 config-4.19.0-6-amd64
drwx------  3 root root 4,0K gen  1  1970 efi
drwxr-xr-x  5 root root 4,0K nov 14 06:59 grub
-rw-r--r--  1 root root  42M nov 17 06:42 initrd.img-4.19.0-6-amd64
-rw-r--r--  1 root root 3,3M nov 11 01:30 System.map-4.19.0-6-amd64
-rw-r--r--  1 root root 5,1M nov 11 01:30 vmlinuz-4.19.0-6-amd64

# root @ Qnap in ~ [13:13:47]
$ ls /sys/firmware/efi
config_table  efivars  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars

This's the rear log after the last run, on 24-11-2019, when I did the modification
https://pastebin.com/JdxK4dAQ

Do you think is possible to make it work?

pcahyna commented at 2019-11-26 13:02:¶

Cc @chlupnoha

jsmeix commented at 2019-11-26 13:59:¶

@Jorman
to avoid confusion I recommend to use the word BIOS
only if you mean the legacy firmware in PC architecture
and also when you use the firmware in legacy BIOS mode
but the word EFI or UEFI if you mean nowadays firmware
that you use in its native way (i.e. as [U]EFI bootloader)
and the word firmware as generic name for such kind of software.
There is no such thing as BIOS that is UEFI capable
(old BIOS does not support [U]EFI) but there is firmware
that supports UEFI but can also run in legacy BIOS mode.

I do not know sufficiently about how the
recovery system UEFI bootloader setup
during "rear mkrescue" actually works
(I am one of those who avoid [U]EFI as much as possible)
so I cannot really help with recovery system UEFI bootloader issues.

The following scripts that are run during "rear mkrescue"
are the "usual suspects" for recovery system UEFI bootloader setup
in case of OUTPUT=USB

# usr/sbin/rear -s mkrescue | grep -i efi | egrep -vi 'efistub|prefix'

Source prep/default/320_include_uefi_env.sh
Source prep/default/330_include_uefi_tools.sh
Source rescue/default/850_save_sysfs_uefi_vars.sh
Source output/USB/Linux-i386/100_create_efiboot.sh

I would first of all have a look at
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh

To see what that scripts actually do run "rear mkrescue"
with full debugging i.e. run rear -D mkrescue
and inspect the log file.

Furthermore regarding UEFI boot with OUTPUT=USB
you must have your ReaR recovery system [USB]-disk prepared
for UEFI with the appropriate "rear format" workflow call, cf.
https://github.com/rear/rear/issues/2275#issuecomment-553802315
the right "rear format" command is also mentioned in
https://github.com/rear/rear/blob/master/usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh#L2

FYI
for comparison the "usual suspects" scripts for recovery system
UEFI bootloader setup in case of OUTPUT=ISO:

# usr/sbin/rear -s mkrescue | grep -i efi | egrep -vi 'efistub|prefix'

Source prep/default/320_include_uefi_env.sh
Source prep/default/330_include_uefi_tools.sh
Source rescue/default/850_save_sysfs_uefi_vars.sh
Source output/ISO/Linux-i386/250_populate_efibootimg.sh
Source output/ISO/Linux-i386/700_create_efibootimg.sh

jsmeix commented at 2019-11-26 14:00:¶

@gozora
perhaps you could have a look here - as time permits ?

Jorman commented at 2019-11-26 21:47:¶

@jsmeix
Understood!
I remember I had to use the rear format -- --efi /dev/sdX
In this case sdh is the rear disk

$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda             8:0    0   1,8T  0 disk
└─sda1          8:1    0   1,8T  0 part  /data/Magia
sdb             8:16   0   3,7T  0 disk
└─sdb1          8:17   0   3,7T  0 part
  └─md0         9:0    0   3,7T  0 raid1
    ├─vg0-lv1 253:0    0  18,6G  0 lvm   /
    ├─vg0-lv0 253:1    0   2,9G  0 lvm   [SWAP]
    ├─vg0-lv2 253:2    0   4,7G  0 lvm   /home
    └─vg0-lv3 253:3    0   3,6T  0 lvm   /data
sdc             8:32   0   3,7T  0 disk
└─sdc1          8:33   0   3,7T  0 part
  └─md0         9:0    0   3,7T  0 raid1
    ├─vg0-lv1 253:0    0  18,6G  0 lvm   /
    ├─vg0-lv0 253:1    0   2,9G  0 lvm   [SWAP]
    ├─vg0-lv2 253:2    0   4,7G  0 lvm   /home
    └─vg0-lv3 253:3    0   3,6T  0 lvm   /data
sdd             8:48   0   1,8T  0 disk
└─sdd1          8:49   0   1,8T  0 part  /data/Sharing
sde             8:64   1   492M  0 disk
└─sde1          8:65   1   490M  0 part  /boot/efi
sdg             8:96   0 931,5G  0 disk
└─sdg1          8:97   0 931,5G  0 part
sdh             8:112  0  55,9G  0 disk
├─sdh1          8:113  0   200M  0 part
└─sdh2          8:114  0  55,7G  0 part

Disk /dev/sdh: 55,9 GiB, 60022480384 bytes, 117231407 sectors
Disk model:  SV300S37A60G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CC8154D6-4121-4494-8E02-3ABE017A00C3

Dispositivo  Start      Fine   Settori  Size Tipo
/dev/sdh1    16384    425983    409600  200M EFI System
/dev/sdh2   425984 117229567 116803584 55,7G Linux filesystem

I'm not a programmer and rear is very new to me. I thought was only a grub menu option to modify, because the rear disk works when I reboot the system, but seem much complicated, sorry for that.
I did the rear -D mkrescue command but I don't know if I really understand all the log, I attach here the link of it maybe is more helpful for you guys
https://gofile.io/?c=zGnYLr

Do you think is better to point all to an ISO file?

gozora commented at 2019-11-27 07:01:¶

Hello @Jorman I don't think switching to ISO will help you. As far as I know, Grub2 UEFI based boot-loaders don't option to boot either first or second hard disk.
I'll try to find a way how such entry could be added, but I have no ETA for this.

V.

jsmeix commented at 2019-11-27 09:50:¶

From my limited end-user-only experience with UEFI booting
I have the impression that the boot devices ordering
is specified only in the UEFI firmware itself
but not in a UEFI application like BOOTX64.efi that is created by
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh

By the way: I found
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
which is from 2014 but I assume it is still correct.

Therein I read about The UEFI boot manager and efibootmgr
which could be the right tool to specify the boot devices ordering
because it has a --bootorder option that might be what is needed here?

As far as I see efibootmgr is called during "rear recover"
when reinstalling the UEFI bootloader on the target system
via finalize/Linux-i386/670_run_efibootmgr.sh
and efibootmgr is also called during "rear mkrescue"
when adding the Relax-and-Recover rescue system
to the local UEFI booting on the original system
via output/default/940_grub2_rescue.sh
but efibootmgr is not called during "rear mkrescue"
for the bootloader setup of the recovery system.

gozora commented at 2019-11-27 09:57:¶

@jsmeix Actually this is a very good point!
@Jorman do you know that you can change your boot order from inside your running OS using efibotomgr?

V.

jsmeix commented at 2019-11-27 10:28:¶

@gozora
I think changing the (UEFI) boot devices ordering on the original system
is not something that ReaR should ever do (and never ever automatically)
in particular not something that should happen during "rear mkrescue"
because "rear mkrescue/mkbackup" must not change anything
on the currently running (original) system.

The GRUB_RESCUE stuff should stay the only (scaring) exception, cf.
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2585

gozora commented at 2019-11-27 11:09:¶

@jsmeix I do agree!

That is why I've asked @Jorman in my https://github.com/rear/rear/issues/2276#issuecomment-559016101 do it manaully ;-)

V.

Jorman commented at 2019-11-27 12:44:¶

@jsmeix & @gozora thank you both for your support, very much appreciated!
Actually my system is quite strange:
I can't change the boot order from bios because I can't log into it anymore.
Is set to CSM capable, so I can boot from GPT EFI disks,
efibotomgr is not working like expected, I think is a bug of my firmware, so I need to fix the boot with this https://wiki.debian.org/GrubEFIReinstall#Problem1:_Weak_EFI_implementation_only_recognizes_the_fallback_bootloader
Whatever usb disk I attach to my system, in whatever position, if the disk is bootable, take the precedence upon the main disk.

Let me know if I can make some log or test to better understand this

gozora commented at 2019-11-27 22:18:¶

After some experimenting with Grub2 features, I've successfully added entry for booting OS original boot loader by chain loading it from ReaR recovery system boot menu.

If all tests goes well, we could end up with something like:
Screenshot from 2019-11-27
22-19-35

@Jorman I'll have (hopefully) some basic code for testing ready during next week (week 49) (last couple of months I'm very short on time), guess you want to be volunteer for testing it? ;-)

V.

Jorman commented at 2019-11-27 23:11:¶

@gozora
Yep, I can test if for you. For me is pretty simple, all the dirty and hard work is made by all of you, many thanks for this! I would help but I don't know if I can, there's a lot of code here!

gozora commented at 2019-11-28 07:24:¶

Hello @Jorman,

Don't worry, once the code is ready, all you will need to do is download, install, run, reboot and post back your results.
No coding or code review will be required from your site ;-).

I'll send you instructions what to do once I have it prepared.

V.

jsmeix commented at 2019-11-28 08:28:¶

@gozora
WOW!

As "reward" for all your work here
I even dared to assign this issue to you ;-)

gozora commented at 2019-11-28 08:38:¶

@jsmeix Thank you kind sir! ;-)

Should anybody be interested, this is the repository with WIP code.

jsmeix commented at 2019-11-28 11:18:¶

@gozora
in your https://github.com/gozora/rear/tree/uefi_menu
there is for function create_grub2_cfg in lib/bootloader-functions.sh

menuentry "Boot original system" {
    search --fs-uuid --no-floppy --set=root 78F9-F844
    chainloader (\$root)/EFI/sles_sap/shim.efi
    bla bla $UEFI_BOOTLOADER
    tst1: ${UEFI_BOOTLOADER#$(df $UEFI_BOOTLOADER | tail -n 1 | awk '{print $NF}')}
}

with a currently WIP hardcoded chainloader value.
E.g. on my openSUSE Leap 15.0 system that is
/boot/efi/EFI/opensuse/shim.efi
where the ESP is mounted on /boot/efi.

I suggest to make this value in any case a user config variable
or does this chainloader value perhaps match the currrent
UEFI_BOOTLOADER or SECURE_BOOT_BOOTLOADER values?

If this chainloader value can be different in some cases
a separated user config variable like UEFI_CHAINLOADER
would be needed so that the user can enforce what he needs.

If empty ReaR could do some reasonable automatism or use
a generic fallback value (e.g. EFI/boot/bootx64.efi) if possible
but that is optional "nice to have" functionality.

gozora commented at 2019-11-28 11:45:¶

Hello @jsmeix I'm afraid that that only OS where this code currently works is owned by me ;-). The values are hard coded because I did not want to spend time with polishing and getting variables until I know that my solution actually works ...

In other words uefi_menu branch is just a prototype that will be later in process enhanced with something like:

diff --git a/usr/share/rear/lib/bootloader-functions.sh b/usr/share/rear/lib/bootloader-functions.sh
index 07e7b517..f8b15e0f 100644
--- a/usr/share/rear/lib/bootloader-functions.sh
+++ b/usr/share/rear/lib/bootloader-functions.sh
@@ -487,6 +487,14 @@ function get_root_disk_UUID {
 function create_grub2_cfg {
 root_uuid=$(get_root_disk_UUID)

+# Get mount point where boot loader resides.
+#
+local esp_info=$(df $UEFI_BOOTLOADER | tail -n 1)
+local esp_mpt=$(echo $esp_info | awk '{print $NF}')
+local esp_disk=$(echo $esp_info | awk '{print $1}')
+local esp_relative_bootloader=${UEFI_BOOTLOADER#$esp_mpt}
+local esp_disk_uuid=$(lsblk --noheadings --output uuid $esp_disk)
+
 cat << EOF
 set default="2"

@@ -521,11 +529,8 @@ menuentry "Relax-and-Recover (Secure Boot)"  --class gnu-linux --class gnu --cla
 }

 menuentry "Boot original system" {
-    search --fs-uuid --no-floppy --set=root 78F9-F844
-    chainloader (\$root)/EFI/sles_sap/shim.efi
-
-    bla bla $UEFI_BOOTLOADER
-    tst1: ${UEFI_BOOTLOADER#$(df $UEFI_BOOTLOADER | tail -n 1 | awk '{print $NF}')}
+    search --fs-uuid --no-floppy --set=root $esp_disk_uuid
+    chainloader (\$root)$esp_relative_bootloader
 }

and of course some explanatory comments ;-)

V.

jsmeix commented at 2019-11-29 13:35:¶

@gozora
only an offhanded (totally untested) idea how to find out
what EFI binary should be used by default or as fallback
to boot the original system:

On my openSUSE Leap 15.0 system I get

# efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0016,0017,0014,001A,0012,0013,0015,0010
Boot0000* opensuse-secureboot   HD(1,GPT,841a03d5-4e52-4634-b21a-43935c88f5af,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)
Boot0010  Diskette Drive        BBS(Floppy,Diskette Drive,0x0)..BO
...

I think BootCurrent: 0000 shows how the
currently running system was booted and its entry

Boot0000* .../File(\EFI\opensuse\shim.efi)

shows the matching EFI binary EFI\opensuse\shim.efi
that was used to boot the currently running system.

This EFI binary appears in my currently running system
as /boot/efi/EFI/opensuse/shim.efi
where the ESP is mounted on /boot/efi cf. my above
https://github.com/rear/rear/issues/2276#issuecomment-559453503

So I think the efibootmgr -v output can be used to find out
what EFI binary should be used by default or as fallback
to boot the original system.

The idea behind is that "boot the original system" means
"boot what was running while rear mkrescue was run"

jsmeix commented at 2019-11-29 13:40:¶

FYI
I noticed right now that on my openSUSE Leap 15.0 system

# diff -s /boot/efi/EFI/opensuse/shim.efi /boot/efi/EFI/boot/bootx64.efi
Files /boot/efi/EFI/opensuse/shim.efi and /boot/efi/EFI/boot/bootx64.efi are identical

so that in my case even the generic
UEFI firmware fallback /EFI/boot/bootx64.efi
would boot "the right thing".

gozora commented at 2019-11-29 19:05:¶

Hello @jsmeix,

What you see in your efibootmgr -v is just one case.
It is very common case indeed, but by far not the only one.

Let me show you couple of other configurations:

QEMU directly loaded by kernel and initrd options (no booloader used)
direct_kernel_initrd

UEFI firmware defaults
When you don't have any UEFI boot entry present, UEFI looks for boot loader in some default locations. If you name your boot loader bootx64.efi and place it under _\EFI\BOOT_ it will be loaded without need of any boot entry in UEFI menu. Once server is up, your efibootmgr -v will look something like:
boot_bootx64

Chainload
If you decide to boot your system using Grub2 chainloading (e.g. you don't have boot loader installed directly on your OS disk, but e.g. on some other device), You might get something like this:
Screenshot from 2019-11-29
19-37-41

startup.nsh / Internal Shell
If you might have trouble like I do with VirbualBox, which doesn't remember UEFI boot entries when machine is power cycled, you might either use UEFI firmware defaults or automatic startup file called startup.nsh which when placed into ESP top directory will be executed and boot what every your hart desires. I'm using startup.nsh to EFISTUB boot my Arch:

arch-efi:(/boot)(root)# cat startup.nsh 
fs0:
vmlinuz-linux initrd=initramfs-linux.img root=PARTUUID="cd4e03d7-40ac-4a67-b271-4e885edf4b3f"

In this scenario your efibootmgr -v will show:
Screenshot from 2019-11-29
19-54-23

efivarfs not mounted
Another issue we might meet is efivarfs not mouted, in this case you will get plain:

arch-efi:(/root)(root)# efibootmgr -v
EFI variables are not supported on this system.

As you can see, it is not that easy to find out how was your system booted.

I've decided to look for the boot loader with simplest idea that came to my mind, using ReaRs UEFI_BOOTLOADER variable. Using this approach we will have both consistency, and user can override this value if needed, hence user will have the final power ;-).

V.

Jorman commented at 2019-11-29 20:59:¶

If can in someway help, here my efibootmgr:

$ efibootmgr -v
BootCurrent: 0015
Timeout: 0 seconds
BootOrder: 0015,001A,001B,0016,0017,0018,001C,001D,001E,001F,0020,0021
Boot000A* ATA HDD2:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000B* ATA HDD3:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot000C* ATA HDD4:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot000D* ATA HDD5:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f605)
Boot000E* Other HDD:    VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f609)
Boot000F* Internal Shell        FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0010* ATA HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0011* Boot Next Boot Option VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,a7ca6d35b2c2684783721826a7404894)
Boot0012  Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0013  Boot Menu     FvFile(86488440-41bb-42c7-93ac-450fbf7766bf)
Boot0014  Diagnostic Splash     FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0015* USB HDD:      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot0016* USB CD:       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0017* USB FDD:      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0018* ATAPI CD:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0019* CD-ROM:       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,be9d0102e211f3489efa0b983c96839b)
Boot001A* ATA HDD0:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot001B* ATA HDD1:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot001C* ATA HDD2:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot001D* ATA HDD3:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot001E* ATA HDD4:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot001F* ATA HDD5:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f605)
Boot0020* Other HDD:    VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f609)
Boot0021* Internal Shell        FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0022* ATA HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0023* Boot Next Boot Option VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,a7ca6d35b2c2684783721826a7404894)

Jorman commented at 2019-11-29 22:59:¶

@gozora
Maybe is a stupid idea or is not relevant, I'll try to explain to you.
We know the disk-id where rear create the emergency disk, so, is not possible to set the boot loader in order to skip the same (rear) disk-id during boot? In this way when the system boot-up and the boot loader find the same disk id, after X seconds without any key pressed, skip to very nexrt boot

Is so stupid

gozora commented at 2019-11-30 08:50:¶

Hello @Jorman it is not stupid idea ;-). I already have working prototype ready. It however need some polishing. But if you want you can try it here.

V.

Jorman commented at 2019-12-02 12:35:¶

@gozora
I can try if you think is the time to make some test
Just let me know if I have to make particular installation or some extra.

J

gozora commented at 2019-12-07 11:24:¶

Hello @Jorman,

If you are still interested, you can test the code in my uefi_menu branch whether it helps to solve problem of yours.

In general you need to:

download code from mentioned branch
install it
add GRUB2_DEFAULT_BOOT="2" to your /etc/rear/local.conf or /etc/rear/site.conf (this will make boot your original system as default when UEFI launches ReaR recovery system from your USB disk)
trigger rear mkbackup (or at least rear mkrescue) to refresh data in your current ReaR recovery system
reboot your system to see if all works as expected
post the results here

Good luck with your tests!

V.

gozora commented at 2019-12-07 11:32:¶

@Jorman
In general your Grub2 menu, (when installed from mentioned branch) should look something like this:
Screenshot from 2019-12-07
12-29-46

V.

Jorman commented at 2019-12-07 13:24:¶

Hi @gozora
Yep, I'm interested in this modification, in this way I can better handle all and leave the recovery disk always attached, so with duplicati that save extra data I can have more protection!
I'll make like you said, and I'll report results.

Thanks in advance!

Jorman commented at 2019-12-08 14:40:¶

@gozora
I did the test but I got some error, here what I did:

Clone your repo (root folder)
Switch to uefi_menu branch
Copy the old configuration and add GRUB2_DEFAULT_BOOT="2"
Use the usr/sbin/rear format -- --efi /dev/sdh
Use usr/sbin/rear -v mkbackup

Note that I worked inside /root/rear folder, the one where I cloned your repo, maybe was not a good idea?

The configuration:

# Default is to create Relax-and-Recover rescue media as ISO image
# set OUTPUT to change that
# set BACKUP to activate an automated (backup and) restore of your data
# Possible configuration values can be found in /usr/share/rear/conf/default.conf
#
# This file (local.conf) is intended for manual configuration. For configuration
# through packages and other automated means we recommend creating a new
# file named site.conf next to this file and to leave the local.conf as it is. 
# Our packages will never ship with a site.conf.
### write the rescue initramfs to USB and update the USB bootloader
OUTPUT=USB
#OUTPUT=OBDR
#ISO_DEFAULT="boothd1"
GRUB2_DEFAULT_BOOT="2"
### create a backup using the internal NETFS method, using 'tar'
BACKUP=NETFS
### write both rescue image and backup to the device labeled REAR-000
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
### Exclude certain items
EXCLUDE_MOUNTPOINTS=( /data )

The logs:
https://pastebin.com/WkGhPuQw
https://pastebin.com/ypWrCkrC

What I did wrong?

gozora commented at 2019-12-08 18:32:¶

Your backup failed because some problem with openssl:

ERROR: openssl failed with return code 1 and below output:

Which is strange because openssl is used for encryption of archive, which is not happening according provided config file.

Can you run rear -d -D mkbackup and attach it to this thread ?

Thanks

V.

Jorman commented at 2019-12-08 21:24:¶

Yep, sure, here the entire log file
https://filebin.net/gdini86jaesuhp55

I don't know why this error

gozora commented at 2019-12-08 21:44:¶

@Jorman 2 things

You can attach files directly to github issue by dragndrop (some people might not feel safe to click third party links ...)
Problem described in your last log is different from previous one:

original issue:

2019-12-07 23:34:54.512145979 ERROR: openssl failed with return code 1 and below output:

current issue:

 mkdir: cannot create directory '\''/tmp/rear.4GjUebHeM9fPWuH/outputfs/rear/Qnap/20191208.2033'\'': No space left on device'

So try to cleanup some space on your USB disk and try to re-run rear -d -D mkbackup ...

V.

Jorman commented at 2019-12-09 12:38:¶

Yep, you right, I don't know if a large file can be attached here, I'll try

I just noticed that all the space is used to make the backup, but is wrong, my configuration is set to exclude /data
EXCLUDE_MOUNTPOINTS=( /data )
But to me seems that don't include all the folder inside, so I modified it
EXCLUDE_MOUNTPOINTS=( /data/* )
But again all the space is used!
I think openssl don't is the problem, the problem is that the space ends
An extract of the log say:

+ Debug 'Leaving debugscript mode (back to previous bash flags and options settings).'
+ test 1
+ Log 'Leaving debugscript mode (back to previous bash flags and options settings).'
+ echo '2019-12-08 23:52:03.344505773 Leaving debugscript mode (back to previous bash flags and options settings).'
2019-12-08 23:52:03.344505773 Leaving debugscript mode (back to previous bash flags and options settings).
2019-12-08 23:52:03.364982424 Including backup/NETFS/default/400_create_include_exclude_files.sh
2019-12-08 23:52:03.370581968 Entering debugscript mode via 'set -x'.
+ source /root/rear/usr/share/rear/backup/NETFS/default/400_create_include_exclude_files.sh
++ is_true no
++ case "$1" in
++ return 1
++ '[' NO '!=' YES ']'
++ read mountpoint device junk
++ IsInArray / /data/Download /data/Fanny /data/Jorman /data/Magia /data/Multimedia /data/Sharing /data/Travel /data/Varie /data/lost+found
++ return 1
++ echo /
++ read mountpoint device junk
++ IsInArray /home /data/Download /data/Fanny /data/Jorman /data/Magia /data/Multimedia /data/Sharing /data/Travel /data/Varie /data/lost+found
++ return 1
++ echo /home
++ read mountpoint device junk
++ IsInArray /data /data/Download /data/Fanny /data/Jorman /data/Magia /data/Multimedia /data/Sharing /data/Travel /data/Varie /data/lost+found
++ return 1
++ echo /data
++ read mountpoint device junk
++ IsInArray /boot/efi /data/Download /data/Fanny /data/Jorman /data/Magia /data/Multimedia /data/Sharing /data/Travel /data/Varie /data/lost+found
++ return 1
++ echo /boot/efi
++ read mountpoint device junk
++ for backup_exclude_item in "${BACKUP_PROG_EXCLUDE[@]}"
++ test '/tmp/*'
++ echo '/tmp/*'
++ for backup_exclude_item in "${BACKUP_PROG_EXCLUDE[@]}"
++ test '/dev/shm/*'
++ echo '/dev/shm/*'
++ for backup_exclude_item in "${BACKUP_PROG_EXCLUDE[@]}"
++ test '/root/rear/var/lib/rear/output/*'
++ echo '/root/rear/var/lib/rear/output/*'
++ for backup_exclude_item in "${BACKUP_PROG_EXCLUDE[@]}"
++ test /tmp/rear.WMvH8jK4z0EGQNM
++ echo /tmp/rear.WMvH8jK4z0EGQNM
++ is_true no
++ case "$1" in
++ return 1
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Download
++ echo /data/Download/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Fanny
++ echo /data/Fanny/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Jorman
++ echo /data/Jorman/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Magia
++ echo /data/Magia/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Multimedia
++ echo /data/Multimedia/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Sharing
++ echo /data/Sharing/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Travel
++ echo /data/Travel/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/Varie
++ echo /data/Varie/
++ for excluded_mountpoint in "${EXCLUDE_MOUNTPOINTS[@]}"
++ test /data/lost+found
++ echo /data/lost+found/
+ source_return_code=0
+ test 0 -eq 0
+ test 1
+ Debug 'Leaving debugscript mode (back to previous bash flags and options settings).'
+ test 1
+ Log 'Leaving debugscript mode (back to previous bash flags and options settings).'
+ echo '2019-12-08 23:52:03.411715609 Leaving debugscript mode (back to previous bash flags and options settings).'
2019-12-08 23:52:03.411715609 Leaving debugscript mode (back to previous bash flags and options settings).
2019-12-08 23:52:03.431887668 Including backup/NETFS/default/500_make_backup.sh
2019-12-08 23:52:03.437417650 Entering debugscript mode via 'set -x'.
+ source /root/rear/usr/share/rear/backup/NETFS/default/500_make_backup.sh
+++ url_scheme usb:///dev/disk/by-label/REAR-000
+++ local url=usb:///dev/disk/by-label/REAR-000

To me seems all ok, but I don't know why the backup is too big

$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda             8:0    0   1,8T  0 disk
└─sda1          8:1    0   1,8T  0 part  /data/Magia
sdb             8:16   0   3,7T  0 disk
└─sdb1          8:17   0   3,7T  0 part
  └─md0         9:0    0   3,7T  0 raid1
    ├─vg0-lv1 253:0    0  18,6G  0 lvm   /
    ├─vg0-lv0 253:1    0   2,9G  0 lvm   [SWAP]
    ├─vg0-lv2 253:2    0   4,7G  0 lvm   /home
    └─vg0-lv3 253:3    0   3,6T  0 lvm   /data
sdc             8:32   0   3,7T  0 disk
└─sdc1          8:33   0   3,7T  0 part
  └─md0         9:0    0   3,7T  0 raid1
    ├─vg0-lv1 253:0    0  18,6G  0 lvm   /
    ├─vg0-lv0 253:1    0   2,9G  0 lvm   [SWAP]
    ├─vg0-lv2 253:2    0   4,7G  0 lvm   /home
    └─vg0-lv3 253:3    0   3,6T  0 lvm   /data
sdd             8:48   0   1,8T  0 disk
└─sdd1          8:49   0   1,8T  0 part  /data/Sharing
sde             8:64   1   492M  0 disk
└─sde1          8:65   1   490M  0 part  /boot/efi
sdf             8:80   0 931,5G  0 disk
└─sdf1          8:81   0 931,5G  0 part  /data/Travel
sdg             8:96   0  55,9G  0 disk
├─sdg1          8:97   0   400M  0 part
└─sdg2          8:98   0  55,5G  0 part

At this time sdg is the read disk and like you can see I want to exclude all inside /data
I attach the log here.

I make some error but I don't know where.

J
rear-Qnap.zip

gozora commented at 2019-12-09 14:05:¶

You can try:

BACKUP_PROG_EXCLUDE=(
     ${BACKUP_PROG_EXCLUDE[@]}
     /data
)

V.

Jorman commented at 2019-12-09 20:31:¶

Now seems to work!
I created the backup, I think without error, I attach the log file here.
I rebooted and the system is started normally, so seems to work!
I don't have a monitor attached, if you need I can borrow a monitor and try with it
rear-Qnap.log

gozora commented at 2019-12-09 21:00:¶

Hello @Jorman,

I personally don't need any further confirmations, but if I were you, I'd try it just to be sure that you can rely on such setup...

I'll try to put fixing code to ReaR upstream after https://github.com/rear/rear/pull/2293 is merged, since they are kind of related. Until that time you can keep using version downloaded from https://github.com/gozora/rear/tree/uefi_menu.

@jsmeix @gdha please keep this issue open. I think that first we should deal with #2293 and afterwards I'll create PR to fix this problem.

V.

Jorman commented at 2019-12-09 21:44:¶

Ok! Many thanks I'll make some extra test to see if all works correctly!

gozora commented at 2020-03-17 18:06:¶

With #2326 merged, this issue can be closed.

V.

jsmeix commented at 2020-03-18 12:23:¶

@Jorman
we would appreciate it if you could verify (as your time permits)
that things work for you with our current GitHub master code.

See "Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

Jorman commented at 2020-03-18 13:13:¶

@jsmeix
I'll for sure.
I'have to install it from scratch, so first I clone the master branch then I make a deb, but for the configuration is changed some? I remember I modified the configuration adding some but is still the same code or is changed?

[Export of Github issue for rear/rear.]

#2276 Issue closed: How to modify recovery system UEFI bootloader to boot the "normal" system by default?¶

Jorman opened issue at 2019-11-13 21:44:¶

jsmeix commented at 2019-11-14 13:30:¶

Jorman commented at 2019-11-14 19:37:¶

jsmeix commented at 2019-11-15 11:00:¶

Jorman commented at 2019-11-15 12:29:¶

Jorman commented at 2019-11-21 21:34:¶

jsmeix commented at 2019-11-26 11:01:¶

Jorman commented at 2019-11-26 12:28:¶

pcahyna commented at 2019-11-26 13:02:¶

jsmeix commented at 2019-11-26 13:59:¶

jsmeix commented at 2019-11-26 14:00:¶

Jorman commented at 2019-11-26 21:47:¶

gozora commented at 2019-11-27 07:01:¶

jsmeix commented at 2019-11-27 09:50:¶

gozora commented at 2019-11-27 09:57:¶

jsmeix commented at 2019-11-27 10:28:¶

gozora commented at 2019-11-27 11:09:¶

Jorman commented at 2019-11-27 12:44:¶

gozora commented at 2019-11-27 22:18:¶

Jorman commented at 2019-11-27 23:11:¶

gozora commented at 2019-11-28 07:24:¶

jsmeix commented at 2019-11-28 08:28:¶

gozora commented at 2019-11-28 08:38:¶

jsmeix commented at 2019-11-28 11:18:¶

gozora commented at 2019-11-28 11:45:¶

jsmeix commented at 2019-11-29 13:35:¶

jsmeix commented at 2019-11-29 13:40:¶

gozora commented at 2019-11-29 19:05:¶

Jorman commented at 2019-11-29 20:59:¶

Jorman commented at 2019-11-29 22:59:¶

gozora commented at 2019-11-30 08:50:¶

Jorman commented at 2019-12-02 12:35:¶

gozora commented at 2019-12-07 11:24:¶

gozora commented at 2019-12-07 11:32:¶

Jorman commented at 2019-12-07 13:24:¶

Jorman commented at 2019-12-08 14:40:¶

gozora commented at 2019-12-08 18:32:¶

Jorman commented at 2019-12-08 21:24:¶

gozora commented at 2019-12-08 21:44:¶

Jorman commented at 2019-12-09 12:38:¶

gozora commented at 2019-12-09 14:05:¶

Jorman commented at 2019-12-09 20:31:¶

gozora commented at 2019-12-09 21:00:¶

Jorman commented at 2019-12-09 21:44:¶

gozora commented at 2020-03-17 18:06:¶

jsmeix commented at 2020-03-18 12:23:¶

Jorman commented at 2020-03-18 13:13:¶

#2276 Issue `closed`: How to modify recovery system UEFI bootloader to boot the "normal" system by default?¶