On Friday 13 May 2016 10:16:00 CN wrote: > On Fri, May 13, 2016, at 09:14 PM, to...@tuxteam.de wrote: > > Jessie/Sid here. But the more important thing is... what version of > > sysv-rc is yours? What update-rc.d are you using? > > "dpkg -l sysv-rc" show this from local host: > > ii sysv-rc 2.88dsf-41+deb7u1 > > "2.88dsf-59" from my VPS provider. > > How embarrasing! I spent quite a while trying to get your second > point, but to no avail. I am in the impression that there is only one > copy of globally accessible update-rc.d, which is exactly located in > /usr/sbin/, meaning that every time I type "update-rc.d" in shell, > this exact version /usr/sbin/update-rc.d gets executed. The only > special thing I notice is that it is a perl script. Am I missing > anything else? > > I do not know what I am doing. Regardless, I typed what you showed in > previous message: > > sha1sum /usr/sbin/update-rc.d > > and got this result which I have no idea of its meaning: > > 19d097b7dbe7f0d0a551e40e9183656f81908088 /usr/sbin/update-rc.d > That is exactly what you asked for, the sha1sum of the file update-rc.d.
Although this is rarely done, it has a several billion to one chance of being different IF you have modified ANYTHING in that perl script. But you would have had to do that as it was being installed, and recorded someplace so that you could do it again later to detect ANY CHANGE in that perl script, which would give you a different sha1sum. Since I doubt that you did that, the only use might be to post it as you have, so that others could compare theirs to yours. Indirectly, if several others get a different sha1sum that matches others, but is different from yours, then its time to compare version numbers. If everybody is running the same version number, but everyone else is getting a different sha1sum, yours stands a very good chance of being contaminated somehow. Bit rot on your hard drive would be slim because the hard drive itself keeps checksums and will re-read that data block until its good, and will usually put that good data into a spare sector, and will remap the spoiled sector to the newly allocated spare, all by itself. A 100,000/1 better chance would be that you've had it in an editor that noticed the last line wasn't terminated by a newline or linefeed and it added one. As some are fond of saying it doesn't mean squat, but the sha1sum goes BOOM in that event. But for the above comparison to work correctly, you (and everybody responding to your message) would have to post the version number of the parent package that held this file too. No use comparing apples to tangerines. :) > Best regards, > CN Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
