#2713 Issue closed: Problems with 1TB SanDisk USB driver rear - v mkrescue¶
Labels: support / question, fixed / solved / done
epaiser opened issue at 2021-11-16 00:41:¶
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"):
Relax-and-Recover 2.6-git.4317.be8b6ed.master / 2021-04-21 -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
```
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
```
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
```
cat /etc/rear/site.conf
cat: /etc/rear/site.conf: No such file or directory
cat /etc/rear/local.conf
# 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
#
# ### 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
```
- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
guest or PowerVM LPAR):
Supermicro:
Product Name: SYS-7049A-T
Product Name: X11DAi-N
```
System Information
Manufacturer: Supermicro
Product Name: SYS-7049A-T
Version: 123456789
Serial Number: S280025X9715928
UUID: CFE28600-A1C1-11E9-8000-002590BC0F4E
Wake-up Type: Power Switch
SKU Number: 097A15D9
Family: SMC X11
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Supermicro
Product Name: X11DAi-N
Version: 1.10
Serial Number: WM197S000330
Asset Tag: WM197S000330
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Default string
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
```
-
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):
```
[ -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD"
EFI boot on HDD
BIOS Information
Vendor: American Megatrends Inc.
Version: 3.1
Release Date: 05/03/2019
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 32 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.14
```
-
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
NVMe 256GB -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT"):
```
lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
/dev/loop0 /dev/loop0 loop squashfs 4K /snap/bare/5
/dev/loop1 /dev/loop1 loop squashfs 61.9M /snap/core20/1169
/dev/loop2 /dev/loop2 loop squashfs 55.4M /snap/core18/2128
/dev/loop3 /dev/loop3 loop squashfs 219M /snap/gnome-3-34-1804/72
/dev/loop4 /dev/loop4 loop squashfs 162.9M /snap/gnome-3-28-1804/145
/dev/loop5 /dev/loop5 loop squashfs 65.1M /snap/gtk-common-themes/1515
/dev/loop6 /dev/loop6 loop squashfs 65.2M /snap/gtk-common-themes/1519
/dev/loop7 /dev/loop7 loop squashfs 548K /snap/gnome-logs/106
/dev/loop8 /dev/loop8 loop squashfs 2.5M /snap/gnome-calculator/884
/dev/loop9 /dev/loop9 loop squashfs 99.5M /snap/core/11798
/dev/loop10 /dev/loop10 loop squashfs 164.8M /snap/gnome-3-28-1804/161
/dev/loop11 /dev/loop11 loop squashfs 99.4M /snap/core/11993
/dev/loop12 /dev/loop12 loop squashfs 2.5M /snap/gnome-system-monitor/169
/dev/loop13 /dev/loop13 loop squashfs 704K /snap/gnome-characters/761
/dev/loop14 /dev/loop14 loop squashfs 116M /snap/cmake/955
/dev/loop15 /dev/loop15 loop squashfs 704K /snap/gnome-characters/726
/dev/loop16 /dev/loop16 loop squashfs 219M /snap/gnome-3-34-1804/66
/dev/loop17 /dev/loop17 loop squashfs 2.5M /snap/gnome-calculator/826
/dev/loop18 /dev/loop18 loop squashfs 241.4M /snap/gnome-3-38-2004/70
/dev/loop19 /dev/loop19 loop squashfs 2.5M /snap/gnome-system-monitor/163
/dev/loop20 /dev/loop20 loop squashfs 242.4M /snap/gnome-3-38-2004/76
/dev/loop21 /dev/loop21 loop squashfs 110.8M /snap/cmake/936
/dev/loop22 /dev/loop22 loop squashfs 55.5M /snap/core18/2246
/dev/loop23 /dev/loop23 loop squashfs 61.8M /snap/core20/1081
/dev/loop24 /dev/loop24 loop squashfs 548K /snap/gnome-logs/103
/dev/sda /dev/sda sata disk 931.5G
`-/dev/sda1 /dev/sda1 /dev/sda part ext4 931.5G /data1
/dev/sdb /dev/sdb sata disk 931.5G
`-/dev/sdb1 /dev/sdb1 /dev/sdb part ext4 931.5G /data2
/dev/sdc /dev/sdc usb disk 231G
|-/dev/sdc1 /dev/sdc1 /dev/sdc part vfat 512M
`-/dev/sdc2 /dev/sdc2 /dev/sdc part ext3 230.5G
/dev/sdd /dev/sdd usb disk 920.4G
|-/dev/sdd1 /dev/sdd1 /dev/sdd part vfat 512M
`-/dev/sdd2 /dev/sdd2 /dev/sdd part ext3 919.9G
/dev/nvme0n1 /dev/nvme0n1 nvme disk 232.9G
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part vfat 512M /boot/efi
`-/dev/nvme0n1p2 /dev/nvme0n1p2 /dev/nvme0n1 nvme part ext4 232.4G /
```
- Description of the issue (ideally so that others can reproduce
it):
When doing:
"rear format /dev/sdd", then "rear -v mkrescue", got:
```
Relax-and-Recover 2.6-git.4317.be8b6ed.master / 2021-04-21
Running rear mkrescue (PID 26879 date 2021-11-15 16:04:01)
Using log file: /var/log/rear/rear-Prisma.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-90-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Docker is running, skipping filesystems mounted below Docker Root Dir /var/lib/docker
Disabling component 'disk /dev/sdc' in /var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/sdc' in /var/lib/rear/layout/disklayout.conf
Using guessed bootloader 'EFI' (found in first bytes on /dev/nvme0n1)
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /var/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
Skipping 'docker0': not bound to any physical interface.
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
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 /var/log/rear/rear-Prisma.log into initramfs as '/tmp/rear-Prisma-partial-2021-11-15T16:04:09-08:00.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/5.4.0-90-generic (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Symlink '/lib/modules/5.4.0-90-generic/build' -> '/usr/src/linux-headers-5.4.0-90-generic' refers to a non-existing directory on the recovery system.
It will not be copied by default. You can include '/usr/src/linux-headers-5.4.0-90-generic' via the 'COPY_AS_IS' configuration variable.
Testing that the recovery system in /tmp/rear.ULGbHOPORxlGlVm/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (337413415 bytes) in 43 seconds
ERROR: /dev/disk/by-label/REAR-EFI is not block device. Use `rear format -- --efi <USB_device_file>' for correct format
Some latest log messages since the last called script 100_create_efiboot.sh:
2021-11-15 16:05:38.346834862 Including output/USB/Linux-i386/100_create_efiboot.sh
2021-11-15 16:05:38.351496120 Configuring device for EFI boot
Aborting due to an error, check /var/log/rear/rear-Prisma.log for details
Exiting rear mkrescue (PID 26879) and its descendant processes ...
Running exit tasks
Terminated
```
Then:
After doing:
"rear format -- --efi /dev/sdd ; rear -v mkrescue"
```
rear -v mkrescue /dev/sdd
Relax-and-Recover 2.6-git.4317.be8b6ed.master / 2021-04-21
Running rear mkrescue (PID 13589 date 2021-11-15 16:17:43)
Using log file: /var/log/rear/rear-Prisma.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-90-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Docker is running, skipping filesystems mounted below Docker Root Dir /var/lib/docker
Disabling component 'disk /dev/sdc' in /var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/sdc' in /var/lib/rear/layout/disklayout.conf
Disabling component 'disk /dev/sdd' in /var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/sdd' in /var/lib/rear/layout/disklayout.conf
Using guessed bootloader 'EFI' (found in first bytes on /dev/nvme0n1)
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /var/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
Skipping 'docker0': not bound to any physical interface.
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
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 /var/log/rear/rear-Prisma.log into initramfs as '/tmp/rear-Prisma-partial-2021-11-15T16:17:53-08:00.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/5.4.0-90-generic (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Symlink '/lib/modules/5.4.0-90-generic/build' -> '/usr/src/linux-headers-5.4.0-90-generic' refers to a non-existing directory on the recovery system.
It will not be copied by default. You can include '/usr/src/linux-headers-5.4.0-90-generic' via the 'COPY_AS_IS' configuration variable.
Testing that the recovery system in /tmp/rear.XZv6065iNpD2iAK/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (337423025 bytes) in 43 seconds
GRUB2 modules to load: ext2 fat part_gpt
Saved /var/log/rear/rear-Prisma.log as rear/Prisma/20211115.1617/rear-Prisma.log
ERROR:
====================
BUG in /usr/share/rear/output/USB/Linux-i386/850_make_USB_bootable.sh line 40:
'Filesystem for device '/dev/sdd2' could not be found'
--------------------
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /var/log/rear/rear-Prisma.log
preferably with full debug information via 'rear -D mkrescue'
====================
Some latest log messages since the last called script 850_make_USB_bootable.sh:
2021-11-15 16:19:29.772955493 Including output/USB/Linux-i386/850_make_USB_bootable.sh
Aborting due to an error, check /var/log/rear/rear-Prisma.log for details
Exiting rear mkrescue (PID 13589) and its descendant processes ...
Running exit tasks
Terminated
```
-
Workaround, if any:
None -
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
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
```
DEvil0000 commented at 2021-11-17 10:35:¶
I changed a lot for output=USB the last 1-2 month so the version from 21
Apr is a bit on the old side. Try using a newer master version please -
your issue may have been fixed.
For the older version the --efi in format is correct.
gdha commented at 2021-11-19 08:47:¶
@epaiser Try the deb package from http://download.opensuse.org/repositories/Archiving:/Backup:/Rear:/Snapshot/xUbuntu_18.04/amd64/ which was build this week. This contains the updated USB format code.
epaiser commented at 2021-11-29 17:42:¶
The latest version solve the problem I have.
But it didn't to work to save the system and restore to a different
machine with different hardware (Supermicro -> ASUS Motherboard).
I will investigate more.
Thank you anyway!!
On 11/17/2021 2:35 AM, A. Binzxxxxxx wrote:
I changed a lot for output=USB the last 1-2 month so the version from 21
Apr is a bit on the old side. Try using a newer master version please -
your issue may have been fixed.
For the older version the |--efi | in format is correct.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/2713#issuecomment-971447782, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AWQKS2N3STX4EAVCLZTCPCDUMOAQZANCNFSM5IC7ZCOA.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
--
Ernesto Paiser - Senior Controls Engineer
Sigray, Inc.
5750 Imhoff Dr, Concord, CA 94520
United States
***@***.*** ***@***.***>
+1-650-503-3410
--
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are
addressed. If you have received this email in error, please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee,
you should not disseminate, distribute or copy this email. Please
notify
the sender immediately by email if you have received this email by
mistake
and delete this email from your system. If you are not the intended
recipient, you are notified that disclosing, copying, distributing or
taking any action in reliance on the contents of this information is
strictly prohibited
gdha commented at 2021-12-23 08:37:¶
@epaiser Did you already try to add MODULES=( 'all_modules' ) in your
local.conf file? However, there is no guarantee this will have the
desired behavior on different HW.
jsmeix commented at 2022-01-03 09:27:¶
MODULES=( 'all_modules' ) is in default.conf since ReaR version 2.5
cf.
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
and @epaiser got the matching "rear mkrescue" message
Copying all kernel modules in /lib/modules/5.4.0-90-generic (MODULES contains 'all_modules')
so the recreating on different hardware failure has a different cause.
@epaiser
in general see in particular the section
"Fully compatible replacement hardware is needed" in
https://en.opensuse.org/SDB:Disaster_Recovery
E.g. I think it cannot "just work" to switch from a SATA disk to a NVMe
disk
because the kernel device name changes from /dev/sda to /dev/nvme0n1
but ReaR stores kernel device names in
var/lib/rear/layout/disklayout.conf
so one has to manually adapt that file and likely some other files
like
var/lib/rear/layout/disktodo.conf
var/lib/rear/layout/config/df.txt
var/lib/rear/layout/diskdeps.conf
to make "rear recover" work on replacement hardware with a NVMe disk
when "rear mkrescue" was run on original hardware with a SATA disk.
I don't know how far ReaR's MIGRATION_MODE helps in this case
because I never migrated from SATA to NVMe myself.
jsmeix commented at 2022-01-31 10:59:¶
I guess the issue is meanwhile sufficiently solved
where "sufficiently" could also mean it was found
that migration is not possible with reasonable effort
in this case.
[Export of Github issue for rear/rear.]