After spending the better part of a day trying to reinstall my neighbors computer using his old Windows XP Home disc (no service packs installed) and burning 4 slip-streamed discs - in an attempt to get the pesky nForce4 controller on the ECS motherboard to play nice – I finally got the system up and running again. Mind you, not using the custom Windows XP CD’s. No, for some reason after the slip-stream, the CD key is no longer accepted (thanks Microsoft for that one).
No, the reinstallation involved the slow and painful upgrade of Windows XP from the vanilla version to SP3 with every upgrade known to man. Of course this process failed once when I tried installing every driver and tool during eachothers installation (and probably during the service pack upgrade) so I wound up with a system which threw a BSOD on each boot and forced me to start all over again. *grmbl*
Now, after everything is up and running again, the only problem that remained was the fact that the SATA hard drive is showing up as a Removable disc. This is probably because the initial installation was using a legacy IDE emulation interface on the nForce4 controller. But as soon as I installed the SATA driver, the full 250GB became available (it showed up as a 128GB disc during the text mode setup) and Windows switched to the faster SATA interface.
My guess is that Windows for some reason now detects the SATA drive as a new drive and assumes for some reason that it is hot-swappable (it should be in theory but still should not show up as such). To fix this, you need to tell the nVidia drivers to stop marking SATA drives as removable. As such, the trick described below might not work if you do not have a nForce SATA controller.
WARNING: Messing with the registry can destroy your Windows installation. If you know what you are doing you should be fine, if not, please stop now.
- Go to ‘Start’
- Type ‘regedit’ and hit enter
- Find the following folder ‘HKEY_LOCAL_MACHINE\CurrentControlSet\Services\nvata’
- Some people might have a 64-bit installation, they should have a ‘nvata64’ folder instead
- On another computer of mine, the folder was called ‘nvatabus’ instead of ‘nvata’
- Create a new DWORD value in this folder (by right clicking and selecting ‘New DWORD value’)
- Name the new value ‘DisableRemovable’ and set the value to 1 (decimal or hex doesn’t matter)
- Close RegEdit and reboot your computer
If everything worked out, you should no longer see the hard disc showing up as a removable device. Don’t forget to reboot to make the changes active!
In a previous article I wrote about KBlogger and its nomination for a vapor-ware award. Most of the commits up until then seemed like KDE global search and replace changes, rather than actual work on the KBlogger application itself.
On the Kblogger page on kde-apps, an anouncement was made that the 3rd alpha was released in Febuari 2009. After installing and playing around for a bit, it felt more like a working blogging tool than it did before.
The downside was the numerous features which didn't work:
- Settings autodetection leaves you hanging and makes setting up a blog account more of a guess than anything else
- If kwallet is not installed or activated (the service needs to run), kblogger crashes
- If you try to read the category list on a Moveable Type API site, you get a 'Method not supported' error
- Reading previously posted articles works (sort of) unless you have media attached in which case it crashes
The biggest problem is not the continuous crashing of the application but rather that I haven't been able to post one article on any of my sites using Kblogger - it truely is an alpha quality application, if that.
It seems like the development is still going, even if the kde-apps page and homepage seem to be dead. Hopefully, they will work out the crashes and get it going in some form before KDE 4.3 ships out in June 2009.
Because of the current state this seems doubtful but according to the plans, it is still a part of KDE 4.3 PIM-libs - although it was on the schedule for 4.0, 4.1 and 4.2 as well.
In a desperate attempt to make the KDE 4.3 deadline, the current Kblogger feature plan seems to have dropped support for media management. This means that a lot of the current issues become a problem for later on and the core of the program (the blogging engine) is the only thing that needs to be fixed.
Lets hope this June we get a pleasant surprise but I am currently putting my money on KDE 4.4 or even KDE 4.5 as a release platform. On the bright side, perhaps the SVN versions become stable enough to use in the mean time.
On a side note, I am still looking for a blogging program for KDE :-)
Looking for instructions to get your latest Logitech webcam to work on linux? Your in the right place! Need a replacement for gspcav1 or spca5xx? Have no clue what I just said but you need a new webcam driver? Please, read on...
If you are running linux and have had the QuickCam Communicate STX for a while (like me) you would probably have started out with the GSPCAV1 package - from 2007.
2007 you ask? Yes, that piece of kit is antique and I couldn't get it to compile anymore on any modern kernel (which you pretty much should have if you are running Gentoo). Not surprisingly though, I was not the only one. Besides, a driver for a common camera should be updated more often and even better: it should be in the kernel tree.
Guess what? It is!
It sounds so simple but if nobody tells you how to upgrade from the gspcav1 driver to the new driver in the 2.6.27+ kernel tree - you'd be stuck, just like I was.
According to the page of the maintainer, pretty much all new Logitech and webcams from other producers work with the new gspcav driver. In my case, my Logitech identifies as 'ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX'.
- Find your camera on the driver list
- Grab a recent kernel (2.6.27+ will do)
- Remember the subdriver name that matches your webcam, mine is zc3xx.
- Configure your kernel:
- Device Drivers --->
- Multimedia devices --->
- <*> Video For Linux
- [*] Video capture adapters --->
- V4L USB devices --->
- <M> GSPCA based webcams --->
- <M> ZC3XX USB Camera Driver
- <M> GSPCA based webcams --->
- V4L USB devices --->
- Multimedia devices --->
- Device Drivers --->
- Decide whether you want it build in or as a module and compile the kernel
- Check using ' dmesg' after plugging in if it worked:
gspca: main v2.4.0 registered usbcore: registered new interface driver zc3xx zc3xx: registered usb 4-2.3: new full speed USB device using uhci_hcd and address 9 usb 4-2.3: configuration #1 chosen from 1 choice gspca: probing 046d:08d7 zc3xx: probe 2wr ov vga 0x0000 zc3xx: probe sensor -> 11 zc3xx: Find Sensor HV7131R(c) gspca: probe ok gspca: probing 046d:08d7 gspca: probing 046d:08d7
If you see a similar output to the above, everything *should* work.
But as always, there is a catch: if you use the latest Nvidia drivers (if you have an Nvidia card of course) you probably have no DGA support because it got dropped (something with DGA needing a static frame buffer address and dynamic memory management on a graphics card - whatever) ad when you try to run something like 'xawtv' you get a warning and only a black image.
This is xawtv-3.95, running on Linux/x86_64 (2.6.29-gentoo-r1) WARNING: v4l-conf is compiled without DGA support. /dev/video0 [v4l2]: no overlay support v4l-conf had some trouble, trying to continue anyway Warning: Cannot convert string "-*-ledfixed-medium-r-*--39-*-*-*-c-*-*-*" to type FontStruct no way to get: 384x288 32 bit TrueColor (LE: bgr-)
The reason for this is the fact that xawtv and some others try to get the data through the V4L interface which most of the time comes with a DGA display method... which doesn't work... which means your webcam is working but you can't see it...
This is silly ofcourse and luckely, players like mplayer can use the V4L2 interface as well which allows it to display the feed without a DGA interface. For example to test using V4L2 and mplayer type:
mplayer tv:// -tv driver=v4l2:width=352:height=288:device=/dev/video0 -fps 15
Have fun with your webcam on linux! ^^
After deciding to upgrade my Ubuntu Intrepid to Jaunty a million things broke – most of which were flimsy solutions at best – making me spend hours to figure out how to fix them.
One of those little gems is the LCD on my Antec Fusion case, or rather it is not an LCD but a VFD. Even better, SoundGraph is the original producer of these gems but seems to think that the entire IT industry is only using Windows as they don’t support linux. At all. Nice.
Of course, most of these devices work alike so if you figure out the guts of one you pretty much have the recipe for all of them. I had installed my HTPC over 6 months ago and after trying a million patches I finally ended up with a Lirc 0.8.3 installation with a patched lirc_imon driver which managed to drive the display as well as work with all the buttons, knobs and the remote.
Sure, I had to tweak the patch a little to get the right payload and replace semaphores with errrr…. something else, but who can complain when it finally works?
So after finding all the previously ‘helpful’ sites again, and people sending each other around in loops for instructions, I figured out what to do. Ignore all the guides out there. There you have it.
So, the instructions? Easy, LIRC 0.8.5 will have native support for the iMon devices and it already works better than any patch out there. Go to the LIRC website and follow the instructions to compile LIRC from CVS. As a hint, if you are running Ubuntu: as soon as you pulled in the CVS tree, run ‘./autogen.sh’ followed by ‘./configure --prefix=/usr –with-driver=imon’ and finally ‘make’ followed by ‘make install’.
Thats all there is to it, now load the lirc_imon driver and to test, configure LCDd to connect to ‘/dev/lcd0’ and behold, your GraphMon VFD works! Lets hope the fine folks at LIRC decide to push the next release out the door soon so everyone can just get the vanilla package from their distribution vendor.
I write a lot of code, most of it unsuitable for release to the public but this little gem is worth a public release.
After using Bacula to backup all my servers (both Windows and Linux) for some time, the large number of mailings you get when using it on a small server park drove me insane. Even when using filters to sort out new mail, it is hard to see if everything is going as it should be.
Enter Bacula Reports: a mail aggregator for Bacula 2.x and 3.x.
Bacula Reports consists of a faux mail command (which does not send out reports by mail but rather analyses and stores them) and a report generator which aggregates all the stored reports into one mailing with an overview and some HTML styling to make it more readable (if you don't want HTML, modify the template to generate plain text).
By integrating the scripts into the Bacula configuration at 2 points (a mail command used for sending out reports and a job to send out the combined report), the storm of daily mails changes into one neat report at the end of the backup cycle.
Normal error messages and operator messages are unaffected and will be delivered as they used to be, only the backup reports per job are redirected to Bacula Reports.
- A linux server (32 or 64 bit, tested on CentOS 5.2 and Gentoo 2008)
- A working Bacula 2.x or 3.x installation
- PHP as a command line interpreter (run ‘php –v’ to see if you have it)
- 10 minutes of your time to set everything up
The cool thing of the scripts is that they require only 2 small changes in the director configuration to reroute the status mailings and if you don’t like it or run into trouble, reverting is normally a matter of simply commenting out the modified lines and restoring the old ones.
One drawback for some people: it requires PHP on the command line (as stated before). The reason for this is very simple: I want to use the same code in the future for a web GUI and my unix-scripting skills are virtually non-existing compared to PHP or Java.
Even though its PHP, the scripts have a small footprint and run very fast – they should be easy to add to any existing Bacula environment.
|Bacula Reports Version:0.9|
|First public release of Bacula Reports version 0.9 - a tool to aggregate Bacula report mails into one daily overview.
|GNU/GPL 2009-04-21 English Linux 0 B 1468|
|Bacula Reports Readme Version:0.9|
|Release notes for Bacula Reports 0.9 including installation instructions and other information. Also included in the full download.
|GNU/GPL 2009-04-21 English Linux 7.08 KB 2868|