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
What was unusual about this, was the fact that this was not the command:
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.
I suppose that I should go into further detail.
Normally, it’s safe to run this command. The command builds or rebuilds a compressed file, which will be loaded as any given kernel’s Init-RAM-Disk, in the initial boot-stage. As long as we don’t change the configuration of boot-time libraries or files, running this command will just reincorporate these files into the RAM-FS. Sometimes we might be making small changes, that don’t affect the overall stability much. But this is what each kernel ‘sees as its data’, when it first boots.
I was faced with three simultaneous problems today:
- It was never a sure-fire success, for the X-server to start, even before I gave this command.
- With the 3.18.0 kernel, too much time had elapsed, since the ‘update-initramfs’ command was given, as the follow-up to any specific kernel-update. Performing this command after several years, was too much of a shock, to the configuration. Too many specific files could have changed in the meantime, not only the detail which I had meant to change.
- The 3.18.0 kernel had not been maintained for too long, to keep it up-to-date with ‘other code’.
And so the only way I was able to reboot the computer and get the X-server to start, was into the ‘3.16.0’ kernel. This is why the testing-procedure took so long. The test had revealed, what I did not want it to reveal, and I’ll next be looking to get rid of the ‘3.18.0’ kernel, since that one can be regarded as defective by now.
What this also means, is that my readers will unfortunately be witness to more-frequent reboots in the future, as kernel ‘3.16.0’ receives the next updates.
To be sure, I also recompiled the specific configuration-change I had meant to commit, into the Init-RD of kernel ‘3.16.0’ , but this kernel took it fine.