Linux

This cured things for blank windows with the Zend Studio IDE and Business Accountz both of which I use daily!

The only one minor thing it didn't quite pull off was getting the attached usb hard drive back in action - a quick unplug and replug later and it's sorted.

This is quite cool, however I'm just in the middle of downloading another kernel update and I hope that keeps the progress made with suspend and resume on this laptop.

So the simple solution is to get the VMware init script to check for and re-create the nodes as required:

Add the following just under the start) line in /etc/init.d/vmware

   start)
# Start insert
      if [ ! -e "/dev/vmmon" ]; then
         mknod /dev/vmmon c 10 165
         chmod 600 /dev/vmmon
      fi
      for a in `seq 0 9`; do
         if [ ! -e "/dev/vmnet$a" ]; then
            mknod /dev/vmnet$a c 119 $a
            chmod 600 /dev/vmnet$a
         fi
      done
# End insert
      if [ -e "$vmware_etc_dir"/not_configured ]; then

Which recreates the nodes that are required - just need VMware to pick that up for future versions. Remember, you'll still need to re-run vmware-config.pl after a kernel upgrade.

The other symptom I noticed was that dbus-monitor or anything else that connected to dbus session would fail with a 'connection refused' message.

After trawling round the net, I found a Redhat Bugzilla posting that resolved the issue - between FC4 and FC5 the location of dbus-daemon had moved from /usr/bin to /bin (and also dbus-cleanup-sockets). The yum upgrade for the dbus packages had not removed the FC4 versions from /usr/bin so a quick rm /usr/bin/dbus-daemon and rm /usr/bin/dbus-cleanup-sockets followed by a reboot sorted the problem altogether.

Perhaps that should be added to the Yum upgrade FAQ on Fedora wiki. Another small but annoying problem resolved

Firstly I checked with the bank - "At the moment, we can't transfer account information to popular accounting packages or spreadsheets. Although we haven't got a definite date for introducing this facility, it has been scheduled for inclusion in our Online service and we'll let you know as soon as it's available."

I'm not the sort of person to be foiled by that sort of response so embarked upon working out a reliable import routine - especially as the online statement is just an HTML table which can be imported into most spreadsheets with ease.

Grisbi supports the QIF format for importing data as well as a few others, so that was my target format. I came across a macro for Open Office Calc (there's also a similar macro for Excel) that exports to the QIF format. So I tried a simple save of the transaction history of my online statement as an html file. This I then opened into oocalc and the transactions were imported, a few row and column deletes later to clean up the un-needed elements and I was left with a list of transactions ready to export.

After a little playing about with the CALC2QIF macro, I was able to get the columns sorted to the order that Grisbi expected (I actually did this using a new sheet, pulling in the data I wanted from the online source). A quick save to qif format later and import into Gribsi and I soon had 2 years worth of banking history imported, acurately too - there were no missing transactions - Brilliant!

So just thought I'd share that to encourage others to circumvent the brick wall that is the bank and do it the underground (but reliable) way - link a few tools together - enjoy.

Same problem, anything to do with rpm resulted in a segfault. Oh dear, or similar sentiments thinks I, best check what's going on elsewhere on the system - all seemed fine as usual, still got web server, mail etc.

I tried digging around in yum, rpm and message logs - nothing of any interest, so I remembered that you can do a rpm rebuilddb as detailed on rpm's site however, that also failed with a segfault so it was obviously something a little more serious, but at least now I'd backed up the /var/lib/rpm directory which I'd need later.

This stumped me for a while, so I started looking at a lower level using 'strace -f rpm' to see where things failed - always at the same point just after loading /lib64/tls/libc.so.6 - so I uploaded, did I mention this machine is remote, a replacement copy of the underlying libc-2.3.4.so and rsync'd it into place - no change rpm still segfaulting. After pondering, googling, trawling and no enlightenment later, I headed over to the nice folks at #rpm on irc.freenode.net, who were initially equally puzzled. Then, jbj (I think), mentioned about using rpm2cpio.sh - a shell script to unpack an rpm file when rpm is not installed / working etc. - which I'd obviously not spotted before.

So here's how it was fixed - so I don't forget, and because it may be of some use to someone else : Continue reading "Segmentation fault using RPM"

I tried several things, many hours of web searching, even looked in on #fedora on irc.freenode.net but nothing seemed to work until I re-read the the Gentoo wiki Kernel Configuration entry. Re-reading that prompted me to remove all the kernel parameters I'd used since FC4 on my machine, as the 2.6.16 kernel used in FC5 seems to have fixed all the problems that were seen on this laptop previously. It certainly cured the lock up problems!

FC4 kernel parameters that I'd used (as advised in various places on the net, including the gentoo wiki previously):



Using those parameters on FC5 caused the machine hangs, so the gentoo forums saved the day, my machine is now stable again.

There's at least one other very nice by product of the FC5 upgrade - the new kernel allows the synaptics touch pad to operate properly. Under FC4, the touch pad missed some of the clicks from the mouse keys, this was really annoying especially when trying to drag thngs around as it would take several attempts to e.g. grab a window to move it. This seems to have been completely addressed now, no more ending up with emails in the wrong folders!