Equipment/Babbage/LogBook: Difference between revisions

From London Hackspace Wiki
No edit summary
No edit summary
Line 1: Line 1:
=== 21/09/2012 Artag ===
03:40 < samthetechie> hey all, sorry for the babbage reset
03:40 < samthetechie> was cleaning / tidying and I nudged the power out
03:40 < samthetechie> :(
03:40 < samthetechie> (I think it reset... there was a plume of dust...
=== 25/03/2012 Jasper ===
=== 25/03/2012 Jasper ===



Revision as of 07:57, 21 September 2012

21/09/2012 Artag

03:40 < samthetechie> hey all, sorry for the babbage reset 03:40 < samthetechie> was cleaning / tidying and I nudged the power out 03:40 < samthetechie> :( 03:40 < samthetechie> (I think it reset... there was a plume of dust...

25/03/2012 Jasper

Added Sol's HP LaserJet CP1025, which needed the latest version of foo2zjs. See /root/printer-stuff for more details.

--JasperWallace 19:15, 27 March 2012 (UTC)

13/10/2011 Mark

Babbage hadn't responded since last night. Jasper checked and found it was stuck on a BIOS screen (probably the SCSI one that says "press F1 to continue"). No idea why it restarted (apparently around 2011-10-12 17:50).

27/4/2011 Mark

Shut down Babbage to install new USB card due to repeated issues with bus overpowering.

  • Shut down at 19:52:32. Uptime was 42 days.
  • After opening, decided to hoover the inside as it had picked up a huge amount of dust
  • Babbage only has one 5v PCI socket, which was being used by the video capture card for the door camera. After a quick chat with Jasper, we decided it would be best to get a USB capture device instead, in return for more USB sockets.
  • Restarted at 20:17:08.
  • On restarting, no F1 message was required, although it flashed up "unbootable system drive" (or similar) monentarily before booting off the hard disk.
  • Service init stopped for about 10 minutes after starting Mysql daemon. I'm not sure whether this is normal. I could log in without any problem on tty2 and access the network. The next service to start was gpm. I wonder whether this was due to the he-6in4 tunnel.
  • Plugging the printer in still caused errors (device descriptor read/64, error -71), but replacing the cable fixed this.
  • The light on the front is no longer flashing orange, which is nice.
  • I've restarted all the services I can in screen:
    • All the doorbot-listeners are in one session
    • camtemp.single.py is in the same session as netcamfix
  • I've disabled thread 3 on motion (the door camera) until we get a replacement
  • I've left ~ms7821/screen.txt with the previous list of screen sessions for root
  • I've disabled the 6in4 tunnel for now (as it should move to Church)
  • I've stopped bind9 from starting up automatically (because resolvconf notices it, and points to localhost)

Other things noticed:

  • mrchrisadams has his HereNow daemon still running off cron.
  • All the startup stuff should be run off init or cron.
  • Boarded needs to have its ports tied with udev.
  • It looks like this is not a high-speed hub. We can put cameras on the built-in hub, but we should try to find a faster one if possible.
  • sysv-rc is in legacy mode (/etc/init.d/.legacy-bootordering).

People who had screen session PIDs:

  • solexious/record
  • aether
  • samthetechie
  • SamLR


27/4/2011 Artag

There were two tftp servers running, or attempting to run. Between them they were using about 50% of the CPU writing messages such as

Apr 27 20:31:40 babbage atftpd[1610]: bind: Cannot assign requested address
Apr 27 20:31:40 babbage atftpd[1610]: recvmsg: Socket operation on non-socket
Apr 27 20:31:40 babbage atftpd[1610]: bind: Cannot assign requested address
Apr 27 20:31:40 babbage atftpd[1610]: recvmsg: Socket operation on non-socket

There seems to be no need for either at the moment, so I disabled tftpd manually in /etc/inetd.conf, and disabled atftpd with 'update-rc.d -n atftpd disable'

If you need one running, please choose one or the other...

25/2/2011 Note by Ciemon

5 packages can be updated. 4 updates are security updates.

The following packages will be upgraded:

 linux-headers-2.6.31-22 linux-headers-2.6.31-22-generic linux-image-2.6.31-22-generic linux-libc-dev tzdata

The kernel upgrades will need a reboot after the upgrade, so upgrade aborted for now until the reboot procedure is defined.

The upgrade procedure is currently DON'T unless it's absolutely necessary, and you've checked with people it affects (especially IRC).
The reboot procedure is DON'T unless it's already completely broken. Ms7821 00:55, 26 February 2011 (UTC)