I was tracing why a tar was creating an absurdly large backup. For a directory tree that “du” claims has about 780MB, it had made 7.9GB file and was continuing to add to it.
It represents the physical memory of your system - it’s there because dhcp runs in chroot.
You should never backup proc directories as those are virtual and are re-created on every system startup (as well as /dev, /sys, /tmp, /run and a few other locations)
Along with this, you may also want to consider the --one-file-system
option to the tar command if you are doing backups like this. It should
prevent tar from wandering across filesystem boundaries, which in your
case would probably stpo it from going into /var/lib/dhcp/proc in the
first place. Keep in mind some applications MAY stretch across
filesystems, but it is more common for all data to be in one.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
I only backup /etc/ and /var/lib/. Which had proven to be wise for the LEAP 15.0 upgrade from 42.3; the upgrade did not go well for non-default services, most of them being either not enabled or reset to default values. Having a backup of /etc/ and /var/lib saved me some grief.
However, the last time that I did a backup of the root file system, I used something like:
The suggestion would do nothing to prevent the original problem: backing up the mysteriously huge 128TB file.
Well no mystery, That is a virtual file that represents the whole address space available to the processor. It is created at boot. Normally it is in /proc. Not in /var but apparently some program decided it needed a link. dhcp??? any how you have no need and should never backup anything in any directory called /proc
I did.
Apparently I did not look in the correct directory when I was verifying the result earlier. Doing this again, there is nothing under …/var/lib/dhcp/proc/, as you noted.
Where might one find “rpmconfigcheck”? Its existence shows in a web search but not where to get an executable.
I get the same two problems no matter how often I select “skip.” It’s an infinite loop.
$ zypper verify --details --recommends
Loading repository data...
Reading installed packages...
2 Problems:
Problem: nothing provides appdata(calibre-ebook-viewer.appdata.xml) needed by application:calibre - E-book Viewer-.noarch
Problem: nothing provides appdata(calibre-ebook-edit.appdata.xml) needed by application:calibre - E-book Editor-.noarch
Problem: nothing provides appdata(calibre-ebook-viewer.appdata.xml) needed by application:calibre - E-book Viewer-.noarch
Solution 1: deinstallation of application:calibre - E-book Viewer-.noarch
Solution 2: break application:calibre - E-book Viewer-.noarch by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c):
“rpm --verify --all” produced some useful results. Many of the results simply said that the configuration file in the package and in the system are different; it is to be expected.
Okay, found it. It is named “rcrpmconfigcheck.” /var/adm/rpmconfigcheck is the output of running rcrpmconfigcheck. I do not know what this is telling me, though; what is unrelsolved about files that exist?
$ rcrpmconfigcheck
Searching for unresolved configuration files done
Please check the following files (see /var/adm/rpmconfigcheck):
/etc/plymouth/plymouthd.conf.rpmnew
/etc/postfix/main.cf.rpmnew
/etc/postfix/master.cf.rpmnew
/etc/sddm.conf.rpmnew
/etc/sysconfig/SuSEfirewall2.rpmnew
I’ll look at the firsst of those (“plymouthd.conf.rpmnew”).
There is a file “plymouthd.conf” in your system. An update had a new version of that file. But because you already have that file, and it is considered a local configuration file, the new version did not replace the old version. Instead the new version was named “plymouthd.conf.rpmnew”.
So what should you do about that?
The possibilities are:
Do nothing (most of the time, this works);
Replace your “plymouthd.conf” with “plymouthd.conf.rpmnew”. The trouble with doing this, is that “plymouthd.conf” was probably changed at some time, and has local settings. It might have even been changed by the installer, so that you didn’t know about those changes. So be cautious about doing this.
Merge the changes to the new version, and then use it to replace the current version. The difficulty here is that you might need to do some investigation to work out how to merge them. If you think this component is causing problem, then it might be worth the effort.
I’ll note that you can use:
diff -u plymouthd.conf plymouthd.conf.rpmnew
to help see what changed between the two versions of that file.
Sometimes you might see a file name ending in “.rpmsave” (also from the same rpmconfigcheck command). This happens when the changes are important enough for the update to force updating this file. And the version with “.rpmsave” is the old version of the file, in case you need to look at that and merge some of your changes.
> rpm --query --whatprovides /usr/sbin/rpmconfigcheck
rpm-4.14.1-lp150.9.3.1.x86_64
> zypper info rpm
Loading repository data...
Reading installed packages...
Information for package rpm:
----------------------------
Repository : Hauptaktualisierungs-Repository
Name : rpm
Version : 4.14.1-lp150.9.3.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 4.6 MiB
Installed : Yes
Status : up-to-date
Source package : rpm-4.14.1-lp150.9.3.1.src
Summary : The RPM Package Manager
Description :
RPM Package Manager is the main tool for managing the software packages
of the SUSE Linux distribution.
RPM can be used to install and remove software packages. With rpm, it
is easy to update packages. RPM keeps track of all these manipulations
in a central database. This way it is possible to get an overview of
all installed packages. RPM also supports database queries.
>
Please note that, the German language repository is: <http://download.opensuse.org/update/leap/15.0/oss> – the main Leap 15.0 OSS update repository.
[HR][/HR]Please check that, all your repositories are in fact those for Leap 15.0.
Yes, a few releases ago the thing was named ‘rcrpmconfigcheck’ …
Therefore, unfortunately, the conclusion is, somehow, you’ve mixed “pre-Leap 15.0” with “actual Leap 15.0” – unfortunately …