Import HSBC transaction data into moneyplex

After a lot of trial and error, the following settings allow one to import the transaction data into moneyplex. Any other settings would no import the date information correctly.

  1. Log in to your HSBC online banking and export the transaction data in the “Quicken (QIF)” format.
  2. In the moneyplex programme (the website is in German, and so is my installation. I am unsure whether it exists in the English language) you choose the account into which you want to import the data.
  3. Go to the transaction screen, right click onto the list of transactions and choose “Import” from the selection menu.
  4. Choose the format “QIF-Import von Intuit Quicken 2001 bis 2003 (US-Version)” as the import filter.

This should import the transaction data correctly. At the moment only the recent transactions seem to import successfully from the HSBC website. This is a major pain. Let us hope, that the English banking system can adopt a common standard for the import and export of financial data some time soon. After all, Germany has had this for a while now.

Resizing the filesystem on an encrypted logical volume ontop of a software RAID

Warning: This is not a tutorial. It is just a story that explains a problem and provides the solution.

I had a few “D’oh!”-*slap your forehead* moments today when I increased the size of my data volume, and since I didn’t find any good information on some of the issues during my google searches, here is a short blog-post to commemorate the occasion and help fellow users.

I am using lvm, linux’s logical volume manager on this machine, and one of the volume groups (vg) sits on a software raid /dev/md0 that used to span 3 physical hard disk drives and which I now increased to span those three drives and an additional partition on a 4th drive. This is not ideal, however the three old drives are each of the same type and 750GB in size, whereas the new one is a single 1TB drive of a different make. To buy the same 750GB drive again would be more expensive then to buy a new drive with more than 1TB capacity, and I had one of those spare. So, I partitioned the 1TB drive into a 750GB partition and an additional partition for misc. purpose. The 750GB partition was then added to the software raid. This was no problem, and after additing the 750GB partition as a spare device, I extended the raid to span 4 active devices (3 HDD + 1 partition).

At this point, the raid had additional space, but I could not yet use it.
If I wasn’t using lvm, I could have just grown the size of my file system partition to cover the additional space available on the raid device (/dev/md0). Since I am, however, using lvm, the device to resize is the lvm volume group that covers the raid device, in my case that is “dat” i.e. /dev/dat/.

Calling vgdisplay as root before and after you extend the vg, should show you that the available free space in the volume group increased.

Once the volume group is grown to cover the whole of /dev/md0 using the “vgextend” command, the additional space may be attributed to any logical volume in that volume group, in my case /dev/dat/data. Use

lvextend -l +100%FREE /dev/yourvg/yourlv 

command to increase the size of yourlv to cover all the free space in the volume group.

Now I had a logical volume with 2.05TB of space, but in Nautilus it only showed 1.4TB as before. This is where, unlike previously, I got stuck. On the web they talked about resizing your file system, which in my case sits in a logical volume, that sits in the volume group, that sits in the raid device. However, when I tried to resize the filesystem, I got the following error message:

resize2fs -p /dev/mapper/dat-data
resize2fs 1.42.4 (12-June-2012)
resize2fs: Device or resource busy while trying to open /dev/mapper/dat-data
Couldn't find valid filesystem superblock.

You see that I did not make the mistake of calling resize2fs on the /dev/dat/data, which is the logical volume, but instead I called it (correctly I think) on the file structure inside, accessable through /dev/mapper/. Unmounting the data volume did not help, and I could not find a helpful post online about this problem either.

Ultimately, the “Couldn’t find valid filesystem…” message made me realise that since I was using an encrypted logical volume, my filestystem is in fact mapped under /dev/mapper/cr_data. With this epiphany, it was no problem to call e2fsck and resize2fs on /dev/mapper/cr_data after which the additional space was available in my file manager.

INKredible also credible.

When I was looking for new ink cartridges last night, I found the website and they had a really good price against a very promising looking set of replacement cartridges. Unfortunately, when I got to the checkout stage, my SSL-Blacklist Extension in Firefox warned me about a connection based on md5 which is not deemed secure any more. I dropped them a ticket explaining the situation and within less than 24 hours they had re-issued their certificate and notified me of the changes. Since I had been unwilling to spend more money on a similar product somewhere else, I promptly went and bought the set of cartridges I had had in mind before. I love good customer service, I am sure we all do, and so I thought I put this little praise out there. Maybe it will help other people make a more informed decision, who knows.