Hardware problems
Due to electricity work this morning, Diana has been switched off nicely – to prevent possible problems on startup. Just a few minutes, not to bother about too much.
Well, so I thought, but it turned out that the whole excersise in getting everyting back online was a very, very different matter: to put it simple: Diana refused to come alive. power on was no problem but in the line of starting, everything froze. I’ve had the problem before and cycling power several times usually helped, but not today.
So I had to boot another Alpha off the system disk. The easiest – and probably fastest – way was to take the AlphaServer 400 – it has 160 Mb internal memory, and carries an EV4 processor running at only 233 Mz – slow, compared to the Personal Workstation but it should do for DHCP, DNS, basic mail (including PMAS – the spam filter) and the basic, static webpages. After having replaced some cards – including the one that connects to the Shared SCSI bus, I booted this machine minimal, changed some startup files to prevent starting unneeded stuff, and restarted. It hung – but interrupting on the console and boot worked. The system started nicely, though slow. Once running I could disable the links to the blogs and the wiki in the page header – I had to extract the data from the library, change it and put it back in – and could create a text file to show.
The system ran nicely for a couple of hours, I could finish the job I was working on,, examione what was wrong with the Personal Workstation (now I had DNS, I could access the Internet 🙂 ) , and after that, I tried to retrieve my mail.
I shouldn’t have done that.
For some reason, the AlphaServer froze. Login to the AlphaServer failed – only CTRL-P worked. I initiated a system crash but that didn’t finish – and the SRM dumped it’s contents. Something I’ve seen happening when booting the box on shared SCSI when the PWS already booted from it.
At that time, I had been working finding out what went wrong in the PWS. The documentation I could find showed the problem was related to memory. At some point, the PWS beeped: once, three times, three times. The doc stated: there is no memory, or if there is, something made it unavailable. Re-seating the DIMMs seemed to help, but it took several attempts to have the system come up without a problem.
Once the AS400 got stuck, I added a KZPSA card – seemed to be required to get the Shared SCSI to life. But the console has some trouble with it, the startup sequence mentioned an error at test E6: Command error 4; and error happened after test E4 as well: SIMPORT failed.
So back to KZPBA – one left so put that is. Hooking it up the shared SCSI however didn’t work. For one reason or the other, this card didn’t notice the disks. Perhaps the wrong SCSI-Id? Changed that, to no avail. Finally, I re=installed the original cards in the PWS and the AS400 – hooked them up to the system and rebooted the PWS: And all seems well, at the moment.
The lesson: It’s time to get a newer box. Power off the PWS may become a nasty problem – once down, it may not come back again. But for now , it works.
Database trouble
I found this error in the database log:
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
081108 22:25:14 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 3274, file name ./mysql-bin.000013
081108 22:25:23 InnoDB: Started; log sequence number 0 502105172
081108 22:25:23 [Note] Recovering after a crash using mysql-bin
081108 22:25:23 [Note] Starting crash recovery...
081108 22:25:23 [Note] Crash recovery finished.
081108 22:25:25 [ERROR] Column count of mysql.db is wrong. Expected 22, found 15. The table is probably corrupted
081108 22:25:25 [ERROR] mysql.user has no `Event_priv` column at position 29
081108 22:25:25 [ERROR] Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
081108 22:25:25 [Note] /$116$DKA100/000000/WEB/MYSQL/MYSQL051/VMS/bin/mysqld.exe: ready for connections.
Version: '5.1.23-rc-log' socket: '' port: 3306 Source distribution
and yet, everyting seems fine. I asked JEan-François about this, he suggested to do a check – it might be the result of the known problem with MyISAM – used by the MySQL engine itself. By mysqlcheck didn’t reveal anything worng. All tablwe were fine. But I might have missed something in upgrading the database, so that’s what I’ll do next – after making a backup 🙂
Update
It looks like it all worked, the conversion is done and all seems to be present. Here, at least. And a number of columns have been added to table mysql.db. Now time to restart MySQL and seen what the logfiles says:
$ type mysql051_root:[mysql_server]MYSQLD.LOG
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
081116 22:32:07 InnoDB: Started; log sequence number 0 579383835
081116 22:32:08 [Note] Event Scheduler: Loaded 0 events
081116 22:32:08 [Note] /$116$DKA100/000000/WEB/MYSQL/MYSQL051/VMS/bin/mysqld.exe: ready for connections.
Version: '5.1.23-rc-log' socket: '' port: 3306 Source distribution
081116 22:32:08 [Note] Event Scheduler: scheduler thread started with id 1
$
I guess that’s more like it should be.