search for: dumpped

Hi, I have a CentOS 4.1 (with a two hdds RAID 1 using mdadm) running some database system.... I connected a DLT device on its SCSI interface (/dev/nst0) in order to make some external backup..... I dump several filesystems (/, /boot /usr /var /home and others)....so and when I try to dump manualy for expmple /boot I get this: [root at Server ~]# dump -0vuf /dev/nst0 /boot DUMP: Date of this

I have and old dump format backup done under fedora 7 which is stored on disk and has an sha256sum file that indicates there are no data errors in the backup file.? When I try to read the file with restore under CentOS 6,? I get the following error: cat /etc/redhat-release CentOS release 6.10 (Final) restore tvf u1_l0_04-29-09_md1.dump Verify tape and initialize maps Input is from a local

On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote: > I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks.

Martin, thanks for the good news and sorry for wasting your (and others time) by not doing my homework and query bugzilla first (lesson learned! ). I have tested the new implementation from R-devel and observe a semantic difference when playing with the parameters: # Test script 1 g <- "global" f <- function(p) { l <- "local" dump.frames() }

Dear R friends, to allow post-mortem debugging In my Rscript based batch jobs I use tryCatch( <R expression>, error = function(e) { dump.frames(to.file = TRUE) }) to write the called frames into a dump file. This is similar to the method recommended in the "Writing R extensions" manual in section 4.2 Debugging R code (page 96):

> Hi, Simon > > >Two things: > > > >1. I''m not convinced ''xm crash'' is needed - ''xm destroy'' will do this > >(and if you want > > a dump, do ''xm dump'' followed by ''xm destroy'') > > > What do you mean? > I think we cannot dump with "xm destroy" now. >

Hi, In the case of linux, crash_kexec() is occured by "sysrq c". In the case of DomainU on xen, Help is occured by "sysrq c" now. So The way of dumping DomainU''s memory manualy is nothing. I fix this issue by the following way. 1. Panic is occured by "sysrq c" on both Domain0 and DomainU. 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).

Hi, I am finding that my project that previously successfully built with versions 3.5 to 4.0 is now failing to link because of missing implementation for dump(). Errors I get are: Undefined symbols for architecture x86_64: "llvm::Type::dump() const", referenced from: ravi::LuaLLVMTypes::dump() in ravi_llvmtypes.cpp.o dump_content(lua_State*) in ravi_llvmluaapi.cpp.o

Two things: 1. I''m not convinced ''xm crash'' is needed - ''xm destroy'' will do this (and if you want a dump, do ''xm dump'' followed by ''xm destroy'') 2. I don''t see the point of the --noreboot option on ''xm dump'' -- I think this command should simply live-dump the specified domain - as

> > restore tvf u1_l0_04-29-09_md1.dump Verify tape and initialize maps > Input is from a local file/pipe > Checksum error 20311110402, inode 0 file (null) > restore: Tape is not a dump tape what does 'file' think the file is - i.e. what does file u1_l0_04-29-09_md1.dump say? > > > Here's a log file from when the backup was done back in 2009: > >

This should have gone here and not to #706233. Patch will obviously need rebasing by now... ----- Forwarded message from Ian Campbell <ijc at hellion.org.uk> ----- Date: Fri, 16 Aug 2013 14:56:49 +0100 From: Ian Campbell <ijc at hellion.org.uk> To: 706233 at bugs.debian.org Cc: control at bugs.debian.org Subject: move core dumps to /var/lib/xen/dump X-Spam-Status: No, score=-4.9

I am trying to parse LLVM IR from a bit code file. I went through the following steps. hello.cpp #include <iostream> int main() { std::cout << "Hello world!" << "\n"; return 0;} dump.cpp #include <llvm/IR/Module.h>#include <llvm/IRReader/IRReader.h>#include <llvm/IR/LLVMContext.h>#include <llvm/Support/SourceMgr.h> using

tags 706233 +patch thanks This is somewhat more FHS compliant IMHO. commit 7d171826bc97bf5f3f2019fc32c1ca85b49de7c9 Author: Ian Campbell <ijc at hellion.org.uk> Date: Fri Aug 16 14:54:42 2013 +0100 * debian/patches/tools-core-dump-dir.patch: Switch tools to dumping to /var/log/xen/dump by default. * debian/xen-utils-common.dirs: Ensure /var/lib/xen/dump is created *

Hi, I would like to get a clear picture on external snapshots memory dump ( i.e. system-checkpoint) vs dumping the memory of the guest. I have created external snapshots which produces a disk file and a memory file. I am not able to use this memory file in any memory analysis tools, for instance volatility. However, the memory dump taken through "virsh dump" works just fine with such

So I recently installed an Overland Arcvault 12 tape library on a server to back up /var/log/ and /home. The server is an out-of-box RHEL 5 install, with all packages selected, in an isolated lan, with no package updates. Also, this is a live server that cannot be brought down for backups, and some files may be actively in use during the dump - just gotta live with it. Since I know EL5 and

On 11/3/18 3:26 AM, Pete Biggs wrote: >> restore tvf u1_l0_04-29-09_md1.dump Verify tape and initialize maps >> Input is from a local file/pipe >> Checksum error 20311110402, inode 0 file (null) >> restore: Tape is not a dump tape > what does 'file' think the file is - i.e. what does > > file u1_l0_04-29-09_md1.dump u1_l0_04-29-09_md1.dump:?? data

I have a cron job that calls a shell script - the script invokes dump. I'd like to do two things: - Have the script dump the results of the job to a text file. I tried this with /path/to/dump my switches -v >> /home/me/dump.log But that just produced an empty file. - Have the dump file be date-stamped with the date it was executed. Right now, I manually edit the script to change

I'm using the dump command to pass data to WinBUGS/OpenBUGS/JAGS and have run into a problem. Here is some R-code: foo <- array(1:6, dim=c(2,3)) dump('foo', file='dumpdata.R') dump('foo', file='dumpdata.R', append=TRUE, evaluate=TRUE) foo2 <- array(c(2,3,5,7,9,7,5,3), dim=c(2,4)) dump('foo2', file='dumpdata.R', append=TRUE) And here is

I have a couple C5 systems I want to back up. My plan is to, one way or another, back them up to a C5 machine in my office. I have samba installed on the systems to back up, the machines are mounted on the system in my office, and a tape library hanging of the system in my office. I was hoping to perform a simple /sbin/dump of the remote systems. I put together a script for another

Hi Martin, On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Are you building a Debug or Release version of the compiler? It seems that in Release builds of LLVM 5.0 the dump() implementation is absent, although the method is available in the interface. This is plain wrong in my view. If the dump() has to be removed then it should not be present