#2712 Issue closed: Restore boots to prompt instead of coming up with menu

Labels: enhancement, support / question, needs sponsorship

exedor opened issue at 2021-11-15 23:55:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    2.6 / 2020-06-17

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    Fedora 34

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=iso:///backup
OUTPUT_URL=null
ISO_DIR=/home/sim/release-1-9-43/devel/install/images/
ISO_MAX_SIZE=4400

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    PC

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86_64

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    SSD

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT"):

/dev/sda                             8:0    0 74.5G  0 disk
|-/dev/sda1                          8:1    0  600M  0 part /boot/efi
|-/dev/sda2                          8:2    0    1G  0 part /boot
`-/dev/sda3                          8:3    0 72.9G  0 part
  `-/dev/mapper/fedora_fedora-root 253:0    0   15G  0 lvm  /
/dev/sdb                             8:16   1 14.4G  0 disk
`-/dev/sdb1                          8:17   1 14.4G  0 part
/dev/zram0                         252:0    0  3.7G  0 disk [SWAP]

  • Description of the issue (ideally so that others can reproduce it):
    ISO image is created. I write it a USB stick with dd if=<image_file> of=/dev/sdb
    I need these ISO images stored and shared via cloud storage so writing directly to USB doesn't help,
    in case anyone was wondering. The image gets written to the USB drive and the USB drive is bootable,
    but it just boots to a prompt. I can login as root without a password and then manually start a restore
    but I've always seen a menu come up that shows the backups and the option for automated
    (well sort of) restore. I'm wondering what I'm doing or have done that is causing this behavior.

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

rear-fedora.log

jsmeix commented at 2021-11-17 12:23:

@exedor
I think in general it does not work
(or when something works it is more by luck)
to plain write an 'OUTPUT=ISO' image with 'dd' onto a disk,
see https://github.com/rear/rear/issues/2210
and https://github.com/rear/rear/issues/2668
in the latter see in particular
https://github.com/rear/rear/issues/2668#issuecomment-899985890

Alternatively you may have a look at the OUTPUT=RAWDISK method,
see usr/share/rear/conf/default.conf and
https://github.com/rear/rear/blob/master/doc/user-guide/13-tcg-opal-support.adoc

Furthermore when you use UEFI you may need something like

ISO_MKISOFS_BIN=/usr/bin/ebiso

i.e. specify the right tool that makes an UEFI bootable ISO image,
see usr/share/rear/conf/default.conf and
https://github.com/rear/rear/blob/master/usr/share/rear/conf/examples/SLE11-SLE12-SAP-HANA-UEFI-example.conf

exedor commented at 2021-12-02 05:43:

Well I get identical behavior when using the UEFI backup. If I backup direct to USB and then boot the USB, the same thing happens. The system being used to test restore, boots to a login prompt. I can enter root as the username and then I get a prompt telling me I can run rear recover. Sure, after I do that manually, it starts to look like it did before. All of this was automated with a nice menu previously. What happened to that? I'm getting identical behavior between the USB boot and the ISO boot burnt to DVD.

github-actions commented at 2022-02-01 02:12:

Stale issue message

pcahyna commented at 2022-02-01 10:11:

I believe it depends on whether the rescue image uses SYSLINUX or GRUB as bootloader. The menu is a feature of SYSLINUX only. And UEFI boot uses GRUB. I would also like to have the UX more unified (although the UI will probably not be the exactly the same).

exedor commented at 2022-02-01 16:14:

Ahhhhh, that makes sense! Our use case is one in which I create the backups and a much less technical user does the restores on a very regular basis. I've already returned to the BIOS boot and OS install to overcome this, and other issues but that is extremely helpful. Thank you!!!! I agree, the UI should be unified. Perhaps at some point, I'll be able to give back to this project as much as I've given.

jsmeix commented at 2022-02-02 08:12:

@pcahyna
thank you for you analysis!

We have too many different boot methods for the ReaR recovery system
which should be unified and cleaned up, cf.
https://github.com/rear/rear/issues/764

The current state was provided by various contributors to ReaR over a long time
and we at ReaR upstream will likely not find the time to unify and clean up all that
at least not as far as I see in the foreseeable future, e.g. see
https://github.com/rear/rear/issues/2391

I remember that I had tested OUTPUT=USB with BIOS and GRUB2 as bootloader
and I had a menue there but there are still some enhancements needed there, cf.
https://github.com/rear/rear/issues/2666

I never tested OUTPUT=USB with UEFI - see also
https://github.com/rear/rear/issues/2648

This issue here is about OUTPUT=ISO with UEFI where the bootloader setup
of the ReaR recovery system is impemented separated and different
than for OUTPUT=USB.

Additionally ("tertium datur" - always - sigh!) we have the bootloader setup
of the ReaR recovery system in case of GRUB_RESCUE=y - see
https://github.com/rear/rear/issues/2545

pcahyna commented at 2022-02-09 22:33:

Of course the SYSLINUX menu is useful for a "less technical user", but the usefulness goes far beyond that. One is then able to select what entry should be the default in the menu when booting the rescue image via a variable like ISO_DEFAULT="automatic", which is very useful in an automated setting. And because of the boot method differences, this does not always work (there is no matching USB_DEFAULT, and ISO_DEFAULT works in SYSLINUX only, so not with UEFI or PowerPC OpenFirmware). Although the integration of this kind of boot parameter with the menu is an implementation choice, and arguably could be done even without the menu support, but that's how it is currently done.

@antonvoznia here's a ToDo for you: implement ISO_DEFAULT also for GRUB, and corresponding *_DEFAULT options for other boot methods (at least, USB). Perhaps via adding menu support to GRUB at the same time.

[Export of Github issue for rear/rear.]