I found the camera in the end - after four odd days searching - I must be going mad 🙁
It turned out to be in the pocket of a fleece I dont remember wearing at the bottom of the washing pile that I swear I hadnt touched for two weeks.
Our cloaks were even on top of it - must be fairies or practical jokers or my mind going - somehting like that 🙁
Anyway I am not happy as now the house is a complete mess again as I was so desperate that I pulled everything out of cupboards looking for the damn thing!
Power had returned when we came back:
Mar 5 19:18:42 anger upsmon[703]: UPS powermust@localhost on battery
Mar 5 19:22:02 anger upsmon[703]: UPS powermust@localhost battery is low
Mar 5 19:22:02 anger upsd[718]: Client monuser@127.0.0.1 set FSD on UPS [powermust]
Mar 5 19:22:02 anger upsmon[703]: Executing automatic power-fail shutdown
Mar 5 19:22:02 anger upsmon[703]: Auto logout and shutdown proceeding
[...]
Mar 6 18:54:33 anger syslogd: restart
Mar 6 18:54:33 anger /netbsd: NetBSD 3.0 (ANGER) #2: Sun Feb 4 19:20:11 GMT 2007
The day's work can now begin... I can run the computers or the ADSL router off of the generator, but due to cabling limitations, not the computers and the Internet connection.
Bah. Our power failed at 7:30pm last night (the 5th of March) and has yet to resume at the time of writing (11:30am on the 6th of March).
The house is festooned with extension leads, since we're running the fridge and freezers from the generator, with another spur over to the ADSL router zone. I'm typing this on my laptop, hooked up to the router with a patch cord, since I don't have enough extension cables to get the switches going to get Internet access to the office...
About to go out and fill up our fuel cans...
Speaking of unearthing bugs, I'm surprised I've not found any mention of anyone fuzz testing NetBSD syscalls. There's a crashme tool which, despite the one-line summary doesn't actually call syscalls explicitly (although it may stumble across them at random) - it just executes arbitrary sequences of random numbers as code, in order to make sure all the CPU trap handlers work correctly...
So I may throw together a tool to do that for syscalls. Needless to say, it ought to be run as an isolated user (so it can only trash its own files), maybe in a chroot, and ideally on a machine without network access (for it could, in theory, open a network socket and do something unneighbourly :-).
This would be a good test of the higher-level inter-process isolation facilities in the OS kernel - namely, it'd help to find security holes such as local denial of service attacks against the kernel!
Also, another fun idea might be a fuzz tester for Xen hypercalls...