#2227 Issue closed
: ERROR: No filesystem mounted on '/mnt/local'. Stopping¶
Labels: support / question
, fixed / solved / done
andreasberner opened issue at 2019-09-05 08:13:¶
I am trying to use rear to create a virtual copy from a physical
system.
The virtual system is indeed different from the physical system and this
is likely the reason for the above error message but I am trying to
overcome this anyhow.
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.00-git201704252000 / 2017-04-25 - OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat
/etc/os-release"):
Debian 8.11 - ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=ISO
OUTPUT_URL=file:///tmp/backup
BACKUP=NETFS
# BACKUP=EXTERNAL
BACKUP_URL=iso:///backup/
# Wegen Restore Problem auf Virtueller Maschine bei Netcup
AUTOEXCLUDE_MULTIPATH=n
BOOT_OVER_SAN=y
-
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
Source: Physical maschine with 16GB RAM, 2*1 TB Harddisk with hardware Raid controller, RAID 1, LVM configuration of Harddisk
Target: Virtual Mashine KVM with 480 GB SAS and 16GB, Intel XEON -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
X86 compatible -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Bootloader GRUB 2 -
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Source local Harddisk 2*1TB with Hardware Raid controller, RAID 1 -
Description of the issue (ideally so that others can reproduce it):
When trying to install the ISO on the target the system would stop
with above message. -
Workaround, if any:
-
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
(I have problems to copy the logfile to here)
hamantri commented at 2019-09-05 15:38:¶
hi,,can anyone help on this issue it is been some time without a result
hamantri commented at 2019-09-05 15:55:¶
# /usr/sbin/rear -V
Relax-and-Recover 2.1-git.0.b346935.unknown.changed / 2017-07-07
# cat /etc/rear/os.conf
OS_VENDOR=SUSE_LINUX
OS_VERSION=12
# cat /etc/os-release
NAME="SLES"
VERSION="12-SP4"
VERSION_ID="12.4"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles_sap:12:sp4"
# cat /etc/rear/site.conf
OUTPUT=ISO
ISO_PREFIX=ROOTVGonly-rear-$HOSTNAME
BACKUP=NETFS
BACKUP_URL=nfs://<ip>/suse_backups
BACKUP_OPTIONS=nfsvers=3,nolock
ISO_MKISOFS_BIN="$( type -p mkisofs || type -p genisoimage )"
ONLY_INCLUDE_VG=( "rootvg" )
BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' '/home/rear/*' '/mnt/*' )
REQUIRED_PROGS=( ${REQUIRED_PROGS[@]} snapper chattr lsattr )
COPY_AS_IS=( ${COPY_AS_IS[@]} /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
SSH_ROOT_PASSWORD="test4backup"
BOOT_OVER_SAN=Y
AUTOEXCLUDE_MULTIPATH=n
# 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.
Hardware---Power PC lpar---p8
Linux 4.12.14-95.24-default #1 SMP Thu Jul 11 13:05:06 UTC 2019 (7b265b8) ppc64le ppc64le ppc64le GNU/Linux
System architecture----ppc64le
Firmware---sys0!system: FW860.20 (SV860_082) (t) FW860.20 (SV860_082) (p) FW860.20 (SV860_082) (b)|service: 00302017030381CF0681
bootloader
# rpm -qa |grep -i grub
grub2-branding-SLE-12-13.3.1.noarch
grub2-2.02-12.15.1.ppc64le
grub2-powerpc-ieee1275-2.02-12.15.1.ppc64le
grub2-snapper-plugin-2.02-12.15.1.noarch
grub2-systemd-sleep-plugin-2.02-12.15.1.noarch
ruby2.1-rubygem-cfa_grub2-0.6.5-3.7.2.ppc64le
Storage---------san
# multipath -ll | grep -i mpath
mpathe (36005076304ffd70e0000000000002204) dm-8 IBM,2107900
mpathd (36005076304ffd70e0000000000002203) dm-5 IBM,2107900
mpathc (36005076304ffd70e0000000000002202) dm-0 IBM,2107900
mpathb (36005076304ffd70e0000000000002201) dm-3 IBM,2107900
mpatha (36005076304ffd70e0000000000002200) dm-9 IBM,2107900
mpathh (36005076304ffd70e0000000000003b03) dm-4 IBM,2107900
mpathg (36005076304ffd70e0000000000003b02) dm-2 IBM,2107900
mpathf (36005076304ffd70e0000000000003b01) dm-1 IBM,2107900
# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/mpathh-part2 rootvg lvm2 a-- 59.97g 35.38g
Description of the issue
We are having suse sles12sp4 on power lpar,,,we installed the rear rpm packate and using that created rear iso image ,,,now we took this image and mounted it on another lpar and we get into resuce mode ,,when we run #rear recover command we get the below error
Start system layout restoration.
Creating partitions for disk /dev/mapper/mpathp (msdos)
Disk layout created.
ERROR: No filesystem mounted on '/mnt/local'. Stopping.
Aborting due to an error, check /var/log/rear/rear-hedcb014.log for details
Terminated
logs
****
race 0: /bin/rear:535 main
Trace 1: /usr/share/rear/lib/recover-workflow.sh:17 WORKFLOW_recover
Trace 2: /usr/share/rear/lib/framework-functions.sh:95 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source
Trace 4: /usr/share/rear/layout/recreate/default/250_verify_mount.sh:5 source
Message: No filesystem mounted on '/mnt/local'. Stopping.
== End stack trace ==
2019-09-03 11:22:26.961166359 Running exit tasks.
2019-09-03 11:22:26.963508185 Finished in 380 seconds
2019-09-03 11:22:26.964939615 Removing build area /tmp/rear.V1q4f8LSDjytHmT
removed directory '/tmp/rear.V1q4f8LSDjytHmT'
2019-09-03 11:22:26.971413270 End of program reached
hamantri commented at 2019-09-05 15:56:¶
i guess i have provided the details you have rqeusted for please let me know if you need any additonal details
hamantri commented at 2019-09-06 08:21:¶
actually there is another input that migth be addition to your investigation,,both the the source lpar and destination lpar where i am try to put the iso image are lpars they are not phyiscal ,,,on poweor systems we call it lpars,,,,
the lpar on which the iso image it taken is having rootvg disk named as mpathh,,,the lpar on which the image i am trying to load is having only one disk and the disk is named as mpatha,,,for me this should not be a cause of concern but yes if it adds on to your investigation it would good
hamantri commented at 2019-09-06 10:27:¶
hi any luck on my query
andreasberner commented at 2019-09-06 12:23:¶
Hi Hamntri,
thank you for your multiple responses. I appreciate that.
However, I am afraid I can't relate your anwers to my question.
Are you sure you anwered my question?
gozora commented at 2019-09-06 12:55:¶
@andreasberner, I don't have exact answer for your problem, but I'd recommend you to start with storing your ReaR recovery system (ISO) and backup separately on some remote (CIFS or NFS) share.
Something like:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://your.NFS.server.IP/path/to/your/rear/backup
here you can find some easy and tested configuration examples.
Be aware file:// as a destination can be quite tricky and might require some hacks to work correctly ...
V.
gozora commented at 2019-09-06 13:07:¶
@hamantri I'm somehow confused by your posts. As @andreasberner already
wrote, they looks to be unrelated to this issue.
If you want, you can open new issue by filling the template
here.
V.
andreasberner commented at 2019-09-06 13:55:¶
@gozora: Thank you for your advice the source server is in a remote
location and I would do hard to store the backup somewhere else if not
on file. I have already used rear on a different hardware where I store
everything on a mounted USB-Stick and this works like a charm.
Can you explain a bit more into detail why storing the resulting backup
in a file would be problematic?
Of course I moved away to the iso to the cd of the desingated copy
computer right after creating the iso on the source.
gozora commented at 2019-09-06 14:03:¶
@andreasberner
Can you explain a bit more into detail why storing the resulting backup in a file would be problematic?
Well, I'm afraid I can't give you qualified answer, because I've never
actually used file://. and honestly I have just foggy idea how it
works ...
Anyhow, as far as I remember there has been some people already having
trouble when they used file://, so you can search in closed
issues
and maybe you will find something usefull ...
V.
jsmeix commented at 2019-09-10 14:49:¶
@andreasberner
in general when you like to recreate on different hardware
(where "hardware" could be also virtual hardware)
things can get soon rather complicated, see my
explanations in the mail thread with subject
"Move from bare-metal2vm ?"
http://lists.relax-and-recover.org/pipermail/rear-users/2018-November/003626.html
on the "rear-users" mailing list at
http://relax-and-recover.org/development/
gdha commented at 2019-11-29 09:11:¶
@andreasberner Did you looked at the target system in detail when this
issue happened? Were the file systems created? Could you inspect this
with fdisk or parted? vgs, lvs and pvs commands?
The error seems to be related that the desired file system was not
created somehow. The logs should tell you more what really happened as
these are quite detailed for that section (in creating the disk
partitions and so on).
gdha commented at 2020-01-23 15:36:¶
@andreasberner Is this issue still relevant? I see Debian, Sles and lpar ?? Very confusing...
jsmeix commented at 2020-01-27 13:11:¶
@gdha
I think the confusing SLES and lpar you see are in comment
https://github.com/rear/rear/issues/2227#issuecomment-528436475
but This comment was marked as off-topic.
by me.
jsmeix commented at 2020-06-24 10:58:¶
Because "no news is good news" I close it.
[Export of Github issue for rear/rear.]