#1891 Issue closed: Unable to restore to PPC64LE system with ERROR: Mount command 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.../outputfs' failed.¶
Labels: enhancement, bug, cleanup, support / question,
fixed / solved / done
ccjung opened issue at 2018-08-06 14:39:¶
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.4 / Git
rpm -qa|grep rear rear23a-2.3.a-1.1.ppc64le
- OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
cat /etc/os-release NAME="SLES" VERSION="12-SP3" VERSION_ID="12.3" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP3" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp3"
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
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.
AUTOEXCLUDE_MULTIPATH=n
BOOT_OVER_SAN=y
REAR_INITRD_COMPRESSION=lzma
OUTPUT=ISO
ISO_MAX_SIZE=4000
BACKUP=NETFS
BACKUP_URL=iso:///iso_fs/REAR_BACKUP
ISO_DIR=/iso_fs/REAR_ISO
TMPDIR=/iso_fs/REAR_TEMP
OUTPUT_URL=null
BOOT_FROM_SAN=y
EXCLUDE_MOUNTPOINTS=( /iso_fs /opt/IBM/ITM /cv /opt/splunkforwarder /opt/teamquest /var/opt/BESClient /usr/sap /hana/data /hana/log /hana/shared /hana/backup /usr/sap/basis /usr/sap/srm /PA_backup )
EXCLUDE_COMPONENTS=( /dev/mapper/20017380034880209 /dev/mapper/2001738003488020a /dev/mapper/2001738003488020b /dev/mapper/2001738003488020c /dev/mapper/2001738003488020d /dev/mapper/2001738003488020e /dev/mapper/2001738003488020f /dev/mapper/20017380034880210 /dev/mapper/20017380034880211 /dev/mapper/20017380034880212 /dev/mapper/20017380034880213 /dev/mapper/20017380034880214 /dev/mapper/20017380034880215 /dev/mapper/20017380034880216 )
## SLES12-SP2
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" snapper chattr lsattr )
COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
for subvol in $(findmnt -n -r -t btrfs | cut -d ' ' -f 1 | grep -v '^/$' | egrep -v 'snapshots|crash') ; do
BACKUP_PROG_INCLUDE=( "${BACKUP_PROG_INCLUDE[@]}" "$subvol" )
done
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )
-
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): PowerVM LPAR
-
System architecture (x86 compatible or PPC64/PPC64LE or what excat ARM device):
PPC64LE -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
GRUB -
Description of the issue (ideally so that others can reproduce it):
I have attached the log.
eniesdbs101_restore.txt
Got the following errors when trying to restore:
RESCUE eniesdbd012:~ # rear -dDv recover Relax-and-Recover 2.4 / Git Using log file: /var/log/rear/rear-eniesdbd012.log Running workflow recover within the ReaR rescue/recovery system ERROR: Mount command 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.SgfzmzgGmm2nVkE/outputfs' failed.
Further down in the logs, we saw the following:
[ OK ] Started udev Kernel Device Manager.
Starting Initialize Rescue System...
Verifying md5sums of the files in the Relax-and-Recover rescue system
md5sum: ./dev/.SRC-Semaphore: No such file or directory
./dev/.SRC-Semaphore: FAILED open or read
[ OK ] Found device /dev/ttyS0.
[ OK ] Started udev Coldplug all Devices.
md5sum: WARNING: 1 listed file could not be read
Possibly corrupted Relax-and-Recover rescue system
Proceeding 'bona fide' nevertheless...
The strange thing is that we were able to restore to this same system and it worked before.
We wanted to add more customization in the Rescue system (original system) and restore the backup to the same system so we don't know why it doesn't work anymore.
Any help would be greatly appreciated. Thank you.
- Work-around, if any:
ccjung commented at 2018-08-06 14:51:¶
Attached another log file from another restore failure.
We have two systems (eniesdbd101 and eniesdbs101) and they both failed
to restore.
eniesdbd101_restore.txt
jsmeix commented at 2018-08-06 15:32:¶
@suseusr168
in your eniesdbd101_restore.txt there is (excerpt)
ERROR: Mount command 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.Ogqve80B29D23eG/outputfs' failed. Some latest log messages since the last called script 060_mount_NETFS_path.sh: 2018-08-06 14:37:05.506048036 Including verify/NETFS/default/060_mount_NETFS_path.sh 2018-08-06 14:37:05.506899805 Entering debugscripts mode via 'set -x'. mkdir: created directory '/tmp/rear.Ogqve80B29D23eG/outputfs' 2018-08-06 14:37:05.511294779 Added 'rmdir -v /tmp/rear.Ogqve80B29D23eG/outputfs >&2' as an exit task 2018-08-06 14:37:05.514107494 Mounting with 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.Ogqve80B29D23eG/outputfs' mount: you must specify the filesystem type
which indicates the root cause is likely a wrong config variable
value,
probably for the BACKUP_URL or OUTPUT_URL config variable
but I never used BACKUP_URL=iso://... myself so that
offhandedly I don't know the right way how to set up this.
The md5sum: ./dev/.SRC-Semaphore: No such file or directory can be
ignored
because it is false alarm.
I noticed already once such a md5sum failure for a strange file in
/dev/.
I need to exclude md5sum checking by default for files in /dev/
cf. "EXCLUDE_MD5SUM_VERIFICATION" in
usr/share/rear/conf/default.conf
how you could exclude such things manually for now.
jsmeix commented at 2018-08-06 15:56:¶
Meanwhile I think it is not a wrong config variable value
because in case of the iso URL scheme the mount_url function
in usr/share/rear/lib/global-functions.sh does
(iso)
if [[ "$WORKFLOW" = "recover" ]]; then
mount_cmd="mount /dev/disk/by-label/${ISO_VOLID} $mountpoint"
else
return 0
fi
;;
i.e. the mount command is basically hardcoded
so that it does not depend on config variable values.
Currently I don't know why mount complains in this case
because usually on can "just mount" an ISO image and the
filesystem type iso9660 is autodetected by the mount command
...
wait!
...
I think I remember something - see
https://github.com/rear/rear/issues/1202
where mounting an ISO in the recovery system failed for me
with mount: unknown filesystem type 'iso9660'.
The reason behind was missing kernel modules in the recovery system.
With MODULES=( 'all_modules' ) you get all kernel modules
into the recovery system to be on the safe side agains possibly
missing subtle kernel module dependencies, cf.
https://github.com/rear/rear/issues/1355
But on POWER but that may result a too big initrd
which could cause arbitrary other strange issues there, cf.
https://github.com/rear/rear/issues/1724
that was also a reason for the md5sum verification
https://github.com/rear/rear/issues/1859
dewagner1 commented at 2018-08-06 19:11:¶
The restore consistently fails on this lpar but using the same rear backup image on a different lpar works sometimes. I have been successful in restoring this image to another lpar but if I restart the install to that same lpar with the same image it will fail. I will attach files for each scenario. Each file contains a screen capture and the log file appended to the end. Another anomaly I've found is that the ethernet adapters are discovered differently during the various attempts at restoring.
Boot from the same rear backup image to the same destination lpar with different results
No network interface mapping is specified in /etc/rear/mappings/mac The original network interface eth0 2a:90:90:4a:af:03 is not available 1) eth2 52:41:08:ca:e4:03 ibmveth 2) eth3 52:41:08:ca:e4:04 ibmveth 3) Skip replacing eth0 2a:90:90:4a:af:03 Choose replacement for eth0 2a:90:90:4a:af:03
No network interface mapping is specified in /etc/rear/mappings/mac The original network interface eth0 2a:90:90:4a:af:03 is not available 1) eth0 52:41:08:ca:e4:03 ibmveth 2) eth1 52:41:08:ca:e4:04 ibmveth 3) Skip replacing eth0 2a:90:90:4a:af:03 Choose replacement for eth0 2a:90:90:4a:af:03
eniesdbd101_restore_fail1.txt
eniesdbd101_restore_success.txt
jsmeix commented at 2018-08-07 08:52:¶
@dewagner1
an initial question only out of curiosity:
Do you work together with @suseusr168 on the same system
or happens your issue on a different system?
Your eniesdbd101_restore_fail1.txt contains (excerpts)
Configuring Relax-and-Recover rescue system ... Running 67-check-by-label-cdrom.sh... ln: failed to create symbolic link '/dev/disk/by-label/RELAXRECOVER': No such file or directory Running 99-makedev.sh... . . . RESCUE eniesdbd012:~ # rear -dDv recover ... ERROR: Mount command 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.Ogqve80B29D23eG/outputfs' failed. . . . +++ mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.Ogqve80B29D23eG/outputfs mount: you must specify the filesystem type
while your eniesdbd101_restore_success.txt contains (excerpt)
Configuring Relax-and-Recover rescue system ... Running 67-check-by-label-cdrom.sh... Running 99-makedev.sh... . . . RESCUE eniesdbd012:~ # rear -dDv recover . . . +++ mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.fdnZ71LVDP4vDbk/outputfs mount: /dev/sr0 is write-protected, mounting read-only
I.e. when it fails the cause is during "Configuring Relax-and-Recover
rescue system" that
ln: failed to create symbolic link '/dev/disk/by-label/RELAXRECOVER': No such file or directory
but currently I don't know what the root cause for that is.
usr/share/rear/skel/default/etc/scripts/system-setup.d/67-check-by-label-cdrom.sh
contains
# On Ubuntu we have received many reports of a missing /dev/disk/by-label/RELAXRECOVER link
# and therefore during recovery the cdrom was not found automatically - details are in #326
# check if the symbolic link exist? Yes - just return
[[ -h /dev/disk/by-label/RELAXRECOVER ]] && return
if [[ -h /dev/cdrom ]] ; then
ln -s /dev/cdrom /dev/disk/by-label/RELAXRECOVER
elif [[ -b /dev/sr0 ]] ; then
ln -s /dev/sr0 /dev/disk/by-label/RELAXRECOVER
else
echo "Did not find a cdrom device. Recover might fail."
fi
which points to
https://github.com/rear/rear/issues/326
O.k. - seems to be just another "udev does not behave consistenty"
issue
which matches perfectly your observation that it "works sometimes".
For more debugging what exactly happens while 67-check-by-label-cdrom.sh
runs
you would need to run 67-check-by-label-cdrom.sh with set -x debugging
output.
To run the recovery system setup scripts one by one with set -x
debugging output
you must add in the recovery system boot menue the kernel command line
option debug.
Because you use GRUB2 to boot the recovery system the recovery system
GRUB2 boot menue seems to be in your eniesdbd101_restore_fail1.txt
GNU GRUB version 2.02
+----------------------------------------------------------------------------+
|*Relax-and-Recover |
| |
| |
+----------------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.
where you should be able to use e to edit the kernel command line
and append the option debug to it.
Then during "Configuring Relax-and-Recover rescue system" you need to
confirm running each recovery system startup script with the Enter key
and each script would show set -x debugging output.
The set -x debugging output of the 67-check-by-label-cdrom.sh
should help to find out what the reason is why
ln: failed to create symbolic link '/dev/disk/by-label/RELAXRECOVER': No such file or directory
From the 67-check-by-label-cdrom.sh code it seems the reason is
that there is neither a /dev/cdrom nor a /dev/sr0 device node.
Perhaps on POWER LPAR the device node where the ISO is attached to
could be something different (e.g. /dev/sr1 or whatever)?
If there is whatever device node where your ISO is attached to
on your particular POWER LPAR system, you can manually create
the missing symbolic link as a workaround before you run "rear recover".
If there is not any device node where your ISO is attached to
on your particular POWER LPAR system, I don't know what to do.
I am not a POWER user so that I don't know how a POWER LPAR system
behaves
but @schabrolles is a POWER user and I assume he can explain what goes
on
in this particular case here.
dewagner1 commented at 2018-08-07 09:06:¶
Yes, we work together. I am trying to clone two systems using rear. I
have not been able to restore the system that the problem was
originally
opened for. It fails every time. However, when I tried to restore the
second system, it worked. So I then tried the second system again and
it
failed.
Also, the ethernet adapters are numbered differentlly almost everytime
I
try a restore.
I will try to follow your instructions to gather more information.
Regards,
Dan Wagner
Senior Enterprise System Specialist
(717) 580-3844 Mobile
(717) 409-5858 Office
dwagner1@us.ibm.com
IBM Services
jsmeix commented at 2018-08-07 09:26:¶
I am not at all a networking expert but as far as I know
one cannot rely on the numbering of traditional network interface
names
(i.e. eth0 versus eth1) because the network interface numbers
depend on when each network interface hardware becomes available
so that eth0 matches those network interface hardware that became
first available to the kernel and eth1 is the next one and so on.
In the end it depends on hardware timing randomness, cf.
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
jsmeix commented at 2018-08-07 09:36:¶
Correction:
In
https://github.com/rear/rear/issues/1891#issuecomment-410984210
I wrote
From the 67-check-by-label-cdrom.sh code it seems the reason is that there is neither a /dev/cdrom nor a /dev/sr0 device node.
After a bit closer looking at the code in 67-check-by-label-cdrom.sh
I think now the reason is that there is no /dev/disk/by-label/
directory
where 'ln' could create the symbolic link
'/dev/disk/by-label/RELAXRECOVER'
because I can reproduce it this way:
# ln -s /etc/doesnotexist /tmp/doesnotexist/issue ln: failed to create symbolic link '/tmp/doesnotexist/issue': No such file or directory # ln -s /etc/doesnotexist /tmp/issue # file /tmp/issue /tmp/issue: broken symbolic link to /etc/doesnotexist
Currently I have no idea what the root cause is
when there is no /dev/disk/by-label/ directory.
I guess it is related to systemd/udev...
dewagner1 commented at 2018-08-07 09:40:¶
We have never seen this behavior using rear 2.1 on sles 11 sp4. The
ethernet adapters are always consistently eth0 and eth1.
[Ashburn] eniesdbd002:~ # rear -V
Relax-and-Recover 2.1-git.2325.fc6e788.master / 2017-07-16
[Ashburn] eniesdbd002:~ # uname -a
Linux eniesdbd002 3.0.101-108.18.1.14692.0.PTF-bigmem #1 SMP Wed Jan
31
01:12:29 UTC 2018 (8d683c9) ppc64 ppc64 ppc64 GNU/Linux
dewagner1 commented at 2018-08-07 09:41:¶
Would you still like me to run the recover with debug appended to the
kernel line in grub?
dewagner1 commented at 2018-08-07 09:54:¶
Here is a file with the screen capture and the log file appended to
the
end.
(See attached file: eniesdbs101 kernel debug.txt)
jsmeix commented at 2018-08-07 09:55:¶
@dewagner1
yes, please - we need the debug output to be able to move forward
from the current guesswork to what really happens on your system.
jsmeix commented at 2018-08-07 10:03:¶
@dewagner1
your attached file: eniesdbs101 kernel debug.txt appears as text in
https://github.com/rear/rear/issues/1891#issuecomment-411002148
and there it is only partially i.e. it is truncated (in particular there
is
no debug output of the 67-check-by-label-cdrom.sh script).
Can you attach it again as a file as you successfully did it for your
files
eniesdbd101_restore_fail1.txt and eniesdbd101_restore_success.txt
in your
https://github.com/rear/rear/issues/1891#issuecomment-410820702
jsmeix commented at 2018-08-07 10:10:¶
@dewagner1
regarding your
https://github.com/rear/rear/issues/1891#issuecomment-410997970
On SLES11 things worked in the traditional way.
Since SLES12 there is systemd that includes a newer udev.
dewagner1 commented at 2018-08-07 10:26:¶
jsmeix commented at 2018-08-07 10:54:¶
The eniesdbs101 kernel debug.txt contains
Press ENTER to run 67-check-by-label-cdrom.sh + source /etc/scripts/system-setup.d/67-check-by-label-cdrom.sh ++ [[ -h /dev/disk/by-label/RELAXRECOVER ]] ++ [[ -h /dev/cdrom ]] ++ ln -s /dev/cdrom /dev/disk/by-label/RELAXRECOVER ln: failed to create symbolic link '/dev/disk/by-label/RELAXRECOVER': No such file or directory Press ENTER to run 99-makedev.sh
which means there is a /dev/cdrom
but it does not show the reason behind why ln failed.
Currently I have no good idea what to do next.
Therefore now only some blind shot in the dark:
@dewagner1
when you are logged in as root in the recovery system
(i.e. without running "rear recover"), what do the commands
ls -l /dev/disk and ls -l /dev/disk/* show?
If they show nothing, wait one minute and retry.
dewagner1 commented at 2018-08-07 11:30:¶
RESCUE eniesdbd012:~ # ls -l /dev/disk total 0 drwxr-xr-x 2 root root 120 Aug 7 07:16 by-id drwxr-xr-x 2 root root 280 Aug 7 07:16 by-path RESCUE eniesdbd012:~ # ls -l /dev/disk/* /dev/disk/by-id: total 0 lrwxrwxrwx 1 root root 10 Aug 7 07:16 lvm-pv-uuid-eoHhwg-IEaj-xKuI-Q34I-ppZs-eUgd-4U8bqj -> ../../sdb2 lrwxrwxrwx 1 root root 10 Aug 7 07:16 'scsi-0IBM_2810XIV_host=eniesdbs101_OS-part2' -> ../../sdd2 lrwxrwxrwx 1 root root 10 Aug 7 07:16 scsi-1IBM_2810XIV_78033E700F2-part2 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Aug 7 07:16 scsi-20017380033e700f2-part1 -> ../../sdb1 /dev/disk/by-path: total 0 lrwxrwxrwx 1 root root 9 Aug 7 07:16 fc-0x5001738033e70140-lun-1 -> ../../sda lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70140-lun-1-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70140-lun-1-part2 -> ../../sda2 lrwxrwxrwx 1 root root 9 Aug 7 07:16 fc-0x5001738033e70142-lun-1 -> ../../sdc lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70142-lun-1-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70142-lun-1-part2 -> ../../sdc2 lrwxrwxrwx 1 root root 9 Aug 7 07:16 fc-0x5001738033e70152-lun-1 -> ../../sdd lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70152-lun-1-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70152-lun-1-part2 -> ../../sdd2 lrwxrwxrwx 1 root root 9 Aug 7 07:16 fc-0x5001738033e70170-lun-1 -> ../../sdb lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70170-lun-1-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Aug 7 07:16 fc-0x5001738033e70170-lun-1-part2 -> ../../sdb2
jsmeix commented at 2018-08-07 11:31:¶
From what I learned here I think the current recovery system setup
script 67-check-by-label-cdrom.sh needs to be overhauled,
see
https://github.com/rear/rear/issues/1893
jsmeix commented at 2018-08-07 11:39:¶
@dewagner1
your
https://github.com/rear/rear/issues/1891#issuecomment-411025148
proves what I suspected in
https://github.com/rear/rear/issues/1891#issuecomment-410996942
There is no /dev/disk/by-label/ directory.
And it even indicates that there is not any kernel device node for any
kind of
CDROM-like device (i.e. a device node where the ReaR ISO image is
attached to).
It seems there are only device nodes for normal disks 'sdX'
and normal disk partitions 'sdXN'.
@schabrolles
can you perhaps help here to find the root cause why
in the running ReaR recovery system there is no device node
where the ReaR ISO image is attached to.
I am puzzled because the ReaR recovery system was booted
from an attached ReaR ISO image (i.e. GRUB2 can access it)
but it seems from within the running ReaR recovery system
that same ReaR ISO image is no longer accessible.
For comparison how it looks on my KVM x86_64 system
from within the running ReaR recovery system see
https://github.com/rear/rear/issues/1893#issue-348280637
schabrolles commented at 2018-08-07 12:06:¶
@dewagner1, could you please run blkid after booting on the recovery
ReaR ISO.
dewagner1 commented at 2018-08-07 12:12:¶
RESCUE eniesdbd012:~ # blkid /dev/sr0: UUID="2018-08-06-10-20-24-00" LABEL="RELAXRECOVER" TYPE="iso9660" PTTYPE="dos" /dev/sda1: PARTUUID="000bb0f5-01" /dev/sda2: UUID="eoHhwg-IEaj-xKuI-Q34I-ppZs-eUgd-4U8bqj" TYPE="LVM2_member" PARTUUID="000bb0f5-02" /dev/sdb1: PARTUUID="000bb0f5-01" /dev/sdb2: UUID="eoHhwg-IEaj-xKuI-Q34I-ppZs-eUgd-4U8bqj" TYPE="LVM2_member" PARTUUID="000bb0f5-02" /dev/sdc1: PARTUUID="000bb0f5-01" /dev/sdc2: UUID="eoHhwg-IEaj-xKuI-Q34I-ppZs-eUgd-4U8bqj" TYPE="LVM2_member" PARTUUID="000bb0f5-02" /dev/sdd1: PARTUUID="000bb0f5-01" /dev/sdd2: UUID="eoHhwg-IEaj-xKuI-Q34I-ppZs-eUgd-4U8bqj" TYPE="LVM2_member" PARTUUID="000bb0f5-02"
schabrolles commented at 2018-08-07 12:34:¶
Ok thanks @dewagner1
As @jsmeix says the issue is mainly the fact that /dev/disk/by-label
directory does not exist on your system. So 67-check-by-label-cdrom.sh
failed to create the link.
If you need to restore your image, you can manually create the directory
/dev/disk/by-label and manually create the link
ln -s /dev/sr0 /dev/disk/by-label/RELAXRECOVER.
Then try a rear recover.
@jsmeix we should be able to make 67-check-by-label-cdrom.sh a bit
more dynamic by using blkid and be sure that /dev/disk/by-label
directory is created.
jsmeix commented at 2018-08-07 12:36:¶
@schabrolles
yes, that's the point of
https://github.com/rear/rear/issues/1893
jsmeix commented at 2018-08-07 12:39:¶
@schabrolles
do you have an idea why sometimes the /dev/disk/by-label directory is
not created
and sometimes it is created (when things work) - i.e. why things do not
behave
consistently (of course except the generic answer that since
systemd/udev
things do no longer behave consistently ;-)
dewagner1 commented at 2018-08-07 12:53:¶
If I create the /dev/disk/by-label directory and create the link
ln -s /dev/sr0 /dev/disk/by-label/RELAXRECOVER
the restore works.
jsmeix commented at 2018-08-07 12:58:¶
@dewagner1
thanks for confrmation how to make "rear recover" work in this case.
Now we can enhance that 67-check-by-label-cdrom.sh to make it work more
fail safe.
FYI:
You can automate such manual workaround hacks via
a PRE_RECOVERY_SCRIPT see usr/share/rear/conf/default.conf
for example in your case something like (untested):
PRE_RECOVERY_SCRIPT=( 'if ! test -h /dev/disk/by-label/RELAXRECOVER ; then mkdir -p /dev/disk/by-label ; ln -s /dev/sr0 /dev/disk/by-label/RELAXRECOVER ; fi' )
jsmeix commented at 2018-08-08 15:43:¶
The false alarm during the md5sum verification in
https://github.com/rear/rear/issues/1891#issue-347952166
should become fixed with
https://github.com/rear/rear/pull/1895
jsmeix commented at 2018-08-08 15:47:¶
The actual issue here (missing /dev/disk/by-label directory
and missing symlink /dev/disk/by-label/RELAXRECOVER
that points to a block device with filesystem label RELAXRECOVER)
should become fixed with
https://github.com/rear/rear/pull/1894
schabrolles commented at 2018-08-08 16:02:¶
@jsmeix, regarding
https://github.com/rear/rear/issues/1891#issuecomment-411041620
I've no idea why sometimes /dev/disk/by-label/ is not created ...
jsmeix commented at 2018-08-10 10:44:¶
With
https://github.com/rear/rear/pull/1894
merged
this issue should be sufficiently fixed.
"Sufficiently fixed" means that it cannot magically heal it when in the
recovery system
there is no block device with filesystem label $ISO_VOLID
(RELAXRECOVER)
but now "rear recover" shows a user dialog in this case where the user
can fix things
(e.g. attach a CDROM with the RELAXRECOVER labeled ReaR ISO).
But when there is a device with filesystem label $ISO_VOLID
(RELAXRECOVER)
things repair automatically when the /dev/disk/by-label/RELAXRECOVER
symlink
does not point to that device or when there is no such symlink.
See
https://github.com/rear/rear/pull/1894#issuecomment-411766357
for some examples how it behaves now.
ccjung commented at 2018-08-10 13:05:¶
Will this fix be in 2.4 or 2.5?
Do we continue to use your 23a version with the workaround or can you provide us the updated version with this fix?
Thanks.
jsmeix commented at 2018-08-10 14:25:¶
@suseusr168 and @dewagner1
If you like to try out our latest ReaR GitHub upstream code
that contaions all fixes and enhancements up to now
on your SLES12-SP3 PPC64LE system:
I provide the latest ReaR GitHub upstream code as of today
in my RPM package rear23a via the public openSUSE build service
wherefrom you could download the currently latest built RPM package
rear23a-2.3.a-2.1.ppc64le.rpm (the RPM release number 2.1 varies) from
http://download.opensuse.org/repositories/home:/jsmeix/SLE_12_SP3/ppc64le/
Regarding what latest fixes and enhancements
that rear23a RPM package actually contains
see at
https://build.opensuse.org/package/show/home:jsmeix/rear23a
my rear23a.changes file
https://build.opensuse.org/package/view_file/home:jsmeix/rear23a/rear23a.changes?expand=1
The openSUSE build service is not an official repository for RPM
packages
that are officially supported by SUSE for SUSE Linux Enterprise
products
so that in particular any RPM packages from
http://download.opensuse.org/repositories/home:/jsmeix/
are not officially supported by SUSE, cf.
https://build.opensuse.org/project/show/home:jsmeix
But this way you could right now try out what is intended to become
the officially provided rear23a package for SLEHA15 SLEHA12 and
SLEHA11
provided no further serious issues appear with it.
I would very much appreciate it if you try out and test and verify
whether or not
my currently latest updated rear23a RPM package actually works
for you on your particular system in your particular environment
and provide feedback to us here at ReaR upstream.
Many thanks in advance for testing it!
ccjung commented at 2018-08-11 01:09:¶
I was able to backup/restore using your rear23a-2.3.a-2.1.ppc64le rpm.
ps1dca0u:~ # cat /etc/os-release NAME="SLES" VERSION="12-SP3" VERSION_ID="12.3" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP3" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp3" ps1dca0u:~ # rpm -qa|grep rear rear23a-2.3.a-2.1.ppc64le
jsmeix commented at 2018-08-13 08:10:¶
@suseusr168
many thanks for your prompt testing and your explicit feedback.
Your Rear23a21.Restore.log looks fine to me.
ccjung commented at 2018-08-13 13:03:¶
I forgot to mention we still see the following at the beginning of the restore but it doesn't stop the restore process:
error: unrecognized number.
jsmeix commented at 2018-08-13 14:56:¶
@suseusr168
I had noticed the GRUB2 error: unrecognized number.
but I still cannot find out what its root cause is, cf.
https://github.com/rear/rear/issues/1883#issuecomment-409867612
I think as long as GRUB2 can load kernel and recovery system initrd
(i.e. as long as GRUB2 can boot the recovery system)
you could ignore that GRUB2 error: unrecognized number.
I think to find the root cause of the GRUB2
error: unrecognized number.
a GRUB2 expert who can imagine what each GRUB2 config setting results
would have to analyze the GRUB2 config of the recovery system
to (hopefully) find something that is not fully right therein.
But I am not a POWER user and I don't know how booting with GRUB2
happens
on PPC64LE PowerVM LPAR (in general I am not at all a bootloader
expert)
so that I cannot really help in this area.
[Export of Github issue for rear/rear.]