/run/resolvconf/resolv.conf not copied, no DNS in rescue system

[mat156]

Relax-and-Recover (rear) Issue Template

Please 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-git201702131649 / 2017-02-13
• OS version (cat /etc/rear/os.conf or lsb_release -a): Ubuntu 16.04.1 LTS
• rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

OUTPUT=ISO
BACKUP=NETFS
BACKUP_PROG=tar
BACKUP_TYPE=incremental
FULLBACKUPDAY="Sun"
NETFS_KEEP_OLD_BACKUP_COPY=y
FULLBACKUP_OUTDATED_DAYS=7
BACKUP_URL=cifs://filer.domain.tld/public
BACKUP_OPTIONS="cred=/etc/rear/cifs"

• Are you using legacy BIOS or UEFI boot? VMware ESX 6.0 with BIOS boot VM

• Brief description of the issue: after booting the rescue system, no DNS resolving is possible because /run/resolvconf/resolv.conf is not copied. I checked backup.log and there is no entry for this file. I know support for dynamic resolvconf generation was added some time ago and I checked the content of /usr/share/rear/rescue/GNU/Linux/300_dns.sh where everything was fine, except the file is not copied. Are there hidden options elsewhere which deny copying files from /run/...?

• Work-around, if any:

backup.log.txt

[jsmeix]

As a workaround for now use the
COPY_AS_IS
array to get things copied into the ReaR recovery system
(see default.conf), i.e. like:

COPY_AS_IS=( "${COPY_AS_IS[@]}" '/run/resolvconf/resolv.conf' )

FYI:
Regarding "I checked backup.log":
Do not mix up what files get saved in the backup with what
files are used (copied) to build the ReaR recovery system.
Both are totally different things.

[jsmeix]

Whoops!
I overlooked that you wrote about
usr/share/rear/rescue/GNU/Linux/300_dns.sh
where that file is already in the COPY_AS_IS array.

You need to inspect the ReaR log with full debugging
to find out why it is not copied into the ReaR recovery
system, i.e. run

rear -d -D mkbackup

and inspect the ReaR log file for entries about that file.

[jsmeix]

Additionally you may use
KEEP_BUILD_DIR="yes"
so that ReaR's working area is not deleted
when "rear mkbackup" finished so that you can inspect
what there actually is in the rescue/recovery system.
The ReaR working area is usually a directory
of the form /tmp/rear.XXXXXXXXXXXXXXX and
therein there is in particular the rescue/recovery system.

[mat156]

first: thanks for your time and comments. I just did a backup job with your recommended options. here is a tree of the /tmp/rear.xxx folder:

├── rootfs
│   ├── bin
│   ├── boot
│   ├── dev
│   ├── etc
│   ├── init -> bin/init
│   ├── lib
│   ├── lib64
│   ├── mnt
│   ├── proc
│   ├── root
│   ├── run
│   ├── sbin -> bin
│   ├── selinux
│   ├── sys
│   ├── tmp
│   ├── usr
│   └── var
└── tmp
├── backup-exclude.txt
├── backup-include.txt
├── backup.log
├── boot
├── bootloader
├── copy-as-is-exclude
├── copy-as-is-filelist
├── initrd.cgz
├── isofs
├── isolinux
├── mappings
├── nfs.mount.info
├── parted
├── partitions
├── partitions-data
├── partitions_unsorted
├── README
├── rear-vm-mherzog-test.log
└── VERSION

I took a look into tmp/copy-as-is-filelist and tmp/rear-vm-mherzog-test.log. The only thing which looks strange is a tar error in copy-as-is-filelist. could you point me to the directoy where exactly the rescue system is located?

copy-as-is-filelist.txt
rear-vm-mherzog-test.log.txt

[mat156]

I had a closer look into /tmp/rear.xxx/rootfs/run and also deflated /tmp/rear.xxx/tmp/initrd.cgz which I think is integrated to boot ISO of the recovery system.

/run/resolvconf:
does exist in /tmp/rear.xxx/rootfs/
does exist in deflated initrd.cgz from /tmp/rear.xxx/tmp/
does NOT exist in the booted rescue environment

[gdha]

@mat156 the resolvconf command is used to regenerate a /etc/resolv.conf file, therefore, the question should be what is the content of /etc/resolv.conf ?
The content under /run/ is automatically generated by a running system, and we should only foresee the directory structure, nothing more. Copying files to it has no meaning as far as I understood it.
Furthermore, I do not think resolvconf executable is copied to the rescue image.
Secondly, I think the next line is not correct:

/usr/share/rear/rescue/GNU/Linux/300_dns.sh:COPY_AS_IS=( "${COPY_AS_IS[@]}" /etc/resolv.conf /run/resolvconf/resolv.conf /etc/hosts /etc/host.conf )

Personally, I think it should be:

/usr/share/rear/rescue/GNU/Linux/300_dns.sh:COPY_AS_IS=( "${COPY_AS_IS[@]}" /etc/resolv.conf /etc/resolvconf /etc/hosts /etc/host.conf )

And we should also copy the resolvconf executable:

REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" resolvconf )

But, again, start with the /etc/resolv.conf file.

[mat156]

the /etc/resolv.conf file shows

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.30.50
search eaalab.hpi.uni-potsdam.de epic.hpi.uni-potsdam.de hpi.uni-potsdam.de

which is the automatically generated content by resolvconf. but these entries are not taken to the rescue image to provide DNS resolving. is there a way to override these (non existent) settings with variables from a config file like the entries ip_adresses or routes in the subfolder mappings in /etc/rear ?
Otherwise I would have to puppetize 100 systems /etc/hosts entries to manually resolve the backup server's IP address.

[jsmeix]

@gdha
regarding "we should also copy the resolvconf executable" in your
#1200 (comment)
I think there is a typo and you actually meant

REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" resolvconf )

[gdha]

@jsmeix thanks! You were right - that happens when you are busy with 3 things at a time...
@mat156 Are you sure the /etc/resolv.conf file is not correct within the rescue image? It will be copied.
Or, are you saying the IP range is completely different in the rescue image (vlan)?

[mat156]

in my rescue environment (tested it now on 3 different installations of ubuntu 16.04: virtualbox, vmware ESX and physical host HP Proliant DL580G7) I only see this:

no, ip range in rescue system is just the same as production. no vlans.

[jsmeix]

@mat156
a question only out of curiosity (I am not a cifs user):
Why can't you use the IP address like

BACKUP_URL=cifs://192.168.100.1/public

?

[gdha]

@mat156 interesting - the link to /run/resolvconf/resolv.conf works nice during the mkbackup workflow and you will find the link (and the file itself in the rescue image directory), but once you boot off the RESCUE image ISO the /run directory will be empty again (as designed by nature). Therefore, we should make sure /etc/resolv.conf file contains the data and is not a link to another file (would be much better)

[mat156]

@jsmeix
point for you, could use that, works of course without DNS. but I remember having problems mounting cifs shares in former versions (either ReaR or Ubuntu). for now this is a workaraound.

@gdha
this would be much much better...

[gdha]

The issue was already reported in #520 - but the fix was not 100% correct (only 50% I would say) - nobody seemed to bother to test it fully afterwards (I'm guilty too)

[mat156]

no one's guilty... how do we proceed? I think this may be closed here and #520 reopened/continued?!

[jsmeix]

The issue should now be fixed via
5390105