Re: update-rc.d creates unexpected sequence numbers
On Friday 13 May 2016 10:16:00 CN wrote:
> On Fri, May 13, 2016, at 09:14 PM, tomas@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>
Reply to: