LONE-TAR ERROR Reference (Chapter 5)

5.1 INTRODUCTION TO ERROR MESSAGES Back To Top

This section explains each and every error message of LONE-TAR and the conditions that must be present to create the error message. Additionally, solutions or corrective measures to be taken are discussed.

This section includes discussions of FATAL messages that cause immediate termination of LONE-TAR, and WARNING or diagnostic messages that simply inform the user of problems encountered as well as unique situations that may exist.

The messages have been abbreviated where a number or string would normally appear. A string is abbreviated as%s. Usually the string is a string of characters representing the actual name of the file that caused the error. The string may represent the name of the backup device or it may represent an option letter. The meaning is usually apparent by context. Simple digits are abbreviated as %d and longer digits are abbreviated as%ld. The symbol {filename} represents the actual pathname of the involved file. The symbol {device-name} represents the actual name of the backup device (e.g. /dev/rct0). Many messages print out why they occurred and this is symbolized by {reason} at the end of a message.

5.2 ERROR RETURN CODES Back To Top

LONE-TAR returns a diagnostic code indicative of what went wrong during the backup or restore process. A return code of 0 means the backup/verify/restore was successful. The following list shows the possible return codes and their respective meaning:

It is important to distinguish these LONE-TAR diagnostic return codes from the UNIX system error codes. The LONE-TAR binary itself reports UNIX system error codes on the screen or in the catalog file. For example, ``LONE-TAR: Tape Write ERROR 5 occurred because I/O error'' is a common error message. The error 5 reported is a UNIX system error code that means there was an input/output error. Table 23 shows the common UNIX system error codes that you may encounter. For codes not described in this table, see the file /usr/include/sys/errno.h.

When you use ltmenu or receive mail from LONE-TAR.cron, the error reported is the LONE-TAR diagnostic return code. This is 0-143 and interpreted as shown above. This diagnostic return code, if not zero, represents a broad error category and its meaning is specific to LONE-TAR alone. You can run grep on the following words in the catalog files to find out what the error was during a backup: WARNING, LONE-TAR:, Failed, is not. For example, the command ''grep LONE-TAR: /usr/lib/ltar/BACKUPS.DIR/LAST_Master'' finds any error messages.

5.3 FATAL ERROR MESSAGES Back To Top

5.3.1 Fatal Errors While Backing Up Back To Top

1. lone-tar: Trying to seek on non-seeking device!! Use 'C' or 'f' option and avoid 'n' option Alternatively use 'P' option to force compression on non- seeking device

