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… )
When K3b does its system-check, it not only verifies the existence of the back-end programs, but also gives each program a kind of query-run, to determine what its capabilities are, before accepting the program as installed-and-set-up.
Under Debian, users must belong to the group ‘cdrom’, to be allowed to burn disks. This is akin to how, under Kubuntu, users must belong to the ‘burning’ group, in order to be allowed to burn disks.
I know that on my own computers, my main user-name belongs to the ‘cdrom’ group. But each of these computers has just received a kernel-update, that was written in a hurry, in order to patch a famous vulnerability. And a possible kernel-bug which might have been introduced, could be some sort of laxity, in attributing each user to belonging to all the groups in fact, which he belongs to.
If this were correct for Debian / Jessie, then at least I wouldn’t be losing my hard-drive…
(Edit 1/16/2018 : )
But there is a reason to doubt, that this really explains the error message. These are the permission and ownership-bits, of ‘cdrdao’ on my system, because it’s a Debian and not a Kubuntu system:
dirk@Phoenix:~$ cd /usr/bin dirk@Phoenix:/usr/bin$ ls -l cdrdao -rwxr-xr-x 1 root root 649288 May 12 2013 cdrdao dirk@Phoenix:/usr/bin$
What this means is that, on my system, any user should at least be able to run ‘cdrdao’, regardless of whether he or she belongs to the group ‘cdrom’ or not. The latter membership will only control, whether the user can in fact connect to my burner or not:
dirk@Phoenix:/usr/bin$ cd /dev dirk@Phoenix:/dev$ ls -l sr0 brw-rw----+ 1 root cdrom 11, 0 Jan 15 21:04 sr0 dirk@Phoenix:/dev$
So according to first-order logic, any user should be able to get K3b started, regardless of whether he’ll actually be able to burn disks or not.