I must confess to starting to get rather more than a little frustrated with this.
Cliff’s Notes: name resolution fails during initrd/initramfs processing.
This wasn’t much of a problem with 3.0.3, as all of the NFS info was stored by IP address. In 3.2.2, it’s stored by symbolic name.
So… I have come to the realization that I need to add /lib*/libnss* to /etc/mindi/deplist.d/minimalist.conf *AND* another file in /etc/mindi/deplist.d. This will get name resolution working during the
initrd/initramfs phase (apparently,) as well as included in images/all.tar.gz for use during the running recovery session.
And it’s starting to get stranger. I can run an automatic compare and an automatic nuke, but an interactive restore will fail *UNLESS* I manually mount /tmp/isodir from the command line prior to running
mondorestore (during a booted mindi/mondo session.)
Both the compare and the interactive session have problems mounting during the initrd/initramfs phase (in spite of my better efforts:)
09:08 INFO: Pinging Remote server...
ping: unknown host ahddr005
Starting rpcbind daemon...
09:08 INFO: Mounting Network share (ahddr005:/data/col1/mondo_local/ahdoul011) on /tmp/isodir...
mount.nfs: Failed to resolve server ahddr005: Name or service not known
09:08 INFO: Mounting Remote image ahdoul011-1.iso in / on /mnt/cdrom in loopback
/tmp/isodir///ahdoul011-1.iso: No such file or directory
Here’s an excerpt from the compare session:
DBG2: [Main] libmondo-devices.c->mount_media#1342: Mounting for Network thingy
DBG2: [Main] libmondo-devices.c->mount_media#1343: isodir = /tmp/isodir
DBG2: [Main] libmondo-devices.c->mount_media#1410: (mount_media) --- command = mount /tmp/isodir///ahdoul011-1.iso -t iso9660 -o loop,ro /mnt/cdrom
INFO: running: mount /tmp/isodir///ahdoul011-1.iso -t iso9660 -o loop,ro /mnt/cdrom > /tmp/mondo.tmp.EnFdkD/mondo-run-prog-thing.tmp 2> /tmp/mondo.tmp.EnFdkD/mondo-run-prog-thing.err
INFO: --------------------------------start of output-----------------------------
INFO: --------------------------------end of output------------------------------
INFO: ...ran just fine.
DBG2: [Main] libmondo-devices.c->mount_media#1426: Mounted media drive OK
The interactive session never appears to mount /tmp/isodir after the initrd/initramfs attempt. It bombs off, telling me I need to mount it first. Has anyone noted had this behavior?
As a rule, I will not be able to use the nuke recovery method. Here, Mondo is only used to back up the running operating system. All other filesystems are backed up using other applications. And… when I have
had to recover an operating system in place, I absolutely, positively, have had to preserve all of the other filesystems.
At this point, I need to decide how much further down the rabbit hole I want to go, and/or modify my recovery docs to manually mount /tmp/isodir (which just might be acceptable,) prior to partitioning and making
From: Kalchik, Jeffery [mailto:JDKalchik <at> landolakes.com]
Sent: Wednesday, May 11, 2016 9:11 AM
To: Mondo mailing list <mondo-devel <at> lists.sourceforge.net>
Subject: [Mondo-devel] Mondorescue 3.x issues?
Good morning, all.
I’ve been using Mondo (currently 3.0.3) for several years for disaster recovery, not cloning, here, on the physical servers. Oracle Linux 5 & 6, CentOS 6, and RHEl 5 and 6. EL7 based distributions are on the way. All backups are written
to an NFS repository (the D/R tagged servers get replicated off-site immediately.) The majority of the physical hosts using Mondo are running Oracle Linux 5 (sorry, Bruno….) Most of the physical hosts are HP bl460c G6 blades, with a few Cisco UCS blades.
I’ve been tinkering with 3.2.2 since it was released a couple of weeks ago. It appears that there is a significant change in the first generated ISO file, all of the network mounts now are using a symbolic name, whereas in 3.0.3, those
were all converted to the IP address. Unfortunately, if I boot up with an ISO image from a 3.2.2 backup (mindi 3.0.2 and mindi-busybox 1.21.1,) none of the symbolic lookups work and restores fail. If I add a configuration file to /etc/mindi/deplist.d with
‘/lib*/lib*nss*’ (expanded,) name resolution finally works at a shell prompt, but an automatic recovery will still fail, not being able to find any of the config files. If I then run something like ‘mount –o ro,nolock ahddr005:/data/col1/mondo_local/ahdoul011
/tmp/isodir’ and rerun mondorestore, selecting automatic recovery, it proceeds gracefully through all of the disc images.
I must be doing something fundamentally wrong, as network name lookups should be proceeding immediately, even during the initram processing. I have verified that the mounts in the initramdisk images match the contents of /tmp/NETFS-SERVER-MOUNT.
Mondo 3.0.3, /tmp/NETFS-SERVER-MOUNT: 172.21.173.31:/data/col1/mondo_local/ahdoul011
Mondo 3.2.2, /tmp/NETFS-SERVER-MOUNT: ahddr005:/data/col1/mondo_local/ahdoul011
I must be doing something rather fundamentally wrong. The conversion from symbolic name to IP address obviously is what allows 3.0.3 to work, and the lack of conversion is what’s causing 3.2.2 to have problems. As near as I can tell,
I have the same issue regardless of distribution.
I’ve attached the mindi log, the mondoarchive log, as well as the captured output from my control script (‘mondo_ahdoul011*.log’, verbose output, you can see exactly how mondoarchive is called.) If the attachment gets stripped out, I’ll
post up the log archive on a public server. I’ve also attached the mondorestore logs from the initial boot. The 3.0.3 version does successfully mount the /tmp/isodir directory at some point before the shell prompt is available, the 3.2.2 version does not.
Any suggestions on where to start digging deeper?
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed,
copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are
not the intended recipient, please contact the sender by reply email and delete all copies of this message.