You have tried to compress files on a device that won't seek. There were errors when trying to seek on the device. You either need to choose another device that seeks or force no compression with the C option. Additionally, you can use the P option (pack regardless) which compresses the files regardless of whether the backup device seeks or not. However, when you use this option you must also include the proper k factor (size of the backup device in kilobytes).
This is probably the most common fatal error that causes lone-tar to stop. This means the backup device (tape or floppy) has developed a bad sector or section of tape. This is a hardware media error and means it is time to get new floppy disks or tape cassettes. If this does not resolve the problem, try cleaning the unit or having the hardware sent for maintenance or repair.
This means a fatal hardware error occurred on the device in question. LONE-TAR could not write all the data to the backup device. When using a floppy, this is usually because of a bad sector on the floppy disk. When using a tape, it means a bad section of tape.
If the number of bytes is displayed, only part of the data was successfully written to the backup device. It is possible that the backup device ran out of room before all the data could be written. This could be because the blocking factor is not an even divisor of the tape size. Simply specify a smaller k factor next time and you will have no further problems.
It is also possible that the data is being piped across a network and the network is unreliable. Only part of the data was transferred.
The offset specifies how many kilobytes into the backup this error occurred. If this number is the same no matter what list of files you back up, you have found a bad spot on the backup device at this offset.
The room left signifies the amount of room left on the backup device. If greater than zero, there is still plenty of room to write the data. The default value for room left is a very large number.
While backing up the specified file, a HARDWARE error occurred. This usually means there is a bad block on the hard disk involving this particular file. The reason is given. Usually this is a serious error and could be a sign of a failing hard disk. If you continue the backup, the following messages appears:
The bad sector of data is replaced with lower-case x's. If this file is later restored, a section of it will contain lower-case x's.
If the backup is being done in the background, a yes answer is automatically supplied. The fact that a file was incompletely backed up is reflected in the backup summary.
This message is produced if an unreadable block is encountered while compressing a file. If you choose to continue the backup, the compressed file is truncated at the point where the hard disk read error occurred. When the file is restored it is shorter than the original version. If the backup is being done in the background, a yes answer is automatically supplied. The fact that the file is incompletely backed up is reflected in the backup summary.
Set the environment variable TMPDIR to your largest filesystem
This message is only produced if the P option is used. This message means that the Virtual Pipe ran out of space. It usually occurs when compressing a very large file, or just after compressing a large file.
The Virtual Pipe is a pipe that consists of machine memory (the amount depends on your binary) and free space on one of the filesystems. The default filesystem used is the filesystem that contains the directory /usr/tmp. Sometimes, this is a small root filesystem that has limited free space. The limited amount of free space was used up by the virtual pipe and it simply ran out of room. LONE-TAR requires that there be at least as much free space in the filesystem used as the size of the compressed version of any given file.
The solution to the problem is to instruct LONE-TAR to use another filesystem for it's Virtual Pipe. The way of doing this is to set the variable TMPDIR to a directory that exists on a larger filesystem. For example, if /dev/u is a large filesystem with 100 Mb of free space and is mounted on the directory /u the command to get LONE-TAR to recognize this is:
In this example, it is assumed that the directory tmp resides on the filesystem /dev/u mounted on /u. If it does not exist, then make it first by typing:
The above example assumes you are using LONE-TAR from the command-line. If you receive the error ``lone-tar: PIPE QUE ERROR - FATAL'' when using LONE-TAR from ltmenu or while running an unattended Incremental or unattended Master backup, then you can edit the file /usr/lib/ltar/variables. This file contains the initialization of the TMPDIR variable. It is read by the ltmenu and lone-tar.cron scripts when they are invoked.
It is best to adjust this variable using ``ltmenu -setup'' and selecting choice 6 Change internal menu variables (Experts Only) and selecting the numbered choice that corresponds to TMPDIR. Simply, change the name of the temporary directory to one which resides in a filesystem with the largest amount of free space.
To verify that you have indeed set the correct filesystem, and that LONE-TAR has recognized this, you can run the command df while LONE-TAR is running and compressing a large file. You should see the available number of blocks decrease on the filesystem you have selected with the TMPDIR variable. If you see the root filesystem free space decreasing, you know you did not set the variable correctly or LONE-TAR did not recognize it.
No more memory is available. This occurred while LONE-TAR was traversing the filesystem. Usually, this occurs when the memory to hold the ever increasing linked file map exceeds the system memory available. The linked file map holds all the files that are linked on the system. The more links that exist, the more memory this requires. To remedy this problem, you can either use a smaller block factor (b option) or turn compression off with the C option. If neither of these work you may have to increase the maximum memory per process (see UNIX manual) or add more memory to the hardware.

5.3.2 Fatal Errors While Restoring or Verifying Back To Top

1. lone-tar: directory not in proper format File header (name, size, date) is unobtainable This means the header information about the file has been corrupted or is not in the TAR format

