I use a home-computer as my Web-host, which I named ‘Phoenix’. This was actually a computer built in 2008, and is one of the oldest still working for me. So far it has continued to work reliably.
Until several years ago, this computer was actually named ‘Thunderbox’, and was running Kanotix / Thorhammer. But I when I wiped it completely and installed Kanotix / Spitfire on it, I not only renamed it, but rebuilt its software from zero.
What just happened to me today on ‘Phoenix’, is that I fired up a routine K3b -session, in order to back up some music from Audio CDs which I had actually purchased in the 1980s, and that the GUI application showed me a message saying that it could not locate the utility named ‘dvd+rw-tools’ ; I should try installing the package (even though it’s a dependency and was installed.) After I reinstalled that package, K3b told me that it could not locate ‘cdrdao’ (even though it’s a dependency and was installed). I needed to reinstall that as well, after which I explicitly needed to tell K3b to rescan the hard-drive, to find all its back-end utilities again.
Because on this computer I had never customized the back-end utilities which K3b uses – unlike what I had done on ‘Klystron’ – and, because I had never changed the variables in question, this actually points to file-system corruption. I had last used K3b on ‘Phoenix’ several months ago, and with no error messages or warnings. Further, those utilities were among the first packages I ever installed, when I resurrected this computer as ‘Phoenix’, and the idea that the oldest data on the hard drive, would be the first data forgotten, even though never deleted, is also consistent with file-system corruption.
Usually, I’d expect FS corruption to stem from power outages. But we haven’t had a power-outage in a long time, and the last time we did, the Extension 4 File-System on the machine just seemed to repair itself correctly. Because Ext4 is such a tightly-meshed file-system, the report that it has been repaired, can be believed. If it was not repaired on boot, the computer would refuse to boot.
And so, even though this is not typical, I’d say that in this case, the FS corruption is actually secondary, to the fact that the actual Hard-Drive is aging, and has caused some I/O errors. We only get to see I/O error messages, if we’re running something from the command-line; I believe that when we’re running a GUI application, those just stay buried in a system log somewhere.
But what this seems to spell, is that eventually – sooner than later – ‘Phoenix’ will die completely, and this time, there will be no resurrecting her, because the problem will be in the hardware and not in the software.
(Update 1/16/2018 : But. there’s another possible explanation… )