Impossibly large file

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.

I finally found the issue.

$ ll -h /var/lib/dhcp/proc/kcore
-r-------- 1 root root 128T Aug  1 21:10 /var/lib/dhcp/proc/kcore

A 128 terabyte (140,737,477,885,952 bytes) file. On a volume that has about 300GB free. tar valiantly tried to back it up.

An attempt to remove it did not succeed: “Read-only file system”. Probably just as well.

How is this file size possible? What is this file that is a file system?

Adding an --exclude option fixed the backup issue.

$ tar --exclude=/var/lib/dhcp/proc/* -czf /data01/backups/root/var-lib.tar.gz /var/lib/

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 normally don’t backup the root file system, because I would prefer to reinstall rather than recover from backup.

However, the last time that I did a backup of the root file system, I used something like:


mount --bind / /mnt

and then I backed up “/mnt” which was really the root partition but without any mounts on it.

When done with the backup, I used

umount /mnt

to undo that bind mount.

But Ihave only 8GB RAM, not 128TB.

You should never backup proc directories as those are virtual and are re-created on every system startup

Lesson learned.

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

Did you try it?

That 128TB file is not present in the “/mnt” tree that I created with that bind mount. So it won’t be backed up.

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.

After the upgrade, did you execute the following?

  • ‘rpmconfigcheck’ – normally indicates which configuration files need to be checked for changes after the upgrade …
  • ‘zypper verify --details --recommends’
  • ‘rpm --verify --all’

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.

It should be at “/usr/sbin/rpmconfigcheck” and that is on the normal root path

Nope, not there. Nor is it available from any of the loaded repositories.

In yast software management search check the box rpm provides. It is not a stand alone package but part of the general rpm package

Checking here, it should be part of the package “rpm”. You can check the file list with Yast software management.

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:

  1. Do nothing (most of the time, this works);
  2. 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.
  3. 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&gt; – 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 …