I've been trying to backup my ubuntu11.04 with the following tar command
sudo tar -cvpzf /media/TOSHIBA\ EXT/backup.tar.gz --exclude=/backup.tar.gz --exclude=/lost+found --exclude=/proc --exclude=/sys --exclude=/mnt --exclude=/media --exclude=/dev --exclude=/home/manuzhang/Music --exclude=/home/manuzhang/Videos --exclude=/home/manuzhang/Pictures --exclude=/home/.aMule /
every time there is such a failure message
tar: Exiting with failure status due to previous errors <br/>
the procedure exited when packaging the directory /sbin several times. Finally I exclude it, but it exited in /root
So what caused the problem?
Anyone has similar experiences?
Many thanks!
The error `"Exiting with failure status due to previous errors" means exactly that. There was an earlier problem which, while not fatal to the running of the program, is reason enough to exit with a failure code.
Given that you're backing up from the root level, this is almost certainly because a file is not able to be backed up for some reason.
Leave off the verbose flag -v and you should hopefully be able to see the problem better.
Related
We are using OPUS Make in our build infrastructure. (Basically traditional make with some wrappers around I guess)
Our codebase is mostly Java and I have been making changes and building for many months now. No issues.
Suddenly, a couple of days back, when I tried to build,i started seeing this error:
OPUS MAKE: Unknown status. Stop.
I see this error no matter what I try to build. More imp - it looks like it is not even trying to actually compile my code and for some reason just stops before with the above error.
I tried doing a clean build. Even manually cleaned up all old generated build files. Still did not work.
I even tried restarting my environment itself. Restarted Clearcase. Still no use.
I see there is a way to build with debug information. Did that also make -d
However, that did not give any useful info either. Just the same line as above. I was hoping that it would give some debug logs or some error code that I could use to solve the problem.
I see there is an option: make -n. That comes out clean. But from the name, it looks like it does not even attempt to run the build itself.
Please suggest what the issue could be.
thx - Om
"Unknown status" means that a shell command in a target returned a status that make did not understand. Run with -d to see which command is failing. And debug that shell command.
I wrote a Singularity container that works just fine on my computer. However, when a colleague of mine tries to run it, he gets the error output
FATAL: container creation failed: failed to resolve session directory /usr/local/var/singularity/mnt/session: lstat /usr/local/var: no such file or directory
In the past, he could run containers I build. In fact, he used being able to run a container with the same recipe. The change was that the version of Singularity on the machine I use to build it was upgraded.
I entered the error in a search engine, and I only found a single hit, https://forum.image.sc/t/improving-cluster-supercomputer-performance-tesla-v100-volta-16-32gb-gpu/37459/8, in which this is not resolved.
Does anybody know a way to fix this? Or what the source of the problem is? Or a workaround, preferably one that does not require me to downgrade Singularity? (The machine on which I build it is shared between several users, that's why I don't want to do that.)
Okay, this was somewhat trivial to solve, we just had the colleague create the required folder,
mkdir -p /usr/local/var/singularity/mnt/{container,final,overlay,session}
My file system went read-only. After reading this answer I ran dmesg | grep "EXT4-fs error" to see if I have any issues related to the filesystem / journaling system itself.
It returned many times:
[68241.757233] EXT4-fs error (device vda): htree_dirblock_to_tree:892: inode #533953: block 2108070: comm updatedb.mlocat: bad entry in directory: rec_len is smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0
What should I do?
I rebooted ubuntu, it asked me if I want to solve some problems, I said yes and it did solve them.
I moved my script to a new server with almost identical configuration (apache/centos) but the cgi-bin has been failing to work ever since. For past one week I have googled every possible solution and isolated the error by executing script from command line. Output i get is as follows for a simple test file:
[root /var/foo/public_html/cgi-bin]# perl -dd /var/foo/public_html/cgi-bin/test.cgi
Loading DB routines from perl5db.pl version 1.32
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(/var/foo/public_html/cgi-bin/test.cgi:2):
2: print "Content-type: text/plain\n\n";
Unknown error
Compilation failed in require at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63.
at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63
Term::ReadLine::Perl::new('Term::ReadLine', 'perldb', 'GLOB(0x18ac160)', 'GLOB(0x182ce68)') called at /usr/share/perl5/perl5db.pl line 6073
DB::setterm called at /usr/share/perl5/perl5db.pl line 2237
DB::DB called at /var/foo/public_html/cgi-bin/test.cgi line 2
Attempt to reload Term/ReadLine/readline.pm aborted.
Compilation failed in require at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63.
END failed--call queue aborted at /var/foo/public_html/cgi-bin/test.cgi line 63.
at /var/foo/public_html/cgi-bin/test.cgi line 63
[root /var/foo/public_html/cgi-bin]#
The code of the test file I am using is:
#!/usr/local/bin/perl
print "Content-type: text/plain\n\n";
print "testing...\n";
I have checked the path to perl, perl version etc etc and everything seems to be ok. However the script is not exceuting and gives a 500 internal server error. I am running php5 with dso handler and susEXEC on. susEXEC logs does not say anything except that the cgi script has been called. This problem is completely baffling me and my little experience with cgi/perl is not helping. Can anyone point me in a right direction to solve this?
As someone commented already check the permissions and also try to run the file from the console.
A likely problem is that when you switched servers the path to perl changed and your shebang line is wrong. A common technique to avoid this is to use #!/usr/bin/env perl instead.
When you recieve a 500 error apache should also log something in the error log (your vhost config might define a custom error log instead the default one so check that if you're having trouble finding the error message.
Also there is no reason to run your script under the Perl Debugger, unless your goal is to experiment with the Perl Debugger (and with no variable defined it is pointless as an example). My advice is don't use the Perl Debugger. A lot of experienced Perl programmers, (probably a big majority) never or rarely use it.
I solved this eventually, posting it for the sake of posterity:
On moving server I mounted the filesystem on a different partition as the home partition ran out of memory. I forgot to give exec permissions to the new mountpoint, that's why the cgi scripts were not executing.
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.