#2888 Issue `closed`: Recovery environment not booting¶

Labels: support / question, fixed / solved / done

ZENAdmin-Ops opened issue at 2022-11-13 01:16:¶

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
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): Ubuntu 22.04
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=USB
BACKUP=NETFS
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
BACKUP_URL=usb:///dev/disk/by-label/REAR-002
USB_UEFI_PART_SIZE="1000"
USB_RETAIN_BACKUP_NR=10

Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): Hyper-V
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): Local USB
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
NAME        KNAME       PKNAME   TRAN TYPE FSTYPE  LABEL      SIZE MOUNTPOINT
/dev/loop0  /dev/loop0                loop squashf              4K /snap/bare/5
/dev/loop1  /dev/loop1                loop squashf           63.2M /snap/core20/
/dev/loop2  /dev/loop2                loop squashf           63.2M /snap/core20/
/dev/loop3  /dev/loop3                loop squashf          238.5M /snap/firefox
/dev/loop4  /dev/loop4                loop squashf          203.7M /snap/firefox
/dev/loop5  /dev/loop5                loop squashf          346.3M /snap/gnome-3
/dev/loop6  /dev/loop6                loop squashf          346.3M /snap/gnome-3
/dev/loop7  /dev/loop7                loop squashf           81.3M /snap/gtk-com
/dev/loop8  /dev/loop8                loop squashf           91.7M /snap/gtk-com
/dev/loop9  /dev/loop9                loop squashf           37.1M /snap/hunspel
/dev/loop10 /dev/loop10               loop squashf           45.9M /snap/snap-st
/dev/loop11 /dev/loop11               loop squashf           45.9M /snap/snap-st
/dev/loop12 /dev/loop12               loop squashf             48M /snap/snapd/1
/dev/loop13 /dev/loop13               loop squashf             48M /snap/snapd/1
/dev/loop14 /dev/loop14               loop squashf            284K /snap/snapd-d
/dev/loop15 /dev/loop15               loop squashf            284K /snap/snapd-d
/dev/sda    /dev/sda                  disk                    3.6T 
|-/dev/sda1 /dev/sda1   /dev/sda      part vfat              1000M 
`-/dev/sda2 /dev/sda2   /dev/sda      part ext4    REAR-002   3.6T 
/dev/sdb    /dev/sdb                  disk                    3.6T 
|-/dev/sdb1 /dev/sdb1   /dev/sdb      part vfat    REAR-EFI  1000M 
`-/dev/sdb2 /dev/sdb2   /dev/sdb      part ext3    REAR-000   3.6T /media/zen/RE
/dev/sdc    /dev/sdc                  disk                    127G 
|-/dev/sdc1 /dev/sdc1   /dev/sdc      part vfat               512M /boot/efi
`-/dev/sdc2 /dev/sdc2   /dev/sdc      part ext4                40G /
/dev/sr0    /dev/sr0                  rom                    1024M

Description of the issue (ideally so that others can reproduce it):
Recovery environment is not booting.

I'm wondering if the issue is due to the fact that I have two USB devices connected. But of course they do have different labels

Workaround, if any:
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear-Ubuntu-DR6.log
To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

```
verbatim content
```

ZENAdmin-Ops commented at 2022-11-13 01:49:¶

My hunch about this was right.

mkrescue was acting on the other USB disk that was attached

So, the work-around (and possibly the solution) is to only have one USB disk attached when performing mkrescue.

Somehow the label is being ignored.

jsmeix commented at 2022-11-14 12:57:¶

@ZENAdmin-Ops

your ReaR config is somewhat inconsistent because
when you use 'REAR-002' instead of the default 'REAR-000' in

BACKUP_URL=usb:///dev/disk/by-label/REAR-002

you must also specify the matching

USB_DEVICE_FILESYSTEM_LABEL='REAR-002'

in your etc/rear/local.conf file.
Otherwise scripts that use USB_DEVICE_FILESYSTEM_LABEL
will use the value from usr/share/rear/conf/default.conf
which results in your
https://github.com/rear/rear/files/9996315/rear-Ubuntu-DR6.log

... Processing filesystem 'ext3' on '/dev/sdc2' mounted at '/media/zen/REAR-000'
...
... Automatically excluding filesystem /media/zen/REAR-000.

But those two messages do not explain why
your 'REAR-002' recovery medium fails to boot.

What exactly do you mean with
"Recovery environment is not booting" ?

What exactly fails when booting your 'REAR-002' USB disk?
What exact (error) messages do you see on your screen?

In general I recommend to be extra careful with
using ReaR USB disks during "rear recover".

In particular don't have USB disks connected
that you do not actually need during "rear recover".

Or more in general don't have any disk connected
that you do not actually need during "rear recover".

ZENAdmin-Ops commented at 2022-11-14 23:23:¶

What exactly fails when booting your 'REAR-002' USB disk?

Boots into GRUB. Rather into Rear.

What exact (error) messages do you see on your screen?

No error messages.

But it was apparent that mkrescue was updating the other USB disk.

I will try adding the statement below into local.conf
USB_DEVICE_FILESYSTEM_LABEL='REAR-002'

Thanks

[Export of Github issue for rear/rear.]