#2995 Issue closed: rear mkrescue fails due to unknown partition table on supposedly excluded device¶
Labels: support / question, no-issue-activity
danboid opened issue at 2023-05-25 15:57:¶
- ReaR version ("/usr/sbin/rear -V"):
2.7
- OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
Ubuntu 20.04.6 LTS
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.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
EXCLUDE_COMPONENTS=( "${EXCLUDE_COMPONENTS[@]}" "/dev/nvme0n1" "/dev/nvme1n1" "/dev/nvme0n1p1" "/dev/nvme0n1p9" "/dev/nvme1n1p1" "/dev/nvme1n1p9" )
#ONLY_INCLUDE_VG=( "vg1" )
- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
Dell Poweredge
- System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
amd64
- Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
BIOS
- Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
local disks
- 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 squashfs 63.3M /snap/core
/dev/loop1 /dev/loop1 loop squashfs 55.6M /snap/core
/dev/loop2 /dev/loop2 loop squashfs 55.7M /snap/core
/dev/loop3 /dev/loop3 loop squashfs 91.9M /snap/lxd/
/dev/loop4 /dev/loop4 loop squashfs 63.5M /snap/core
/dev/loop5 /dev/loop5 loop squashfs 91.8M /snap/lxd/
/dev/loop6 /dev/loop6 loop squashfs 53.2M /snap/snap
/dev/loop7 /dev/loop7 loop squashfs 53.2M /snap/snap
/dev/sda /dev/sda usb disk iso9660 Ubuntu-Server 20.04.2 LTS amd64 15G
|-/dev/sda1 /dev/sda1 /dev/sda part iso9660 Ubuntu-Server 20.04.2 LTS amd64 1.1G
|-/dev/sda2 /dev/sda2 /dev/sda part vfat 3.9M
`-/dev/sda3 /dev/sda3 /dev/sda part ext4 writable 13.8G
/dev/sdb /dev/sdb disk 931.5G
|-/dev/sdb1 /dev/sdb1 /dev/sdb part 1M
`-/dev/sdb2 /dev/sdb2 /dev/sdb part linux_raid ubuntu-server:0 931.5G
`-/dev/md0 /dev/md0 /dev/sdb2 raid10 LVM2_membe 1.8T
`-/dev/mapper/vg1-lv--0
/dev/dm-0 /dev/md0 lvm ext4 1.8T /
/dev/sdc /dev/sdc disk 931.5G
|-/dev/sdc1 /dev/sdc1 /dev/sdc part 1M
`-/dev/sdc2 /dev/sdc2 /dev/sdc part linux_raid ubuntu-server:0 931.5G
`-/dev/md0 /dev/md0 /dev/sdc2 raid10 LVM2_membe 1.8T
`-/dev/mapper/vg1-lv--0
/dev/dm-0 /dev/md0 lvm ext4 1.8T /
/dev/sdd /dev/sdd disk 931.5G
|-/dev/sdd1 /dev/sdd1 /dev/sdd part 1M
`-/dev/sdd2 /dev/sdd2 /dev/sdd part linux_raid ubuntu-server:0 931.5G
`-/dev/md0 /dev/md0 /dev/sdd2 raid10 LVM2_membe 1.8T
`-/dev/mapper/vg1-lv--0
/dev/dm-0 /dev/md0 lvm ext4 1.8T /
/dev/sde /dev/sde disk 931.5G
|-/dev/sde1 /dev/sde1 /dev/sde part 1M
`-/dev/sde2 /dev/sde2 /dev/sde part linux_raid ubuntu-server:0 931.5G
`-/dev/md0 /dev/md0 /dev/sde2 raid10 LVM2_membe 1.8T
`-/dev/mapper/vg1-lv--0
/dev/dm-0 /dev/md0 lvm ext4 1.8T /
/dev/sdf /dev/sdf disk 1.8T
/dev/sdg /dev/sdg disk 1.8T
/dev/sdh /dev/sdh disk 1.8T
/dev/sdi /dev/sdi usb disk 931.5G
|-/dev/sdi1 /dev/sdi1 /dev/sdi part 8M
|-/dev/sdi2 /dev/sdi2 /dev/sdi part vfat REAR-EFI 1G
`-/dev/sdi3 /dev/sdi3 /dev/sdi part ext3 REAR-000 930.5G
/dev/sr0 /dev/sr0 sata rom 1024M
/dev/nvme0n1 /dev/nvme0n1 nvme disk 931.5G
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part zfs_member lxdpool 931.5G
`-/dev/nvme0n1p9 /dev/nvme0n1p9 /dev/nvme0n1 nvme part 8M
/dev/nvme1n1 /dev/nvme1n1 nvme disk 931.5G
|-/dev/nvme1n1p1 /dev/nvme1n1p1 /dev/nvme1n1 nvme part zfs_member lxdpool 931.5G
`-/dev/nvme1n1p9 /dev/nvme1n1p9 /dev/nvme1n1 nvme part 8M
- Description of the issue (ideally so that others can reproduce it):
rear mkrescue is failing:
# rear -v mkrescue
Relax-and-Recover 2.7 / Git
Running rear mkrescue (PID 376711 date 2023-05-25 16:47:26)
Using log file: /var/log/rear/rear-dionysus.log
Running workflow mkrescue on the normal/original system
Using autodetected kernel '/boot/vmlinuz-5.4.0-149-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
ERROR: Unsupported partition table 'unknown' (must be one of 'msdos' 'gpt' 'gpt_sync_mbr' 'dasd')
Some latest log messages since the last called script 200_partition_layout.sh:
2023-05-25 16:47:32.465629559 Saving disks and their partitions
Some messages from /var/tmp/rear.8wI1FCmFKs5AaWk/tmp/rear.mkrescue.stdout_stderr since the last called script 200_partition_layout.sh:
blockdev: cannot open /dev/nvme0n1p9: No such file or directory
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
Use debug mode '-d' for some debug messages or debugscript mode '-D' for full debug messages with 'set -x' output
Error exit of rear mkrescue (PID 376711) and its descendant processes
Exiting subshell 1 (where the actual error happened)
Aborting due to an error, check /var/log/rear/rear-dionysus.log for details
Exiting rear mkrescue (PID 376711) and its descendant processes ...
Running exit tasks
Terminated
I know that REAR cannot backup or restore ZFS partitions. That's fine, I
use syncoid to backup and restore ZFS but here it seems rear mkrescue
is failing because /dev/nvme0n1p9 (and /dev/nvme1n1p9 ) have an
unknown partition table. It is just an empty placeholder partition that
I definitely don't want to backup because I couldn't anyway.
My understanding of rear is that EXCLUDE_COMPONENTS is used to exclude
certain devices from being backed up but nothing that I've tried so far
stops mkrescue from analysing the nmve devices, which are formatted
with ZFS, and then aborting mkrescue because of the unknown
partitions.
- Workaround, if any:
Under rear 2.5 I was successful in getting this machine to backup (and
hence mkrescue worked too) by using ONLY_INCLUDE_VG=( "vg1" ) in my
/etc/rear/local.conf because it uses LVM but that doesn't work any
more under 2.7. rear 2.5 also didn't produce bootable USB drives under
Ubuntu 20.04.
Thanks
jsmeix commented at 2023-05-26 06:41:¶
@danboid
in general for an analysis we need a full debug ReaR log file,
see
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files)
Caution with possible secrets in a full debug log file:
When 'rear' is run via '-D' in debugscript mode
it logs executed commands via the bash command 'set -x'
that print commands and their arguments as they are executed
so in particular when arguments contain secret values
(e.g. something like a password or whatever else)
such secret values may appear in the log file.
Also secrets may be stored in some other files
like /var/lib/rear/layout/disklayout.conf
or /var/lib/rear/layout/diskrestore.sh
cf. [password=<password>] in the section
"Disk layout file syntax" in
doc/user-guide/06-layout-configuration.adoc
online at
https://github.com/rear/rear/blob/rear-2.7/doc/user-guide/06-layout-configuration.adoc
So before you attach your full debug log file and other files
here (GitHub is a public accessible place) inspect your files
and verify that they do not accidentally cointain secrets.
danboid commented at 2023-05-26 10:25:¶
Debug log attached
jsmeix commented at 2023-05-26 12:39:¶
@danboid
as far as I see in your
https://github.com/rear/rear/files/11574203/rear-dionysus.log
# grep -A10000 ' source /usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh' rear-dionysus.log | egrep 'extract_partitions|disk_label='
++ extract_partitions /dev/nvme0n1
++ disk_label=gpt
++ extract_partitions /dev/nvme1n1
++ disk_label=gpt
++ extract_partitions /dev/sda
++ disk_label=unknown
the problematic disk where the
ERROR: Unsupported partition table 'unknown' ...
happens is
/dev/sda
which is according to your 'lsblk' output
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sda /dev/sda usb disk iso9660 Ubuntu-Server 20.04.2 LTS amd64 15G
|-/dev/sda1 /dev/sda1 /dev/sda part iso9660 Ubuntu-Server 20.04.2 LTS amd64 1.1G
|-/dev/sda2 /dev/sda2 /dev/sda part vfat 3.9M
`-/dev/sda3 /dev/sda3 /dev/sda part ext4 writable 13.8G
a USB device.
So I wonder if you could (at least as a workaround for now)
disconnect this USB device while you run "rear mkrescue"?
jsmeix commented at 2023-05-26 12:41:¶
By the way:
I did right now
https://github.com/rear/rear/commit/2aaa1967710314c7bc12ccacac67dcf76b10b95a
to make that "Unsupported partition table" error message meaningful
in particular for systems with more than a single disk ;-)
danboid commented at 2023-05-26 13:12:¶
I can't physically remove that disk now but if it is that causing the error then I would've expected changing to:
EXCLUDE_COMPONENTS=( "${EXCLUDE_COMPONENTS[@]}" "/dev/nvme0n1" "/dev/nvme1n1" "/dev/nvme0n1p1" "/dev/nvme0n1p9" "/dev/nvme1n1p1" "/dev/nvme1n1p9" "/dev/sda" )
Should fix my problem but I still get:
rear -v mkrescue
Relax-and-Recover 2.7 / Git
Running rear mkrescue (PID 1247546 date 2023-05-26 14:09:05)
Using log file: /var/log/rear/rear-dionysus.log
Running workflow mkrescue on the normal/original system
Using autodetected kernel '/boot/vmlinuz-5.4.0-149-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
ERROR: Unsupported partition table 'unknown' (must be one of 'msdos' 'gpt' 'gpt_sync_mbr' 'dasd')
Some latest log messages since the last called script 200_partition_layout.sh:
2023-05-26 14:09:14.858195493 Saving disks and their partitions
Some messages from /var/tmp/rear.f7X59f7QErCnxcV/tmp/rear.mkrescue.stdout_stderr since the last called script 200_partition_layout.sh:
blockdev: cannot open /dev/nvme0n1p9: No such file or directory
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
Use debug mode '-d' for some debug messages or debugscript mode '-D' for full debug messages with 'set -x' output
Error exit of rear mkrescue (PID 1247546) and its descendant processes
Exiting subshell 1 (where the actual error happened)
Aborting due to an error, check /var/log/rear/rear-dionysus.log for details
Exiting rear mkrescue (PID 1247546) and its descendant processes ...
Running exit tasks
Terminated
danboid commented at 2023-05-26 13:19:¶
My amateur, not knowing rear well guess is that the $device array as fed into 200_partition_layout.sh doesn't exclude the devices listed in the $EXCLUDE_COMPONENTS array so it tries to fetch the label/ partition type of ALL partitions regardless.
jsmeix commented at 2023-05-26 13:29:¶
Yes, this is how it currently behaves.
The exclusion happens afterwards.
Basically for normal disks
layout/save/GNU/Linux/200_partition_layout.sh
does
for disk in /sys/block/* ; do
...
extract_partitions "$devname"
...
done
jsmeix commented at 2023-05-26 13:35:¶
Remember my
https://github.com/rear/rear/issues/2772#issuecomment-1069119836
with its link to my
https://github.com/rear/rear/issues/2229#issuecomment-531474858
danboid commented at 2023-05-26 15:07:¶
I removed the Ubuntu install USB disk, rebooted and that did fix
mkrescue and mkbackup as rear is backing it up now but why did
adding "/dev/sda" to the $EXCLUDE_COMPONENTS array not fix that error
if that was the disk causing trouble?
jsmeix commented at 2023-05-31 12:05:¶
As far as I see
adding "/dev/sda" to any EXCLUDE variable
cannot help here because of
https://github.com/rear/rear/issues/2995#issuecomment-1564384575
and
https://github.com/rear/rear/issues/2995#issuecomment-1564397149
pcahyna commented at 2023-06-20 13:23:¶
I downloaded the "Ubuntu-Server 20.04.2 LTS amd64" image and set it up as a disk (should be equivalent to dd-ing it to a empty disk):
losetup -P -f ~pcahyna/Downloads/ubuntu-20.04-beta-live-server-amd64.iso
and I examined how it behaves:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 918M 0 loop
├─loop0p1 259:0 0 918M 0 part
└─loop0p2 259:1 0 3.9M 0 part
# file -s /dev/loop0
/dev/loop0: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Ubuntu-Server 20.04 LTS amd64' (bootable)
# parted -m -s /dev/loop0 print
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
BYT;
/dev/loop0:963MB:loopback:512:512:unknown:Loopback device:;
# fdisk -l /dev/loop0
Disk /dev/loop0: 918 MiB, 962592768 bytes, 1880064 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x53c95e79
Device Boot Start End Sectors Size Id Type
/dev/loop0p1 * 0 1880063 1880064 918M 0 Empty
/dev/loop0p2 20464 28463 8000 3.9M ef EFI (FAT-12/16/32)
so, the root problem seems to be that parted does not recognize the partition table that is recognized both by the kernel and fdisk.
danboid commented at 2023-06-22 19:27:¶
Thanks for explaining the root of this error. I had no intention of
backing up that disk/iso but I was unable to get rear to exclude
(examining) the disk. I had to physically remove the disk to get
mkrecover to work and I don't think that should've been necessary.
I opened a separate ticket regarding the "exclude from backup" section of the docs, which I regard as a key and lacking section of the docs so I will eventually read the source and document it if no-one else does it before me.
https://github.com/rear/rear/issues/2997
github-actions commented at 2023-08-22 02:01:¶
Stale issue message
[Export of Github issue for rear/rear.]