#3101 Issue closed: ReaR 2.7 Ignores loop partition type Disks¶
Labels: support / question, fixed / solved / done
ramzcode opened issue at 2023-12-07 13:58:¶
-
ReaR version ("/usr/sbin/rear -V"):
2.7 -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
Amazon Linux 2 & Mostly for other Distros too -
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
AUTOEXCLUDE_DISKS=n added to include extra disks -
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
VM KVM / AWS EC2 -
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):
BIOS -
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,LABEL,SIZE,MOUNTPOINT"):
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/nvme1n1 /dev/nvme1n1 nvme disk ext4 8G /disk-a
/dev/nvme2n1 /dev/nvme2n1 nvme disk 23G
`-/dev/nvme2n1p1 /dev/nvme2n1p1 /dev/nvme2n1 nvme part ext4 23G /disk-b
/dev/nvme0n1 /dev/nvme0n1 nvme disk 8G
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part xfs / 8G /
`-/dev/nvme0n1p128 /dev/nvme0n1p128 /dev/nvme0n1 nvme part 1M
- Description of the issue (ideally so that others can reproduce it):
When a disk is formatted directly
with out a partition table like, GPT, MBR or DOS,
then the disk partition type is set to loop.
ex: mkfs.ext4 /dev/nvme1n1.
Due to the Type ReaR excludes the disk / partitions and FS.
- Workaround, if any:
Reformat the disk with Partition table like GPT
or remove the loop type from the EXCLUDED List
in the ReaR default conf file.
ramzcode commented at 2023-12-07 14:00:¶
jsmeix commented at 2023-12-11 12:44:¶
I can reproduce the "rear mkrescue" part with a USB disk /dev/sdb
# dd if=/dev/zero of=/dev/sdb count=64 bs=1M
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 1.94995 s, 34.4 MB/s
# lsblk -ipo KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
...
/dev/sdb usb disk 465.8G
# parted -s /dev/sdb unit GiB print
Error: /dev/sdb: unrecognised disk label
Model: TOSHIBA External USB 3.0 (scsi)
Disk /dev/sdb: 466GiB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
# mkfs.ext4 /dev/sdb
mke2fs 1.46.4 (18-Aug-2021)
Creating filesystem with 122096645 4k blocks and 30531584 inodes
Filesystem UUID: e1fe595f-0d9f-4d10-a152-45864d5ece07
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done
# lsblk -ipo KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
...
/dev/sdb usb disk ext4 465.8G
# parted -s /dev/sdb unit GiB print
Model: TOSHIBA External USB 3.0 (scsi)
Disk /dev/sdb: 466GiB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00GiB 466GiB 466GiB ext4
# mkdir /mountpoint_sdb
# mount -v /dev/sdb /mountpoint_sdb
mount: /dev/sdb mounted on /mountpoint_sdb.
# lsblk -ipo KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
...
/dev/sdb usb disk ext4 465.8G /mountpoint_sdb
# usr/sbin/rear -D mkrescue
...
# less var/lib/rear/layout/disklayout.conf
...
# Disk /dev/sdb
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sdb 500107859968 loop
# Partitions on /dev/sdb
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
# Filesystems (only ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs are supported).
# Format: fs <device> <mountpoint> <fstype> [uuid=<uuid>] [label=<label>] [<attributes>]
...
fs /dev/sdb /mountpoint_sdb ext4 uuid=e1fe595f-0d9f-4d10-a152-45864d5ece07 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16380 default_mount_options=user_xattr,acl options=rw,relatime
Excerpts from my 'rear -D mkrescue' debug log file:
+ source /root/rear.github.master/usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh
...
++ echo '# Disk /dev/sdb'
++ echo '# Format: disk <devname> <size(bytes)> <partition label type>'
++ echo 'disk /dev/sdb 500107859968 loop'
++ echo '# Partitions on /dev/sdb'
++ echo '# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>'
++ extract_partitions /dev/sdb
++ declare device=/dev/sdb
+++ get_sysfs_name /dev/sdb
+++ local name=sdb
+++ name=sdb
+++ [[ -e /sys/block/sdb ]]
+++ echo sdb
+++ return 0
++ declare sysfs_name=sdb
++ sysfs_paths_unfiltered=(/sys/block/$sysfs_name/$sysfs_name*)
++ declare -a sysfs_paths_unfiltered
++ sysfs_paths=()
++ declare -a sysfs_paths
++ declare path sysfs_path
++ [[ 0 -eq 0 ]]
++ [[ /dev/sdb = *\/\m\a\p\p\e\r\/* ]]
++ :
++ declare partition_name partition_prefix start_block
++ declare partition_nr size start
++ sort -un /var/tmp/rear.tvClaM8FOHZNYWr/tmp/partitions_unsorted
++ [[ ! -s /var/tmp/rear.tvClaM8FOHZNYWr/tmp/partitions ]]
++ Debug 'No partitions found on /dev/sdb.'
...
+ source /root/rear.github.master/usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh
...
2023-12-11 13:05:51.970513644 Processing filesystem 'ext4' on '/dev/sdb' mounted at '/mountpoint_sdb
...
Right now I cannot reproduce the "rear recover" part.
I need to set up a VM to do this.
I think all needed information is there in disklayout.conf
so that ReaR could recreate a disk with a filesystem
directly on the disk without a partiton table
BUT
currently I have no idea how difficult it may get in practice
to implement support for recreating disks without partitons
and filesystem directly on the disk.
ramzcode commented at 2023-12-21 08:51:¶
@jsmeix Sorry for the confusion, actually i missed to mount the FS, and due to this ReaR did not include it.
I gave a retry with mount point for a loop typed disk and with proper fstab entry and it did work. Also from your disklayout, it states that correctly. For sure recover should handle it without any problem and for me things worked perfectly.
Only one things is, the logs were either not clear to me or i did miss the point that a unmounted disk will be ignored by ReaR
Once again thank you.
jsmeix commented at 2023-12-21 10:55:¶
@ramzcode
thank you for your information what the root cause was
in your particular case and that things worked well
when that filesystem on the "raw" disk was mounted.
It helps so much to have feedback how things behave
for users "in real world out there" - and in particular
positive feedback when things work (reasonably) well.
In general regarding
what disk layout components to include or exclude
see my
https://github.com/rear/rear/issues/2229#issuecomment-531474858
Perhaps changing AUTOEXCLUDE_DISKS (by default set to 'y')
could help. But I did not test it.
In general see the "How to exclude something" part in default.conf
for ReaR 2.7 online starting at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L2974
which tells that disks that are not used by mounted filesystems
are automatically excluded via 'AUTOEXCLUDE_DISKS=y'.
The main script where things are automatically excluded
usr/share/rear/layout/save/default/320_autoexclude.sh
In your case (unmounted filesystem) there is a
DebugPrint "Automatically excluding disk $name (not used by any mounted filesystem)"
which you would see when you run ReaR in debug mode.
I recommend to run ReaR in debug '-d' mode
(personally I basically always use debugscript '-D' mode)
in particular during development of a disaster recovery procedure
while trying out this or that with ReaR to make things work.
[Export of Github issue for rear/rear.]