Yes, you can avoid backing up that location. If you start armory without it, it will regenerate the data from ~/.bitcoin/blocks and the contents of your Armory wallet, which is stored in ~/.armory/*.wallet

Thank you Carlton Banks,

SIGKILL is often caused by Linux's out-of-memory killer. Linux is saying "I'm out of memory, I'm gonna kill an application that I think is to blame", and in this case it guesses Armory, which is probably the correct one. Running dmesg should show that the "OOM" event. Maybe you can confirm?

The second crash is definitely our fault, but it's hard to tell what's causing it.

0.93 should fix this, if for no other reason that so much of that code is now totally different.

I'll test for the suspend scenario there.

Provide log files.

Yes, that is the case for Windows XP, online support. It was a consideration, but if you're using Windows XP, the machine is either pretty old and will be really slow for use with an online wallet, or you could just install a more recent windows if you want to use it online, which is a good idea since you'll then want security fixes from Microsoft.

Armory 0.93 requires a 64 bit OS in online mode. I can't imagine a workaround existing. the RPi is 32-bit.

try rescanning, from the help menu.

There is a bug that has to do with the databases and how they set the file location.
 
In your log file this line tells me that you are experiencing this problem:

def SetBlkFileLocation(self, *args): return _CppBlockUtils.BlockDataManager_LevelDB_SetBlkFileLocation(self, *args) TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'

To correct this, you will need to simply modify how Armory starts the program.
 
Please start Armory with --satoshi-datadir="/home/yourownhomedirectory/.bitcoin/"  where "/home/yourownhomedirectory/.bitcoin" should be replaced with YOUR own home directory.

A little birdie told me that you can use https://counterwallet.io/ to create transactions and view your balance of Armory offline wallets, without ever revealing your private keys.

Go to the Help menu, choose "Rebuild and Rescan Database". And be prepared to wait a while.

That usually fixes this problem.

Whether they use BDB or LevelDB is not relevant because those blk files are not BDB or LevelDB files, so indeed that does not make a difference.

That their headers have a different format does make a difference (and I would not be surprised if they started using merged mining at the time of when your patched Armory failed).

In order to support their slightly different block format, you'll need to modify the class BlockHeader. I would recommend, for the time being, not bother making a program that supports both bitcoin and namecoin without recompiling.

It's hexdump that is exchanging the order of each pair of bytes. Give it the option -C

Open up a hex editor on that file, go to that byte offset, and see if there's anything unusual.

You got so far into the the file (229714131 bytes) that it makes me think maybe the file itself is corrupt. Try blowing away namecoind data and download its blockchain again?

But conversely, you got it in the testnet as well, so that seems unlikely.

You cannot get an instance of BlockDataManager_LevelDB from anywhere, anymore. But anywhere that calls getBlkFilename has an instance of BlockDataManagerConfig available.

I recommend you put a boolean in in BlockDataManagerConfig that sets things to namecoin mode, and then check that boolean wherever getBlkFilename is called, and maybe write a new function, or use etotheipi's old version and modify its parameters based on that.

Hi Joseph,

The short answer is "you don't". The useful answer is that Armory loads the C++ side from BDM.py. There it creates a BlockDataManagerConfig object. When you create a BlockDataManagerConfig, you could specify parameters there that affect the C++ side's behavior, like the file format convention for blk files.

You're developing against the "dev" branch, right? You should.

the current dev branch supports headers first, it is being tested. The next release of armory will officially support headersfirst. Nothing to worry about!

There's little reason to put Armory's (or bitcoin-qt's) blockchain on SSD or have it encrypted from a cost-benefit point of view.

This is fine for dpkg. You install all the debs that are interesting even though you get dependency errors, and then apt will install them all once you've tried to install all the packages necessary to satisfy the dependencies, with apt-get -f install

in addition to what goatpig wrote, can you give us the output of `echo $OPT`