#2764 Issue closed: Unable to boot from USB image created¶
Labels: support / question, fixed / solved / done
SupraJames opened issue at 2022-03-07 15:41:¶
I'm using the latest git master and have followed the quickstart guide. The USB media is created, but I am not able to boot from it. I would like to this working and happy to try things out as directed.
- ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.6 / Git
- OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
Ubuntu 20.04.3 LTS
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OS_VENDOR=Ubuntu
OS_VERSION=20.04
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
Intel NUC running Ubuntu on the bare metal
- System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86
- Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Grub on UEFI
- Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Internal NVMe
- Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
jamesp@bonnie:~/rear/etc/rear$ 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 squashfs 55.5M /snap/core18/2253
/dev/loop1 /dev/loop1 loop squashfs 61.9M /snap/core20/1328
/dev/loop2 /dev/loop2 loop squashfs 55.5M /snap/core18/2284
/dev/loop3 /dev/loop3 loop squashfs 117.2M /snap/docker/1458
/dev/loop4 /dev/loop4 loop squashfs 8.5M /snap/distrobuilder/1125
/dev/loop5 /dev/loop5 loop squashfs 67.9M /snap/lxd/22526
/dev/loop6 /dev/loop6 loop squashfs 116.6M /snap/docker/1125
/dev/loop7 /dev/loop7 loop squashfs 61.9M /snap/core20/1361
/dev/loop8 /dev/loop8 loop squashfs 67.2M /snap/lxd/21835
/dev/loop9 /dev/loop9 loop squashfs 43.6M /snap/snapd/14978
/dev/sda /dev/sda usb disk 7.3G
|-/dev/sda1 /dev/sda1 /dev/sda part vfat REAR-EFI 512M
`-/dev/sda2 /dev/sda2 /dev/sda part ext3 REAR-000 6.8G
/dev/nvme0n1 /dev/nvme0n1 nvme disk 931.5G
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part vfat 512M /boot/efi
|-/dev/nvme0n1p2 /dev/nvme0n1p2 /dev/nvme0n1 nvme part swap 16G [SWAP]
`-/dev/nvme0n1p3 /dev/nvme0n1p3 /dev/nvme0n1 nvme part btrfs 915G /
- Description of the issue (ideally so that others can reproduce it):
I am unable to boot from my USB rescue media, the log of creating the media is below, and at boot the following happens
First
error: no such device: REAR-EFI.
Switching to GRUB2 boot menu...
Second - Grub 2.04 screen with Relax-and-Recover options for BIOS or
UEFI with and without secure boot)
No matter which of the first two optoins I select, I press enter and get
Loading Kernel /EFI/BOOT/kernel ...
error: file /EFI/BOOT/kernel not found.
Loading initial ramdisk /EFI/BOOT/initrd.cgz ...
error: you need to load the kernel first.
Press any key to continue...
- Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
USB media creation log:
jamesp@bonnie:~/rear$ sudo usr/sbin/rear -v mkrescue
Relax-and-Recover 2.6 / Git
Running rear mkrescue (PID 6206 date 2022-03-07 15:25:13)
Using log file: /home/jamesp/rear/var/log/rear/rear-bonnie.log
Running workflow mkrescue on the normal/original system
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-5.4.0-100-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /home/jamesp/rear/var/lib/rear/layout/disklayout.conf
Disabling component 'disk /dev/sda' in /home/jamesp/rear/var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/sda' in /home/jamesp/rear/var/lib/rear/layout/disklayout.conf
Using guessed bootloader 'EFI' for 'rear recover' (found in first bytes on /dev/nvme0n1)
Verifying that the entries in /home/jamesp/rear/var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /home/jamesp/rear/var/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
Skipping 'br-0d8a79ee7617': not bound to any physical interface.
Skipping 'br-39d00694ea74': not bound to any physical interface.
Skipping 'br-63581da79f65': not bound to any physical interface.
Skipping 'br-8480267a86dd': not bound to any physical interface.
Skipping 'br-947474637cd6': not bound to any physical interface.
Skipping 'br-9fc2cc230010': not bound to any physical interface.
Skipping 'br-c76e8d934a08': not bound to any physical interface.
Skipping 'docker0': not bound to any physical interface.
Skipping 'lxdbr0': not bound to any physical interface.
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/ubuntu/grubx64.efi' as UEFI bootloader file
Copying logfile /home/jamesp/rear/var/log/rear/rear-bonnie.log into initramfs as '/tmp/rear-bonnie-partial-2022-03-07T15:25:22+00:00.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/5.4.0-100-generic (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Testing that the recovery system in /var/tmp/rear.jL4qCqNhUTUcj9J/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (422444221 bytes) in 37 seconds
GRUB2 modules to load: btrfs fat part_gpt
Saved /home/jamesp/rear/var/log/rear/rear-bonnie.log as rear/bonnie/20220307.1525/rear-bonnie.log
Exiting rear mkrescue (PID 6206) and its descendant processes ...
Running exit tasks
gdha commented at 2022-03-07 15:49:¶
@SupraJames We are currently busy trying to fix the issue you're having - see PR #2763 or read historical information wriitten down in issue #2500.
SupraJames commented at 2022-03-07 16:10:¶
Thanks! Look forward to it working. I will try the RAWDISK method for now.
gdha commented at 2022-03-09 15:18:¶
@SupraJames You could try out http://download.opensuse.org/repositories/Archiving:/Backup:/Rear:/Snapshot/xUbuntu_20.04/amd64/rear_2.6-0git.4698.a16e840.master_amd64.deb and define:
GRUB2_SEARCH_ROOT_COMMAND="search --no-floppy --set=root --file /EFI/BOOT/BOOTX64.efi"
in the /etc/rear/local.conf file. If possible, provide us with some
feedback - positive or negative. Thanks.
SupraJames commented at 2022-03-10 18:13:¶
GRUB2_SEARCH_ROOT_COMMAND="search --no-floppy --set=root --file /EFI/BOOT/BOOTX64.efi"
I was able to try this just now - it does boot into the rescue shell so would seem to be successful! however the networking isn't quite right. which I suspect is an unrelated issue. Thanks!
jsmeix commented at 2022-03-11 07:42:¶
@SupraJames
I assume with "it does boot into the rescue shell" you mean the ReaR
recovery system
which is a normal (non graphical) Linux system where you can log in as
'root'
but not some kind of EFI or GRUB or systemd "rescue shell".
So I assume this specific issue is now solved, see also
https://github.com/rear/rear/issues/2500#issuecomment-1062951489
In general regarding networking in the ReaR recovery system
see what there is described related to "networking" in
usr/share/rear/conf/default.conf
and have a look what you may pick out of our examples in
usr/share/rear/conf/examples/
For example for my test VMs I use
USE_DHCLIENT="yes"
SSH_ROOT_PASSWORD="rear"
where USE_DHCLIENT="yes" lets the ReaR recovery system
startup with a new IP address that is different than the one of the
original system so I can keep both running without IP conflicts.
And SSH_ROOT_PASSWORD="rear" provides remote access
to the ReaR recovery system, cf. the section
"First steps with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
how to access the ReaR recovery system from remote via ssh
which is in particular useful for debugging issues that happen
inside the ReaR recovery system (i.e. during "rear recover").
[Export of Github issue for rear/rear.]