The header section of the file has been corrupted or the previous header file size was wrong. When reading an archive, LONE-TAR first reads the header block to find out information about the file including the name, size, modification time, number of links, and whether the file is compressed or not. This information, along with a checksum, is contained in header.
The above error message means that the recomputed checksum does not match the checksum stamped into the header when it was created. More often than not, the data block in question is probably not even a header block. This occurs if the wrong volume is inserted in the drive while restoring. Since LONE-TAR usually checks volume numbers when restoring, this is rare. However, it is possible to get two volume sets mixed up. Also, rarely, someone may have overwritten one of the volumes with other information. You are allowed a chance for error recovery. LONE-TAR reads through the data until it finds a valid header block and then resumes restoring from that point on. If LONE-TAR is running in the background, it does not prompt for error recovery, but terminates immediately.
The user is prompted for this message when a hardware error or software error happens during restoring or verifying a backup. If you answer y, LONE-TAR attempts to find the next valid file. You get the message: File {filename} may have CORRUPT DATA
After this, LONE-TAR continues to restore data.
You attempted to restore or list files from a tape, but there is no data on the tape. This means there is no data of any kind on the tape. Make sure the tape is rewound. This can happen if there are two filemarks back-to-back on the start of the tape. If you are convinced the tape has data on it, try the procedure again using the no-rewind tape device.
This occurs when restoring data to the hard disk from a floppy or tape. LONE-TAR has encountered a hardware problem on this hard disk device. This also occurs if the hard disk is out of space. Check the space on the hard disk by using the df command. If you have plenty of space, your hard disk is having problems and you need to map out the bad block in question.
This message appears when LONE-TAR is trying to skip over a file while listing the directory on the archive or while extracting. Something happened to prevent LONE-TAR from getting to the next file. The reason is given.
This is displayed when LONE-TAR has difficulty reading the archive while listing files on the archive or while restoring files. This means a serious hardware error exists with the device or with the archive volume.
This message is displayed when trying to restore from a tape. To fix this, check your SCSI Subsystem and check all SCSI termination. Then be sure that the tape is being read with the same block size as it was written with. Also, you should try to read the tape with the same block size you wrote the tape in. (ie: read the tape in fixed mode if it wouldn't read in variable mode, or vice versa).

5.3.3 Fatal Errors Getting Started Back To Top

1. Using file {filename} for file names to archive Cannot open...

The file specified with the F option could not be opened for reading. Most likely the name was misspelled on the command-line.
The catalog file, where a carbon copy of the screen output goes, cannot be opened for writing. Either a directory in the pathname does not exist, a directory in the pathname does not allow search permission, or the file already exists and is not writable because of permissions.
The volume size specified with the k or s option is a negative number or cannot be converted into a number (i.e. text). Usually this is because the options and arguments on the command-line have been mixed up.
The limit specified with the L option is invalid. The same reasons apply as above.
These must be positive numbers. The blocksize has a defined upper limit depending on the type of CPU. This limit is shown on the general help display of LONE-TAR (displayed when LONE-TAR is typed with no command-line options).
The archive device has not been specified. The f option was given but no name of the backup device to use was given.
The date has been specified incorrectly. The correct usage is shown using examples. There are several ways the date can be specified but the method you chose does not fit any of these. Most likely you reversed month and day-of-the-month. See Specifying Dates and Times on page 67 for details.
The option letter given (%s) may be supported in other versions of LONE-TAR or TAR but not in this one.
An unknown option letter has been given to LONE-TAR. Please check the command-line options and try again.
This means that the command-line option letters were okay, but you did not give LONE-TAR any actual files to back up. Unlike some versions of tar, LONE-TAR does not erase your backup when this happens. A common mistake is to type lone-tar cv instead of lone-tar xv when restoring. Another common way of doing this is to forget an argument in the command-line:
In this case, the file insurance.dat was meant to be backed up, but the user forgot to specify to what device the backup should go.
In order to add files to the end of an archive the device must be seeking. This is because you never know when an archive ends until one has read the last block of data. This block, however, must be rewritten with the new data added to it. Because most tapes and non-seeking devices do not allow a skip one block backwards, a seeking device must be used.
The combination of memory allocated for the blocksize used and the compress/decompress buffers requires too much memory space. The solutions suggested are self explanatory.
This means there was trouble accessing the backup device at the start of a backup. The possibilities are self explanatory.
This means that LONE-TAR is trying to read data from a pipe but there is no data at all in the pipe. In fact the pipe is empty. Check the program that creates the pipe; it probably aborted prematurely. Most commonly this is due to misspelling of the command or an option.

5.4 WARNING MESSAGES Back To Top

5.4.1 Warnings While Backing Up Back To Top

1. lone-tar: can't find {filename} because {reason}

You have given LONE-TAR a list of files to back up but this one specified cannot be found on the hard disk. Usually this is because it is misspelled or it has been removed by another user.
While traversing the filesystem, LONE-TAR has come upon a directory that cannot be accessed. Either the directory was removed or the permissions of the directory do not allow the user of LONE-TAR to search it.
A pathname/filename combination exceeds the maximum number of characters allowed. The maximum number is 170. This may occur on networked systems with long pathnames. It also may occur in a very deeply nested subdirectory. The remedy is to shorten some of the subdirectory names or eliminate the deep nesting. This file is skipped and the backup is continued.
While doing a Master backup, the above file could not be created because of the reason given. Check permissions.
While attempting to do Incremental backup, the date of the last Master Backup is obtained from the file ./etc/Master_backup or ./Master_backup. Neither of these files exists, which means a Master Backup has never been done, the files were removed, or LONE-TAR was invoked from a directory other than that from which the Master Backup was invoked. Check the directory you are in when LONE-TAR was invoked. Generally, Master and Incremental Backups should be done from the root directory.
This means LONE-TAR attempted to put an enforced lock on a file that was locked by another program. LONE-TAR is waiting for the lock on this file to be released. This message is displayed for either UNIX V or XENIX style locking.
This is printed when the lock above has been released and the backup is resuming. It is helpful to know if and when the lock on a large file has been released.
This means LONE-TAR attempted to place an unenforced lock on a file and couldn't because it was already locked by another program. LONE-TAR tries again when finished with the rest of the backup, and if it cannot obtain the lock, it backs up the file anyway.
UNIX versions of LONE-TAR print this message when an unenforced lock cannot be placed on a file because it is already locked by another program. It is possible that another program or user could change this file while it is being backed up. Thus, a warning message is printed.
UNIX versions print this message when an unenforced lock cannot be placed on a file because it was already locked by another program or user. However, because the type of lock placed on the file by the other program or user is a System ENFORCED write lock, LONE-TAR would hang indefinitely (or until the lock was released) if it tried to back up the file. Rather than do this, a decision was made to try again when all other files have been backed up. Hopefully, at this later time, the System ENFORCED write lock will have been released.
LONE-TAR tries to lock files before backing them up so they won't change. If this fails you receive one of the two messages depending on the type of locking available on the system. This is not a critical error, but it does mean that no file locking was done on that particular file while being backed up. If you get many of these messages it would be better to back up in single-user mode.
This appears near the end of a backup. The backup is complete except for those files that could not be backed up because there was a lock placed on them. This message means that another attempt will be made to back them up.
This type of message occurs at the end of a backup when previously locked files are attempted to be backed up. A very special type of lock has been placed on the file by another program or user. This type of lock is an ENFORCED write lock. This means that no program can read the file at all. If any program tries to read the file, it will hang indefinitely (or until the lock is released). LONE-TAR detects this situation and avoids it and informs you of why it did not try to back up the file.
This type of message occurs at the end of a backup when previously locked files are attempted to be backed up. An attempt was made again to obtain a lock on the file, but another program or user already had a lock on the file. Because Level 1 locking was specified, the file was backed up anyway and this warning message lets you know that no lock had been obtained when the file was backed up.
A file was locked and could not be accessed. It was determined that this file would be accessed again at the end of the backup. However, when trying to open temporary save-work-file to put the filename into, the open failed. The temporary save-work-file to be opened would reside in the /usr/tmp directory. Make sure that the /usr/tmp directory exists and that you have access permissions for it. On some systems, this directory may not be /usr/tmp depending on the default location for temporary files in the C library routines
This message means that the locked file was not backed up and furthermore, was not backed up at the end of the backup.
LONE-TAR cannot figure out what kind of file this is. This means the file is not a regular file, directory, block device file, character device file, or named pipe. Several possibilities exist. The file could be a shared memory file, a semaphore file, a named space entry, or a symbolically linked file. If the version of LONE-TAR you have was not compiled to handle symbolically linked files, this message appears when a symbolically linked file is encountered. As UNIX develops,new types of files may also develop. It is possible that special network implementations in the future will use special files. If your version of LONE-TAR is significantly out of date with the version of UNIX, it is possible that a new file type was added to the version of UNIX. This message may occur with an upgrade to a new operating system release because of the above reasoning. Also to be considered is the possibility of having a corrupt inode entry on the hard disk. This could make the type of the file unrecognizable.
This is generated when the -zDEV option is used to back up special raw device files. One of the devices specified in fact is not a character device. The raw device backup feature must use a character device. Keep in mind that the -zDEV option is available only with special versions of LONE-TAR.
If the filename already ends in a '.Z', 'z', '.zoo', '.zip' or '.arc', LONE-TAR assumes the file is in compressed format. Also any other suffixes that were specifically excluded using the COMP_EXCL environment variable are listed. If LONE-TAR tried to compress a previously compressed file the result would most probably be negative compression and a larger file. This feature can be used to advantage when one wants to make sure a certain file is not compressed.
While LONE-TAR was backing up the file, someone shortened it. LONE-TAR adjusts for this automatically. If the device is seeking, the shorter length is used. If the device is non-seeking, LONE-TAR fills in the dead space with nulls (zeros).
This file cannot be opened. The most common cause is the file does not have read permissions. This happens when LONE-TAR is used by a non-super-user. More rarely, a file has been removed by another user between the time LONE-TAR saw the file and started to open it for reading.
One of the virtual files specified in the list of virtual files could not be opened. Most commonly a space character was left on the trailing end of the filename in the list. Check the list, delete the name and then retype the name, being careful not to include any spaces. The list of virtual files is specified using the VIRTUAL_LIST environment variable.
There are two phases to a virtual file backup, scan phase and backup phase. The accessory program that is used to prepare the virtual file failed to scan the virtual file and produce a valid header. This may be due to corruption or it terminated prematurely. Try re-installing the package.
This informs you the virtual file was incompletely backed up. This usually results from the failure of the accessory program that removes the null data from the virtual file. This program is called /usr/lib/ltar/vback. It failed. Most often this is because the accessory program terminated prematurely or was killed by the super-user.
This is a serious error while backing up a virtual file. This represents a system error or error in communication between vback and LONE-TAR. The amount of data predicted in the scan phase does not match that actually received. Call for technical support.
The file specified by the VIRTUAL_LIST environment variable contains a filename that is misspelled. This file does not exist on the system or cannot be accessed due to permissions. Make sure the list does not contain trailing spaces or tabs after any of the names.
This can occur if there are not enough processes in the process table. Look at the reason given and make appropriate adjustments. Check to be sure /usr/lib/ltar/vback is executable.
This file is needed for virtual file backup and is not present. Reinstall LONE-TAR and try again.
This occurs when the file specified by the VIRTUAL_LIST environment variable does not exist or cannot be opened for reading. Check the permissions on this file and reset the VIRTUAL_LIST environment variable and try again. Alternatively, allocating memory for the internal virtual list structures can cause this problem.
This happens when the wrong k factor size is given in the command-line. For example, if you thought your tape took 40MB you might use a k factor of 40960. However, if your tape happened to be the one out of the group of tapes that was 5% shorter you would get this error. Experience has shown that the exact capacity of the tape may vary up to 10% of what is actually claimed. Additionally, even tapes with the same capacity will vary from one to another.
Two results are possible. If the word ``Recoverable'' appears, the backup is still good and you do not need to repeat it. LONE-TAR has ways of recognizing this situation and can recover. If this message is not present then the backup is bad. Either way, LONE-TAR suggests the proper value to use next time so that this won't happen again.
This warning message occurs when LONE-TAR is checking to see which directory you are in when LONE-TAR is invoked. This only occurs on Berkley systems where getcwd.o (get current working directory) is not part of the standard C library.
As LONE-TAR backs files up, it creates an internal map of what files are linked to other files. This map grows larger as the backup continues. The size of the map has exceeded memory limitations. The solution is to increase the memory allotted to a single process, manually decrease the number of linked files, or split the backup into two smaller backups of the same data.
These errors only appear in the small model compiled version of LONE-TAR. An error occurred reading a temporary file that holds the map of linked files. The reason is given. You can tell if your version of LONE-TAR is small model compiled by using the file command on the UNIX system. You can also use the hdr command.
This means that the {filename} specified had a number of links, but not all of the links were encountered during the backup. This results from a partial backup or backup that excludes some files or directories. The unresolved links were links to the excluded files or directories. This message only appears during a Master backup, an Incremental backup or when the l option modifier is used.
This occurs when the S option modifier is used for Double Buffering. LONE-TAR splits into two processes, but the child process was terminated. Usually, this is because of a kill command from the system administrator or another user.
During a compressed backup, LONE-TAR encountered a file on an NFS mounted filesystem that it did not have permission to backup. This often results from NFS mount options that map the ``root'' user-id to user-id ``other'' during remote file access. Check the options used on your NFS mount and remount so that root has full access to remote mounted NFS filesystems. Alternatively, you can exclude NFS mounted filesystems with the -E Readmounts option.
This message can accompany the previous error message. The file is stored as a zero size file on the tape.
LONE-TAR encountered a file on an NFS mounted filesystem that it did not have permission to backup. This often results from NFS mount options that map the ``root'' user-id to user-id ``other'' during remote file access. Check the options used on your NFS mount and remount so that root has full access to remote mounted NFS filesystems. Alternatively, you can exclude NFS mounted filesystems with the -E Readmounts option. This message with no other accompanying messages means the file was not backed up.
This message can accompany the previous error message when the file header has already been flushed out to tape. LONE-TAR has no choice but to fill in the file with zeroes for its full size.
This occurs when the X option is used to specify a list of files to exclude. The list could not be opened for reading and usually this is because the name is misspelled or permissions are inadequate. This message can also appear during a restore.

5.4.2 Warnings While Restoring or Verifying Data Back To Top

1. ERROR DURING VERIFICATION!!

This occurs at the end of a verification when the T option is used if errors were encountered. In most but not all cases the reason for the error can be determined by scanning the catalog file for the ``lone-tar:" identifier. Many times the verification required ERROR RECOVERY mode to get through some bad spots in the media.
This also shows up for any internal error at all. It is very precise so it is possible that minor errors that do not represent any change in the integrity of the data could result in this error.
This is self explanatory. You only get this message two times. After that, LONE-TAR assumes you know what you are doing and really want to restore the volumes out of order. It is possible that one volume of a set was damaged, and you need to restore out of order. So, this message can be overridden if you are persistent.
An error occurred while initiating the streaming decompress for this particular file. An attempt to create a stream with write permission failed. Check the permissions of the file being restored or re-invoke the restore with super-user power.
This message is given by the decompression part of LONE-TAR when asked to decompress a file that is really not in compressed format. LONE-TAR determines if a file is in compressed format by two tests.
a. The header block of the file signifies the file is compressed b. The first two bytes of the file have been stamped with a special value signifying the file is compressed.
This message occurs if you start restoring on a volume other than the first and you have a split compressed file across volumes. Even though the name and header indicate that the file is compressed, the first two bytes do not have the special value signifying compressed format. These two special bytes are on the first part of the split file.
Try putting a previous volume in to see if the file actually does start on the earlier volume.
Here %d represents an integer between 9 and 16. This file was compressed with a bit value larger than this version can handle. The larger the bit value used, the more memory consumed by the program. This can happen if you take a floppy disk that has compressed files in 13 bit format (most versions) and try to restore these to a machine where LONE-TAR was small model compiled (ALTOS). The small model version can only decompress files using 12 bits so you are out of luck.
An error occurred writing the decompressed data into the file on the hard disk. Most commonly this is because you have run out of space on the hard disk filesystem. Free some more space on the hard disk filesystem and try again. Occasionally, the error is due to a hard disk fault. This is a serious error and means the file was not restored properly.
This message only occurs on versions of LONE-TAR compiled by using a small memory model option. This is done for computers with an extremely small amount of memory. This is because the memory is so scarce that it is allocated when needed. You can try using a smaller block size (try 1) to free some more memory. This message is primarily of historical significance since the small memory model is not used anymore.
This means that as the file was decompressed, corrupt data was encountered and it could not be decompressed further. The file is restored up to the point where the corrupt data was encountered and then truncated. Usually there is minor corruption near the tail end of the restored file.
The cause of this is usually a hardware problem during the original backup or during the restore. Also, the media could have been corrupted by electromagnetic radiation after it was backed up. It is also possible on seeking devices, that parts of the media were overwritten by another program. Additionally, it could be that the media was backed up using an error-correcting device such as /dev/erct0 and yet restored using a non-error-correcting device such as /dev/rct0.
This is a ``tip-of-the-iceberg'' type of problem. There is probably widespread corruption on the tape media. Be aware of the fact that there is probably some corruption in non-compressed files that were restored during the same session. You should check out all restored files carefully, even if there were no error messages.
You should check to be sure you are using the same blocking factor, capacity, and device and try again. If problems are still encountered in the same spot, chances are you have a hardware problem with the tape drive or a media problem with the tape.
This only occurs on versions that support Virtual files. The accessory program that revirtualizes the file has failed. The file is incompletely restored. Please check that you have /usr/lib/ltar/vrestore on the system and that it has not been corrupted.
This only happens when revirtualizing virtual files. It means an internal error occurred. An internal buffer problem occurred and appropriate corrections were made to correct this problem. However, you should call technical support and review the circumstances leading to this problem.
These are informative messages printed out while restoring files to clarify why certain actions were not taken. They are all self explanatory.
LONE-TAR has tried to make the necessary path to restore a given pathname/filename. The attempt to make one directory in the path failed for the given reason. Thus, the file was not restored successfully.
This is printed when doing a restore to inform the user that the directory was not created because of the reason given.
A selective restore of a few files was performed and one of these was a linked file. The file that it is linked to, however, does not exist on the hard disk. Therefore, this file needs to be restored first. The restore should be retried and the file {filename} given should be included in the new list of files to be restored.
This happens if you are going from one filesystem to two filesystems and a regular link cannot be used because it spans across the two different filesystems. In this case, a symbolic link is conveniently used instead. In the restore summary, this file still shows as incompletely restored.
LONE-TAR attempted to restore the link and it failed because of the above reason. This most commonly occurs when you are taking files from a system with one large filesystem to a system with two or more filesystems. A link which linked two files on the same filesystem is attempted to be restored to a system that requires that the two files be in different filesystems. It is impossible for a regular link to span two filesystems so this fails.
This occurs when you are restoring an archive from another computer that supports symbolic links and trying to restore it to a computer that does not support symbolic links. In this case, a regular link was used instead of a symbolic link. and the restore summary shows this file as incompletely restored. This should alert you to look for the above WARNING message in the catalog file.
Similar to the above message except that a regular link could not be used. Most likely this is because the previous symbolic link was to files across different filesystems. LONE-TAR attempted to use a regular link instead but discovered that it could not be done because a regular link cannot span filesystems.
The binary version of LONE-TAR running does not internally support symbolic links. This is usually because the operating system under which it is running also does not support symbolic links. Therefore a regular link was made instead. This shows up in the restore summary as a file that was incompletely restored.
The binary version of LONE-TAR running does not internally support symbolic links. This is usually because the operating system under which LONE-TAR is running also does not support symbolic links. A regular link could not be made because the link would span across two different filesystems.
If, for whatever reason, a file that is split across multiple volumes is restored out of order, you receive this message. Sometimes it is desirable to do this. For example, if a file is split across several floppy disks, and one of the diskettes is severely damaged (or missing), you will want to restore what you can. If you answer n, the remainder of this file is skipped.
This message occurs when restoring files backed up on a DOS system with DOS-TARTM and restoring to a UNIX system. The DOS files (if they are text only files) are converted to the UNI format. All carriage-returns preceded by a linefeed are converted to linefeed alone. If you do not want any conversions done, you can use the -zNOCNVT option.
If the file is binary, you should not see this message. The decision to convert is made by inspecting the first 512 characters of the file. If there are non-ascii or non-printable characters the file is considered binary.
This occurs when you are restoring or listing and have already encountered and entered ERROR RECOVERY mode. LONE-TAR believes that you have reached the true end of the archive. However, if you are doing difficult error recovery work and need to list or obtain some valid TAR format files beyond this point (if they exist), you are given this option. In most cases, you would answer n to this question.
When this file was backed up, it was being compressed and encountered a bad spot on the hard drive. The file was clipped at the point where the bad spot was encountered. Therefore, when this file is restored, the length is shorter than the original and thus incomplete.
This means the very last chunk of data on the tape was shorter than expected. This results from using a block size on backup that is different than that on restore. If a tape is backed up with a block size of 64 and restored with a block size of 20, there will be 4 blocks left over at the end. This is called the short block.
This error is a warning only and does not affect the integrity of the restore or verification. You should take note, however, to correct the block size mismatch.
This can also mean that the block size is too large (1024 blocks) and is not supported properly by the tape driver in the operating system. Try lower values until this problem no longer occurs.
The end of the archive came unexpectedly. This could result from listing or restoring from an archive that was aborted during its creation. The offset number is the kilobytes into the tape where this occurred.

5.4.3 Warning on Starting Back To Top

1. Special '-z' option: "NOCNVT" - No conversion of DOS files

This means that throughout the restore, there is no DOS textmode conversion of any DOS text files.
A -z option was entered that is not in the list supported. Most likely the name of the option was misspelled. The spelling has to be exact, and getting upper-case and lower-case letters correct is important.
This confirms the correct use of the -zDEV option. This option is only available on special versions.
The -zDEV option was used to back up a raw device. The filename given, however, was not actually a character device so a raw partition backup could not be done. This is not fatal, but the file is not backed up. This option is only available on special versions.
This is repeated for each file or directory excluded on a restore. There is no distinction made between files or directories in this listing. If a backup is being done, this represents the directories that are excluded.
This is repeated for each file excluded during a backup.
This is repeated for each wild-card pattern excluded either during a backup or restore.
This confirms that Double buffering will be used. This message also appears in the catalog file.
This indicates that LONE-TAR believes it is running as a background task. The behavior of LONE-TAR is different and these differences can be reviewed in the LONE-TAR MAN PAGES under the section Background Operation on page 63.
The system ulimit needed to be increased to match the large capacity tape drive you are using.
An attempt was made to increase the ulimit but it failed. This occurs if the user is not the super-user. It is a warning that the backup may stop when the system ulimit is reached.
An attempt was made to obtain the system ulimit value. This attempt failed for the reason given.
This confirms that unenforced file locking will be used during the backup.
This confirms that enforced locking will be used during the backup. This means that each file backed up is guaranteed to be locked against writing before it is backed up.
An attempt was made to read the block size, device name, and capacity from either /etc/default/tar or /etc/default/tar and this could not be done. Either there is no permission to access the file or it is corrupt.
The capacity for this device number was set to zero. It needs to be set to a physical capacity in kilobytes. Although some versions of tar allow a capacity of 0, LONE-TAR does not because of compression constraints.

5.5 BACKUP SUMMARY MESSAGES Back To Top

1. ****> ERROR: %d File(s) NOT backed up!!

This means the specified number of files were not backed up. This could be for many reasons. The most common reason for a large number of files not being backed up is that the backup was done by an account other than super-user. Thus, only the files that person has privileges for can be backed up. Other reasons include inability to open a file (perhaps across an NFS network), a file not being found by that spelling of the name, the name of a file is greater than the maximum allowable LONE-TAR path length, inability to lock a file because enforced locking was used by another process, information about the file cannot be obtained (size, date, etc.), or the file type cannot be determined. The catalog file should be scanned for error messages starting with ``lone-tar:'' to determine the exact reason files could not be backed up.
This means that hardware errors were encountered during the backup. Specifically, there were defective data blocks encountered on the hard disk and the files involved were only partially backed up. Again, in this case, you should scan the catalog file for details of what happened and the names of the files involved.
This only appears in the catalog file and is the LONE-TAR exit code for the entire command. Any value other than zero means there was a problem. The exit codes (also referred to as the LONE-TAR diagnostic return codes) are within the range of 1-20 and 128-143. They are discussed in the section ERROR RETURN CODES on page 100 of this chapter.

5.6 RESTORE SUMMARY MESSAGES Back To Top

1. FILES successfully restored: %d

This represents the number of files that were successfully restored. This means that no errors were encountered during the restore.
This represents the number of files requested to be restored less the actual number that were restored. Check the spelling of the files that were not restored. You can see if a file by that spelling exists in the catalog file representing the original backup for that medium. Alternatively, you can list the entire contents of the medium using the tV option and then see if the file is listed by looking for it in the catalog file.
This represents the number of files that were incompletely restored. There are many reasons for this, including:
a. Incomplete decompression of a file due to corruption
b. Incomplete revirtualization of a virtual file
c. A regular link that spanned filesystems thus requiring symbolic link
d. A symbolic link (from another system) converted to a regular link
e. A regular file partially restored using ERROR RECOVERY

5.7 MISCELLANEOUS ERROR MESSAGES Back To Top

1. lone-tar: Running as background task and cannot get a reply

An attempt was made to look for a reply in the named pipe /dev/ltar_listen and this failed. Most commonly, it is because this named pipe is not present on the system. This usually occurs while crossing volumes. You can create it by using the command:
mknod /dev/ltar_listen p
If the named pipe is already present, check the access permissions since it is possible that the permissions on this named pipe are too restrictive.
An attempt was made to read from your terminal, but it could not be opened for reading. Check the access permissions of /dev/tty and make sure that it is a character device. In rare cases, it is possible that the standard input appears to be a terminal to the system but cannot be opened for reading. This message can appear when LONE-TAR is crossing volumes and trying to obtain the answer to the volume prompt message.
The device file /dev/tty could not be opened. Check the access permissions of this character device. If this message appears, you also need write access permission to this device.

5.8 DOUBLE BUFFERING ERROR MESSAGES Back To Top

1. Shminit: Failed to obtain segment: %d because {reason}

During the initialization phase for the S option, five shared-memory buffers are obtained. They are the size of the blocking factor specified by the b option. If there are already too many shared-memory buffers allocated in the system this will fail. Additionally, the size may exceed the maximum allowable shared-memory buffer size allowed for your system. You should run the ``ipcs -m -b'' command to see how many shared memory buffers are allocated and their size. If there are bogus shared-memory buffers, they can be removed using the ipcrm command. Bogus shared-memory buffers can accumulate if a process allocates a shared-memory buffer but never gives it back to the system. The shared-memory buffer will be permanently allocated even if the original process is no longer running.
It is then best to reboot the system and retry in single user mode. If this works, you know you have a resource problem and can probably retune the kernel. If this doesn't work try lowering the block size. If that works, you can again retune the kernel to allow larger chunks of shared-memory. The variable that is tuned is SHMMAX which is the maximum size in bytes of a shared-memory buffer. If neither of these works, it is probable that either your computer does not support shared-memory or it does not support the UNIX System V implementation of shared-memory.
Once the shared-memory buffers are allocated, they are attached to a given location in memory. There must be at least six allowable attachment sites per process. This is specified in the kernel tuning variable SHMSEG. Be sure SHMSEG is six or greater.
A small shared-memory segment of 4096 bytes is used for the master control segment. The same reasons apply for this failing as apply to obtaining the five shared-memory segments above.
Again, there must be at least six shared-memory segments allowable per process for attachment. Make sure SHMSEG is at least six or greater.

Main Navigation

Demo Downloads

Technical Articles

First to Market!

Watch instructional videos from:
- Smart phones
- YouTube.com
- Right here on Cactus.com