## System Maintenance Today, Downtime

I take the somewhat unusual approach, Of hosting this Web-site, and therefore also my blog, on my personal computer at home. Therefore, any downtime of my home computer, also affects the visibility of the blog. And, as long as the actual Web-server is not online, I also cannot make it display a maintenance-mode page.

Just in recent days, I took the more-unusual step, of running the command:


root@Phoenix:/home/dirk# update-initramfs -u -k 3.18.0-14-generic




root@Phoenix:/home/dirk# update-initramfs -u -k 3.16.0-4-amd64



While it seemed nice for some time, to be running a kernel-version named ‘3.18.0-14-generic’, the mainstream version which a Debian / Jessie system is supposed to be running, is ‘3.16.0-4-amd64′. So, while the mainstream kernel had been receiving regular updates, I was running a kernel, which had not been receiving any updates, for years now. This helped reduce the number of reboots which I needed to carry out, due to frequent updates on the ‘3.16.0’ kernel.

But just because this was the first time in ages, that I had run the ‘update-initramfs’ command on the running kernel, I next needed to attempt a reboot, just to see whether the computer could still boot.

Therefore, readers would have experienced problems accessing my blog or site, from about 16h40 until about 17h10 today.

And No, My system Failed to Reboot.

## Plausible does not mean Assumed

I could make hypothetical guesses, as to why crashes like this one happen, on the machine I name ‘Phoenix’, which was manufactured in 2008. This time I noticed, that the cursor on the screen stopped moving, then that mouse-input was not being interpreted, then that the screen just filled with an image, which was a diagonally-scrambled version of the normal screen content:

• It could be that the old GPU is no longer reliable at the hardware level, and that it may now suffer from random crashes, which also crash the X-server. The “” (‘‘) feature I have seen the nVidia Driver execute properly in past situations, may just not kick in.
• When I reinstalled, replacing the old 32-bit O/S with the current 64-bit O/S, I also replaced the 2GB of RAM with completely new, 4GB of RAM, and the “” (‘‘) of the new RAM has also become faster, that becoming 800MHz instead of the earlier 600MHz. Either set of DDR RAM modules was running with dual-channel capability. The motherboard may detect this capability of the new RAM modules and start using it, as the motherboard itself may have the stated capability of running at 800MHz. Yet, at 800MHz, the way this Motherboard works may not be stable.
• There could be some sort of kernel issue…

What I do find a bit more specific, is the fact that there seem to be no log entries for the , suggesting that although an X-server crash eventually takes place, this may not be the root cause. Also, the fact that the mouse has become unresponsive for a few seconds, before screen-content collapses, seems to suggest the same thing…

But the most important fact for me to observe, is that simply being able to suggest plausible reasons for the crash, is not the same thing as having diagnosed the crashes. Honestly, I do not know at present, why this type of crash happens.

One of the observations about this machine which had impressed me in the past, was that I had pushed 3D rendering beyond the limits of the old GPU, thereby crashing this graphics chip, but that the desktop manager I had in place was able to restart the GPU, and to resume the session, without requiring any action from me, but displaying a well-behaved message to the effect that the GPU needed to be rebooted. This is called “” (‘‘), and does the same thing under Linux, that it does under Windows, and depends on stable graphics drivers.

The fact that I do possess ‘‘ on this machine suggests, that a simple failure of the graphics chip, should not take out my session.