As a follow-up to this test yesterday, I just performed a reboot of the home-computer that acts as my Web-server, and that I name ‘Phoenix’ on my LAN. Unlike how it was yesterday, the reboot took place effortlessly tonight, requiring less than 5 minutes to complete, and undertaken around 21h20.
Again, my purpose was just to determine, whether a reboot would work, and again, there was a plausible reason why it might not have. Luckily, this one worked on the first try.
The reason for which this reboot might have failed, would have been the fact that yesterday, I ripped out kernel 3.18.0 using the package-manager. This is actually not the best way to remove one kernel, because the package manager will perform removal, and then post-removal steps, out-of-sequence. I.e., the package-manager will first remove the actual kernel headers, and then try to recompile the DKMS modules, and then try to update the initramfs of the kernel that is being removed, and then remove the kernel again…
I could say that the end-result is the same, in that one kernel’s files will have been removed completely. But if I said that and really meant it, then suddenly I’d be an optimist.
After the package-manager removed the kernel in question, I needed to recreate the symlinks ‘/vmlinuz’ and ‘/initrd.img’ manually, because the kernel I chose to remove, happened to be the one with the higher of two versions, leaving me with kernel 3.16.0 in good working order.
And then, as root, I ran the command ‘update-grub’ manually (before attempting any reboot).
Hence, rather than really testing whether the system can presently boot into its only kernel, I was testing, whether the GRUB would display correctly, after having been updated, and it just did. (“Grand Unified Bootloader”)