atreus running again

For unknown reasons the first power cycle did nothing, ie left it down. Second one today fixed that. There are a few things I'm trying to improve uptime; there may be further downtime if I need to do anything drastic, but hopefully things will be better overall.

Unscheduled downtime

atreus is down again, suggesting a hardware problem. The ISP should reboot it fairly promptly, and I'll investigate further to try to figure out what's causing this :-(

Reboot completed

See MOTD for where we are now.

Scheduled reboot

Atreus will be rebooted in about ten minutes.

Service restored

atreus is back. I'm working to prevent future downtime.

Further downtime

atreus is currently unreachable, presumably down with another kernel reboot. This should be resolved tomorrow with a simple reboot by an ISP engineer. I will then prioritise moving to the 3.x series kernel that Debian now ships with in the hope that will fix whatever is ailing at the moment…

Service restored

atreus has been rebooted and should be running normally. If any services have not restarted, please let me know (even if you can start them manually via userv or similar) so I can fix problems in the boot sequence.

atreus downtime

atreus is currently down. I suspect this was a kernel panic or something similar; the ISP will reboot it Monday (to avoid ridiculous out of office charges) and it should come back up smoothly at that point.

Upgraded to 7.1: remaining problems should be notified to me

Basically, we're done. If you spot problems, please let me know.

Upgrade largely complete

dovecot is going to need hammering back into shape, but everything else should be okay. Let me know if not…

Kernel upgrade held back

Our /boot is…tiny. It probably made sense when Martin did the sizing on install back under (I think) the 2.4 series kernel, but it's not big enough to contain two 2.6+ kernels and the initrd with MODULES=most.

Accordingly I'm holding back the kernel upgrade, and doing the rest of the system (which shouldn't depend on it). I've generated an initrd for our 2.6 kernel with MODULES=dep, which looks largely sane, but I don't want to install the 3.2 series kernel until I've had a chance to research a little more and convince myself it's found the modules we actually care about. Once I've done that, and probably rebooted for good measure, we should be able to move up to the 3.2 kernel, assuming it can do a dependency scan off a 2.6 kernel; I may have to do some work by hand to ensure the early user space has access to the 3ware RAID controller and its file systems.

Main upgrade now going ahead.

Atreus upgrade to Debian 7.1

This is now underway, starting with some tests of the old system, then a minimal upgrade, followed by the full upgrade. There will be a number of reboots, which I will try to announce (`wall` to logged-in users) before I do them.

Ongoing information as it happens…

Debian squeeze: remaining upgrade steps

These will take a while (an hour to download the packages; and unknown time to actually upgrade them). So services may come and go over the next few hours. However we're highly unlikely to see system downtime from now on (there are no scheduled reboots, and we're now running a stock Debian kernel). I'll post again here, and update /etc/motd & /info/new once the upgrade is complete.

Reboot succeeded; next stage started

The reboot took longer than expected; the next stage is to upgrade the rest of the system, initially piece by piece and then everything else all at once.

Some services will disappear during this time (indeed, some are probably missing now), and will be fixed on completion of the upgrade.

Server reboot, possible problems

Predictably, the more recent Debian kernel doesn't seem to actually be working. I'm submitting a request to the hosting provider to get console access and figure out what's going on.

Atreus upgrade to Debian 6.0

This is now underway, starting with a minimal upgrade, then a kernel switch. I'm hoping that the new stock Debian kernel will Just Work (it sounds credible, at least), in which case possibly the only significant downtime will be if the RAID controller decides to verify the RAID set. If that happens, there'll be a 2+ hour downtime while it does that; if not it should be more like a few minutes.

Ongoing information as it happens…