Great!

Not so great to be on the same spot an hour later.
I don't know how accurate that node progress percentage is but if 169113 is the 72% of blocks that you have to go, then 100% would be #234879 which can't be right. I could be making a huge math fail too!

Going to refresh my memory on a Win10 VM but this has made me think: how have you got Armory & Bitcoin Core set up to work together? Are you starting Bitcoin Core, leaving it open and then starting Armory? Or have you been closing Bitcoin Core?
In Armory under File > Settings is "Let Armory run Bitcoin Core/bitcoind in the background" checked or unchecked?

Definitely this one and this time uncheck "This is a test recovery to make sure my backup works."

I understand your worry. If it helps, whatever lengths that the tech had to go through to send you your coins cease to apply once the coins are in your wallet/at your new address. From your info about the address starting with a 1, I can tell you that your coins are in a normal P2PKH Address, which is the easiest to recover to any other wallet if it comes to that (but you've not mentioned any problems with your online PC/watching-only wallet).

I'll lay out the process before you commit to it - nice to not go in blind:
After you click "Continue" on the first "Restore wallet from Backup" step, you input your paper backup as you did before to test.
When you hit "Restore" on this step you'll get three options: Cancel, Merge and Overwrite.
I would say that "Merge" is the option you want. My understanding is that it'll retain existing information and fix whatever is wrong with your wallet (if anything) and will allow you to choose a new password.
After that it'll take a short while to recreate the wallet. Since you're doing this on your offline PC you won't have the long step of rescanning the blocks for transactions.

Armory made a backup of the actual wallet file for me as part of this process when I tried it out on my test wallet.
Make a note of the ID that is listed next to the wallet in the main Armory view.
The backup appeared in a timestamped subfolder in this directory:
I haven't actually tested that this file worked, but it seems logical.

If you're still worried you can choose to manually create a copy of the existing wallet files beforehand like so:
Close Armory entirely.
Go to
And copy every file that has the walletID in the name to another location on your offline PC.

Great, definitely fine for space, but good to know.

Worth checking where Core has got to in the sync process too. From the Bitcoin Core client go to Help > Debug Window > Information.
In Core 0.18 this was moved to the Window menu. So Window > Information.
Check that the value next to "Current number of blocks" is greater than 579853.

Yes but Core 0.18 and Armory 0.96.5 do play nice together, thankfully. Core 0.17.1 would be fine too if you wanted to avoid the latest release still.
There definitely have been some compatibility issues in the past and probably more if you were on a really old version (such as Armory 0.93)

Good luck. There will likely be more steps after that but it helps to fix the simplest things first. If I've not explained something clearly enough don't be afraid to ask

Some quick questions:
Any reason you can't run Bitcoin Core 0.18?
Has Bitcoin core actually synced fully? Block 180043 is from 2012.
Quite unlikely given it is a new laptop, but you're not running out of space on the hard drive, are you?

Armory does not use a BIP32/39/44 seed like many common wallets do. This will not work.

Great to hear that the paper backup is valid! Restoring your backup on the offline machine will not adversely affect your watch-only wallet on the online machine.
Which four options are you unsure of, specifically?
The options regarding paper backup version? 1.35, 1.35a, 1.35c? If so, your wallet version should be on your printed backup near the top.

You should be able to manually type in the path to the external drive for those options, rather than use the dropdown.
I'm not familiar with how Mac mounts these things, but a quick search suggests under /Volumes/your-drive ?
Fair warning external drives aren't ideal. If it is only USB2 capable you're probably in for a hellish experience 

Definitely stick with running bitcoin-qt yourself, not having Armory run bitcoind. You will want to config bitcoin-qt to run RPC in this case too.
In my experience, ArmoryDB not exiting gracefully usually means either the scanning isn't finished or ArmoryDB is choking on some part of the blockchain.
In those rare cases where Armory rescans have failed like that I've had to reindex the blockchain in bitcoin-qt, which isn't exactly fast.
Before you do anything like that, please post your logs files (via pastebin or similar)
armorylog.txt and dbLog.txt are probably the most useful. They will contain paths that have your username in them - feel free to find/replace the username.

The wallet you have imported the key(s) into: I assume you have set the wallet owner to be "yours"? That'd only affect the transactions and overall balance, not the value next to the individual wallet.
If yes, then definitely provide log files as goatpig requested.

Ha! I got enough of a taste of the requirements when I was digging for information and trying to understand the tools. When multiarch packaging was described as self inflicted pain, by the docs themselves, I did my best to avoid it!

https://github.com/goatpig/BitcoinArmory/pull/587
Hope it is okay, or at least a good starting point.

Many hours later and I now know a lot more about debian packaging and dpkg-buildpackage than I ever wanted to.
I have something that compiles with light changes to make_deb_package.py and the debian/rules. Autotools config untouched.
I'm assuming you're not planning on submitting this to the Raspbian/Debian repo? I set the bar at getting it working, rather the rabbit hole of debian multiarch packaging requirements!

As you found out... the Ubuntu release won't work: The Pi uses an entirely different processor architecture to a normal pc.

I can provide a build but frankly you shouldn't trust it. If you ask goatpig very nicely he might compile an up to date and official build for Raspberry Pi - it has been a while since we had one but you could be waiting a while longer.

Unfortunately you'll likely need to compile it yourself, ideally on a more powerful box than a Pi.
https://github.com/goatpig/BitcoinArmory/tree/master/r-pi

You're welcome. I'm surprised that alone made a difference but I'm glad it did.
Hope it remains problem free for you from now on.

Thanks for the logs. Definitely odd that the dblog is that short.
I just realised that nobody has asked which version of Bitcoin Core are you running. Please make sure you do have the latest version (0.16.3) https://bitcoincore.org/en/download/
If it wasn't 0.16.3, it could be helpful to know which version you had installed.

My best guess is still that the Armory database has gotten corrupted somehow.
Relatively easy fix to try, but will take time to rebuild.
Make sure Armory isn't running. If you can, check for ArmoryDB.exe in task manager's processes, and if it is there end it.

Press the Windows Key & the R key together. You'll get a popup to "Run". Enter this into the box (exactly as it is) and hit OK:
The Armory datadir folder should open and inside will be a lot of files including your logs and wallet files. Leave those alone, but there should be a "databases" folder there.
You want to delete the just "databases" folder (and anything in it).

You could reboot your PC at this point for good measure if you're not sure if Armory might be running still.
Start up Armory once this is done. It should start the process of building & scanning again. Fingers crossed that once it rebuilds you'll be connected and up to date.

As you're learning the hard way that isn't a good idea. -reindex is what you wanted, but hindsight is 20:20.
Unfortunately you're going to need to sit through that until Core finishes. Going on my testnet trial run that will be doing a proper reindex.

Shouldn't be much technical magic to it - just a text file and either you've copy/pasted it all or not
Generic path to that file is or in your specific case

Thanks for the definition. You'd perhaps be surprised by the proportion of people that land here while still using 0.96.0 from the old Armory website, often claiming the "latest" version. I seem to remember ArmoryDB.exe crashing out like that with earlier versions, hence the question

Given that you've been presumably been wiping the database when retrying the Armory rebuild we'd need to see full log files (sanitise usernames & post them on pastebin or similar). Or you could take a chance on getting bitcoin core to "-reindex" and check your blocks for any corruption. ArmoryDB is choking on something - segfaults are usually a lot earlier on so my guess is some bad blocks.

"Latest" isn't helpful, sadly. You want to be on Armory 0.96.4 and BC 0.16.3 - are you?

Thanks for doing that - logs look more sane now. Keep the satoshi param there (or move to the config file). Try Armory's Help > Rebuild and Rescan Databases but note that it will take a while as it is rebuilding from scratch.
If you'd like a better diagnosis before doing the rebuild posting your dblog.txt would be helpful. Check you haven't got any duplicate processes running too: one bitcoind, one ArmoryDB (and make sure it isn't running before you launch ArmoryQt).

The bitcoind that is getting fired up by Armory is looking in the wrong place, then. I'd suspect one of the many similar parameters is getting mixed up here given that Armory is trying to find bitcoind in your satoshi-datadir (i.e. blockchain folder).

Unclear to me, but are you planning to fire up bitcoind manually yourself (or via services etc.) or let Armory spawn it as needed? You say already running... so leaning to the former you'd want to uncheck the "Let Armory run Bitcoin Core/bitcoind in the background" option.

At least initially I think you should pass in as an argument or as a config option in armoryqt.conf (won't exist by default)
A fresh log after that would help

Running bitcoind in the background - Note that Armory says connected, but 0 blocks - confirmed in the logs.

@truebits
Going on the last entry in your logs, it was still scanning the blocks at this point:
If I'm reading it right, you kept everything running overnight then exported the log?

Assuming Bitcoin Core is fully synced, ArmoryDB might be choking on some corrupt data... though there is or was something strange going on with the 2bW2mnkwH wallet.
I'd guess an Armory database rebuild, and failing that a reindex in Bitcoin Core. Running Bitcoin Core separately from Armory would be worth a shot too, but needs a little configuration to work.