3

Setup:

Linux Debian Jessie based
Arch is armv7l
kernel is 4.4.14-v7+
tar (GNU tar) 1.27.1

We have an archive, config.tar.gz, which replaces already existing config files. Extraction was done via ssh on the device with tar -xzvf config.tar.gz -C /

The archive is packed with absolute paths so this is normally OK (for this setup). The same procedure was done for 14 similar devices, which are identically configured and have identical hardware and software on them.

One device, however, was unable to write the config files, it just replaced those files with files of same name and 0 byte size.

After that extraction, a manual reboot was done to have all newly extracted configuration files work with the custom services we use.

The drive itself doesn't seem to be broken, no inode issue, no write error, no issue with not enough space or similar related problems.

The hard drive (actually an sdcard) does not show any issues and is perfectly usable.

Sadly, the output of the tar command is not available anymore.

The usual logs (syslog, messages, auth, daemon, journalctl, custom logs we create), all show nothing which seems related.

I have the sdcard here but cannot reproduce the error with either that card or another with the same configuration.

What could have caused this? How can I ensure it doesn't happen again?

closed as off-topic by user34720, countermode, GAD3R, Rui F Ribeiro, Archemar Jan 13 '17 at 13:32

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Community, countermode, GAD3R, Rui F Ribeiro, Archemar
If this question can be reworded to fit the rules in the help center, please edit the question.

  • You mention it's not reproducible. Does this mean that a second attempt to extract the configuration files on the same system with the same SD card worked correctly as expected? – roaima Jan 13 '17 at 11:58
  • to answer the comment: yes further info: it did happen again though not while extracing a tar.gz but rather after an rsync (which finished just fine,no error) so for now without further proove i am assuming a sync/fs error instead of an actual tool issue. – Dennis Nolte Mar 24 '17 at 12:16
  • 1
    I've seen something similar on a Raspberry Pi. It seems to be related to a big filesystem update followed fairly shortly by power-off without confirmed sync to disk. In my situation the simple answer is "sync the disks explicitly". I've not logged a bug-report because I can't reliably reproduce the problem. – roaima Mar 24 '17 at 16:56

Browse other questions tagged or ask your own question.