Intermittent errors when running mkrescue/mkbackup

[rlrichmo]

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 1.17.2 / Git
• OS version (cat /etc/rear/os.conf or lsb_release -a):
  OS_VENDOR=OS_VENDOR=OracleServer
  OS_VERSION=7
• rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://lxignite/var/opt/rear/"
ONLY_INCLUDE_VG=( vg00 )
BACKUP_PROG_EXCLUDE=( '/w01/*' )
EXCLUDE_MOUNTPOINTS=( /w01 )
AUTOEXCLUDE_AUTOFS=y
AUTOEXCLUDE_DISKS=y
AUTOEXCLUDE_MULTIPATH=y
AUTOEXCLUDE_PATH=( /media )

• Are you using legacy BIOS or UEFI boot?
  BIOS
• Brief description of the issue:
  We get the following error intermittently on on our servers running Oracle grid with ASM. The devices it is referring to in the logs are ASM disks with GPT partitions.

ERROR: BUG BUG BUG!  Could not determine size of disk sdn/sdn1, please file a bug.
=== Issue report ===
Please report this unexpected issue at: https://github.com/rear/rear/issues

• Work-around, if any:
  I have not found one.

Here is the log form mkbackup:

2017-08-02 10:07:06.122384172 No partitions found on /dev/sdo.
2017-08-02 10:07:06.198816935 No partitions found on /dev/sdp.
2017-08-02 10:07:06.274899006 No partitions found on /dev/sdq.
2017-08-02 10:07:06.352263549 No partitions found on /dev/sdr.
Error: /dev/sds: unrecognised disk label
2017-08-02 10:07:06.428313739 No partitions found on /dev/sds.
Warning: Unable to open /dev/sdt read-write (Read-only file system).  /dev/sdt has been opened read-only.
Error: /dev/sdt: unrecognised disk label
2017-08-02 10:07:06.506045613 No partitions found on /dev/sdt.
2017-08-02 10:07:06.584354475 No partitions found on /dev/sdu.
2017-08-02 10:07:06.662259028 No partitions found on /dev/sdv.
2017-08-02 10:07:06.739228143 No partitions found on /dev/sdw.
2017-08-02 10:07:06.818309102 No partitions found on /dev/sdx.
2017-08-02 10:07:06.901006837 No partitions found on /dev/sdy.
2017-08-02 10:07:06.984680040 No partitions found on /dev/sdz.
2017-08-02 10:07:06.986247515 Running exit tasks.
2017-08-02 10:07:06.987673703 Exit task 'cleanup_build_area_and_end_program'
2017-08-02 10:07:06.989168508 Finished in 6 seconds
2017-08-02 10:07:06.990509363 You should also rm -Rf /tmp/rear.Tl0CpNXekZy5IAs
2017-08-02 10:07:06.991716935 End of program reached
2017-08-02 10:07:06.992856583 Exit task 'exec 8>&-'
2017-08-02 10:07:06.993897243 Exit task 'exec 7>&-'

[schlomo]

Can you please try again with our current release 2.2? There where some changes in this area that might solve your issue.

[gdha]

Indeed see also issue #1234

[gdha]

@rlrichmo Please try the latest release and return feedback.

[rlrichmo]

First, I want to thank everyone for the quick responses. I apologize for the slow reply on my part, as I am getting back to this issue. We are just getting started on implementing rear in our environment. In the mean time I have discovered that rear 2.00 is now available through the standard Oracle Linux repositories. I want to give version 2.00 a try first as we prefer to use packages supported by our Linux vendors. I upgraded rear on our Oracle Linux servers today and ran mkbackup without any issues. I will monitor these for the next few days and let you know if any errors should occur.

[gdha]

@rlrichmo And, does it work better with rear-2.00?

[rlrichmo]

Again, I apologize for the slow replies. I have not received any errors since upgrading to Rear version 2.00 on our Oracle Linux hosts. I am inclined to stay with version 2.00 since it is available in standard update channels for our Linux hosts and I did not see anything in the 2.1 and 2,2 release notes to compel me to upgrade further. Thanks to everyone who assisted in resolving this issue.

[jsmeix]

Because "no [further] news is good news" I assume that since
#1438 (comment)
it works with ReaR 2.0 so that I can close this issue.
If the same issue persists this issue report can be reopened but
new and different issues need new and separated issue reports.