#1214 Issue closed: Add support for Arch Linux systemd-boot f.k.a. gummiboot (UEFI boot)

Labels: enhancement, discuss / RFC

ProBackup-nl opened issue at 2017-03-01 18:10:

systemd-boot (f.k.a. gummiboot) is a simple UEFI boot manager which executes configured EFI images. systemd-boot is included with the systemd, which is installed on an Arch Linux system by default.

Change in Relax-and-Recover:

Detection on x86-64 systems:

  • file exists: /boot/loader/loader.conf (optional, systemd-boot can even boot without this file)
  • file exists: /boot/EFI/systemd/systemd-bootx64.efi
  • file exists: /boot/EFI/Boot/BOOTX64.EFI
  • at least 1 file matching /boot/loader/entries/*.conf
  • /boot/EFI/systemd/systemd-bootx64.efi is identical to /boot/EFI/Boot/BOOTX64.EFI (md5sum)

Mkrescue command needs to copy at least these files to the new recovery partition to reach a recovery prompt:

  • /boot/initramfs-linux.img
  • /boot/intel-ucode.img
  • /boot/vmlinuz-linux

Optional copy:

  • /boot/initramfs-linux-fallback.img

For each recovery menu line create a corresponding .conf file at recoveryESP/loader/entries/.

Create recoveryESP/loader/loader.conf file, with contents like:

  • timeout 999999 (0 will not show a menu)
  • editor 1

ProBackup-nl commented at 2017-03-01 21:32:

@gozora Some hints on whether this "feature request" fits Relax-and-Recover, and how/where to plug this in, are welcome. I would guess next to Lilo and Grub.

jsmeix commented at 2017-03-02 08:42:

@ProBackup-nl
what is the reason behind why ReaR should also support
systemd-boot/gummiboot?

Is it that systemd-boot/gummiboot is used as bootloader
on the original system and during "rear recover" ReaR
must reinstall the systemd-boot/gummiboot bootloader
in the recreated system (i.e. via chroot into /mnt/local/)?

Or is it that systemd-boot/gummiboot should be used as
bootloader of ReaR's own recovery system?

In the latter case I wonder why ReaR should support
two bootloaders for its own recovery system because
that would mean we need someone who implements it
and then - even more important - who continuously
maintains this functionality (i.e. updates and bugfixes).
Would you @ProBackup-nl do that?

From my point of view the only reason why to use another
bootloader for ReaR's own recovery system would be
when the current syslinux is actually insufficient.

Furthermore in general regarding what to use as future
bootloader for ReaR's own recovery system see also
https://github.com/rear/rear/issues/764

ProBackup-nl commented at 2017-03-04 00:41:

@jsmeix
The latter is my request: systemd-boot/gummiboot should be used as bootloader of ReaR's own recovery system.

When ReaR would support systemd-boot/gummiboot then no extra 4.61 MiB of syslinux-6.03-6 software installation is needed for Arch Linux systems, because a default Arch Linux installation already contains systemd-boot.

schlomo commented at 2017-03-06 10:37:

@ProBackup-nl so what about non-UEFI systems? I think your suggestion is worth following after we get rid of supporting BIOS booting.

OTOH I think that we also should consider GRUB as the "universal" boot loader for the ReaR rescue system as it probably supports most if not all of our platforms.

With regard to detection, IMHO the only way to go is to check the output of efibootmgr and follow the breadcrumb trail from there:

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000
Boot0000* ubuntu    HD(1,GPT,ef2a7e35-5378-4d76-8d7c-024c8f67de08,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Once you do that you will know for sure how this system was booted. Everything else is just blind guessing. That it IMHO actually a big advantage of UEFI in general, that we can actually ask the UEFI BIOS about how it boots the computer.

While I wholeheartedly support the beauty of systemd and its holistic approach to Linux, ReaR must keep supporting older systems. Therefore we either split the relevant code paths in ReaR into a legacy and a systemd path or we stick with the legacy stuff till nobody needs it any more.

If your goal is reducing the size of the rescue system then firmware is indeed a good start, if you are willing to compromise on hardware support during recovery. Otherwise please note that most backup software adds 50-300MB to the rescue image size when included. And that is still the primary use case for ReaR: Supplementing backup software with true bare metal disaster recovery. Optimizing the rescue image size for the included backup methods (tar, rsync ...) will therefore only help a part of our users and even that depends on the other things that they choose to include.

ProBackup-nl commented at 2017-03-06 11:26:

@schlomo Regarding "non-UEFI systems"? They will still use the mechanisms that are currently in ReaR.

There are even more UEFI booted situations:

# efibootmgr -v
No BootOrder is set; firmware will attempt recovery

With my little knowledge of ReaR I would start inserting code into rear/usr/share/rear/prep/USB/Linux-i386/340_find_mbr_bin.sh.

For the suggestion to split the relevant code paths in ReaR into a legacy and a systemd path, at which file would you start the split?

Not including rsync is a bad example to reduce space for someone that is willing to use RBME. I hope that RBME will not add 300MB :-)

gozora commented at 2017-03-06 11:32:

Hello @schlomo

OTOH I think that we also should consider GRUB as the "universal" boot loader for the ReaR rescue system as it probably supports most if not all of our platforms.

I can say that e.g. SLES11 SP4 uses elilo once installed on UEFI.

V.

gozora commented at 2017-03-06 11:33:

@ProBackup-nl careful with UEFI boot, doesn't matter how simple it might look, it is very easy to break!

V.

ProBackup-nl commented at 2017-03-09 00:17:

it is very easy to break

An example: having set the EFI boot menu using efibootmgr, after the first reboot the EFI boot menu can be completely vanished:

# efibootmgr -v
No BootOrder is set; firmware will attempt recovery

ProBackup-nl commented at 2017-03-09 16:11:

I will also add some minor improvements, including labelling the GPT partitions so parted ... printwill show partitions with information that gives more clues what the purpose of each partition is:

Number  Start    End       Size      File system  Name      Flags
 1      4.00MiB  100MiB    96.0MiB   fat16        EFIBOOT   boot, esp
 2      100MiB   14906MiB  14806MiB  ext2         REARDATA

Instead of:

Number  Start    End       Size      File system  Name  Flags
 1      4.00MiB  100MiB    96.0MiB   fat16              legacy_boot
 2      100MiB   14906MiB  14806MiB  ext2

ProBackup-nl commented at 2017-03-09 21:51:

Also add EFISTUB systemd-boot support to bootloader detection. For instance at rear/usr/share/rear/prep/default/500_guess_bootloader.sh:

echo "SYSTEMD-BOOT" >$VAR_DIR/recovery/bootloader

ProBackup-nl commented at 2017-03-10 01:16:

Status: boot menu is OK when booting from ReaR rescue USB device; Kernel panic - Unable to mount root fs on unknown-block(0,0) initramfs unpacking failed: junk in compressed archive; I need to check whether a RAM based root fs will improve.

ProBackup-nl commented at 2017-03-10 22:20:

Still stuck at the kernel panic. The current Arch Linux kernel is build like:

CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16 #number
CONFIG_BLK_DEV_RAM_SIZE=16384 #size in kb

Where CONFIG_BLK_DEV_RAM=m makes the RAM drive a module. Though I yet can't find which file name the module carries. What are the chances that CONFIG_BLK_DEV_RAM=m makes
it impossible to pass an initrd image since populate_rootfs() in init/initramfs.c omits
code for checking whether the image is an initrd or not?

ProBackup-nl commented at 2017-03-10 22:46:

initramfs unpacking failed: junk in compressed archive

This error is caused by the the lz4 initramfs compression I added in #1218. When switching back to "fast" initramfs compression, the systemd-boot (menu) boot to Relax-and-Recover 2.00 / Git succeeds.

Thanks go to: https://bbs.archlinux.org/viewtopic.php?id=137961

ProBackup-nl commented at 2017-03-11 11:19:

EFISTUB boot loader

Now systemd-boot boot loader is implemented at 100_create_efiboot it is time to work on the EFISTUB boot loader using the UEFI boot menu. That is the boot loader menu that is integrated into the UEFI firmware.

ProBackup-nl commented at 2017-03-11 19:56:

Mmm, there already is .../finalize/Linux-i386/230_run_efibootmgr.sh.

Why isn't that script executed upon rear mkrescue?

My guess, because the script is in the folder Linux-i386 instead of GNU/Linux.

Can't this script be moved to default?

jsmeix commented at 2017-03-13 09:34:

@ProBackup-nl
in general regarding why some scripts are sourced or not
see the SourceStage function in
lib/framework-functions.sh

I.e. something like .../stage_name/default/123_foo.sh
gets always souced for stage 'stage_name'
but .../stage_name/Linux-i386/456_bar.sh
is only souced when one of those zillions of variables
that are tested in the SourceStage function is "Linux-i386".

Caution with moving a script to 'default' because then
this script is sourced in any case.
I would recommend to better set one of those zillions
of variables right for Arch Linux so that
finalize/Linux-i386/230_run_efibootmgr.sh
gets sourced.

How to set those variables right for Arch Linux see
the SetOSVendorAndVersion function in
lib/config-functions.sh
There is already a (archlinux) case but I assume
this needs some enhancements to actually work well.

Regarding what stages are sourced for a workflow,
see the WORKFLOW_workflow_name functions
in the lib/workflow_name-workflow.sh scriprts,
e.g. for the 'recover" workflow
the WORKFLOW_recover function
in lib/recover-workflow.sh

ProBackup-nl commented at 2017-03-14 01:21:

@jsmeix To me it looks like "Linux-i386" is starting to be configured around line 77 of https://github.com/rear/rear/blob/4fb1f98a2b6ff777e006424ff991d1bd27029018/usr/share/rear/conf/default.conf#L77 ... where at line 79 https://github.com/rear/rear/blob/4fb1f98a2b6ff777e006424ff991d1bd27029018/usr/share/rear/conf/default.conf#L79 the "x86_64" of uname -m is converted to i386.

The "Linux" part is configured at line 89 using uname -s.

When my head is clearer I will try again to have a look at why finalize/Linux-i386/230_run_efibootmgr.sh doesn't seem to get sourced.

gdha commented at 2017-03-14 07:31:

@ProBackup-nl Could you run rear dump once so we can what ReaR thinks it has under his motor cap?

jsmeix commented at 2017-03-14 08:45:

@ProBackup-nl
with probability one (https://en.wikipedia.org/wiki/Almost_surely)
I confused how exactly what of those zillions of variables is set ;-)

In general to find out how exactly something happens inside ReaR,
run it with full debugging "rear -d -D ..." and inspect the log file, cf.
"Debugging issues with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery

jsmeix commented at 2017-03-14 13:54:

FYI
regarding the SetOSVendorAndVersion function
and the (perhaps buggy?) SourceStage function, see
https://github.com/rear/rear/pull/1241

ProBackup-nl commented at 2017-03-14 13:59:

@gdha

# usr/sbin/rear dump
Relax-and-Recover 2.00 / Git
Using log file: /root/rear/var/log/rear/rear-d2.log.lockless
Dumping out configuration and system information
This is a 'Linux-x86_64' system, compatible with 'Linux-i386'.
System definition:
                                    ARCH = Linux-i386
                                      OS = GNU/Linux
                        OS_MASTER_VENDOR =
                       OS_MASTER_VERSION = rolling
                   OS_MASTER_VENDOR_ARCH = i386
                OS_MASTER_VENDOR_VERSION = rolling
           OS_MASTER_VENDOR_VERSION_ARCH = rolling/i386
                               OS_VENDOR = Arch
                              OS_VERSION = rolling
                          OS_VENDOR_ARCH = Arch/i386
                       OS_VENDOR_VERSION = Arch/rolling
                  OS_VENDOR_VERSION_ARCH = Arch/rolling/i386
Configuration tree:
                         Linux-i386.conf : OK
                          GNU/Linux.conf : OK
                               i386.conf : missing/empty
                            rolling.conf : missing/empty
                       rolling/i386.conf : missing/empty
                               Arch.conf : missing/empty
                          Arch/i386.conf : missing/empty
                       Arch/rolling.conf : missing/empty
                  Arch/rolling/i386.conf : missing/empty
                               site.conf : OK
                              local.conf : OK
Backup with RBME
                             RBME_BACKUP =
                           RBME_HOSTNAME = d2
                  BACKUP_INTEGRITY_CHECK =
                         BACKUP_MOUNTCMD =
                     BACKUP_ONLY_EXCLUDE = no
                     BACKUP_ONLY_INCLUDE = no
                          BACKUP_OPTIONS =
      BACKUP_RESTORE_MOVE_AWAY_DIRECTORY = /root/rear/var/lib/rear/moved_away_after_backup_restore/
          BACKUP_RESTORE_MOVE_AWAY_FILES =
                    BACKUP_RSYNC_OPTIONS = --sparse --archive --hard-links --numeric-ids --stats
                  BACKUP_SELINUX_DISABLE = 1
                             BACKUP_TYPE =
                        BACKUP_UMOUNTCMD =
                              BACKUP_URL =
Output to USB
                              USB_DEVICE = /dev/disk/by-label/REAR-000
                   USB_DEVICE_FILESYSTEM = ext4
            USB_DEVICE_FILESYSTEM_PARAMS = -b 4096 -E stride=8,stripe-width=256 -O sparse_super,^has_journal
        USB_DEVICE_FILESYSTEM_PERCENTAGE = 100
                 USB_DEVICE_PARTED_LABEL = gpt
                               USB_FILES =
          USB_PARTITION_ALIGN_BLOCK_SIZE = 4
                    USB_RETAIN_BACKUP_NR = 2
                              USB_SUFFIX =
                      USB_UEFI_PART_SIZE = 200
                           RESULT_MAILTO =

/root/rear/usr/share/rear/lib/validated/Arch/rolling/i386.txt
Your system is not yet validated. Please carefully check all functions
and create a validation record with 'rear validate'. This will help others
to know about the validation status of Relax-and-Recover on this system.
Saving /root/rear/var/log/rear/rear-d2.log.lockless as /root/rear/var/log/rear/rear-d2.log

ProBackup-nl commented at 2017-03-14 14:29:

Does this -d -D debug logging snippet means that /finalize/Linux-i386/230_run_efibootmgr.sh gets executed?

++ [[ ! -d /root/rear/usr/share/rear/finalize/Linux-i386/230_run_efibootmgr.sh ]]
++ [[ -x /root/rear/usr/share/rear/finalize/Linux-i386/230_run_efibootmgr.sh ]]
++ echo /root/rear/usr/share/rear/finalize/Linux-i386/230_run_efibootmgr.sh

No, I don't think that finalize/Linux-i386/230_run_efibootmgr.sh gets sourced/executed here. It is a check whether the file is not a directory and is executable.

ProBackup-nl commented at 2017-03-14 14:49:

I don't see a 'finalize' stage running on mkrescue. Maybe 'finalize' only executes on mkbackup.

The stages I see at mkrescue are in order of occurence:

  1. init
  2. prep
  3. layout/save
  4. rescue
  5. build
  6. pack
  7. output

gdha commented at 2017-03-14 14:55:

@ProBackup-nl Use the -s option with the workflow to see which scripts will be executed in which order.

ProBackup-nl commented at 2017-03-14 15:02:

usr/share/rear/lib/recover-workflow.sh

    SourceStage "layout/prepare"
    SourceStage "layout/recreate"

    SourceStage "restore"

    SourceStage "finalize"
    SourceStage "wrapup"
}

Aha, finalize is only used for the recover command, not for mkrescue. Now I think I know that I can't move that file, and need to duplicate most of it's code for creating an EFISTUB booted recovery medium.

It wasn't clear to me, that there is no finalize phase available in mkrescue.

jsmeix commented at 2017-03-14 15:03:

For comparison on my SLES12 SP2 system (with BIOS):

# usr/sbin/rear -s recover | grep finalize
Source layout/prepare/default/550_finalize_script.sh
Source finalize/default/010_prepare_checks.sh
Source finalize/default/100_populate_dev.sh
Source finalize/GNU/Linux/150_migrate_disk_devices_layout.sh
Source finalize/GNU/Linux/150_migrate_lun_wwid.sh
Source finalize/GNU/Linux/150_migrate_uuid_tags.sh
Source finalize/GNU/Linux/160_rename_diskbyid.sh
Source finalize/SUSE_LINUX/i386/170_rebuild_initramfs.sh
Source finalize/Linux-i386/210_install_grub.sh
Source finalize/Linux-i386/220_install_elilo.sh
Source finalize/Linux-i386/220_install_grub2.sh
Source finalize/Linux-i386/230_run_efibootmgr.sh
Source finalize/GNU/Linux/300_create_mac_mapping.sh
Source finalize/GNU/Linux/410_migrate_udev_rules.sh
Source finalize/GNU/Linux/420_migrate_network_configuration_files.sh
Source finalize/default/880_check_for_mount_by_id.sh
Source finalize/default/890_finish_checks.sh
Source finalize/default/900_remount_sync.sh

# usr/sbin/rear -s mkbackup | grep finalize
[no output]

# usr/sbin/rear -d -D mkrescue
Relax-and-Recover 2.00 / Git
Using log file: /root/rear/var/log/rear/rear-e205.log
...

# grep ' source ' var/log/rear/rear-e205.log
+ source /root/rear/usr/share/rear/conf/Linux-i386.conf
+ source /root/rear/usr/share/rear/conf/GNU/Linux.conf
+ source /root/rear/usr/share/rear/conf/SUSE_LINUX.conf
+ source /root/rear/etc/rear/local.conf
+ source /root/rear/usr/share/rear/init/default/010_set_drlm_env.sh
+ source /root/rear/usr/share/rear/init/default/030_update_recovery_system.sh
...
[many more scripts that get 'source'd]

ProBackup-nl commented at 2017-03-20 12:57:

efibootmgr is lacking support for OsRecovery#### and efibootmgr is lacking support for USB (WWID) devices yet, otherwise I could have added support for UEFI boot manager (for USB devices).

gdha commented at 2017-12-22 08:37:

@ProBackup-nl According your last comment is this PR obsolete, or does it need some rework?

ProBackup-nl commented at 2017-12-22 10:34:

@gdha Here I lost track. First it took me a week to create the changes, and afterwords another week (mostly fumbling with git to get the changes uploaded) to re-create and upload the changes a second time. I am passing the on this PR due to "lost interest".

gdha commented at 2017-12-29 11:32:

Based on the above comments we close this issue until the need re-arises.

[Export of Github issue for rear/rear.]