Re: broken system after srm -r -d /tmp/.* (user login and several services not working)
On 02/07/2008 Ron Johnson wrote:
> No flames, but "thanks!" for the informative post.
> A reboot cleanly clears out /tmp, so ISTM that the way to accomplish
> your ultimate goal is to run sfill soon after boot.
Yes, you're correct. ;-)
Thanks for the suggestion, will use that next time. Should have
considered that earlier, then I wouldn't have all the trouble now.
In the meanwhile, I had a new idea:
Maybe srm doesn't remove the overwritten files before quitting when it
is aborted. That way, some file on my system could still exist, but in a
truncated way: half of the file is still the orignal, the other half is
overwritten by srm.
If that would be the case, dpkg would not replace it with a new version
even when invoked with 'option --force-confmiss', correct? And debsums
would save the new md5sum of the truncated file in it's db.
I should have invoked debsums just after my accident, now it's maybe to
late. Nevertheless I tried it, but no success:
# debsums -as
debsums: checksum mismatch debsecan file /etc/default/debsecan
debsums: checksum mismatch grub-pc file /etc/default/grub
debsums: checksum mismatch nessusd file /etc/nessus/nessusd.conf
debsums: checksum mismatch openssh-client file /etc/ssh/ssh_config
debsums: checksum mismatch openvpn file /etc/default/openvpn
debsums: checksum mismatch pbuilder file /etc/pbuilderrc
debsums: checksum mismatch procps file /etc/sysctl.conf
debsums: checksum mismatch schroot file /etc/schroot/mount-defaults
debsums: checksum mismatch schroot file /etc/schroot/schroot.conf
debsums: checksum mismatch syslog-ng file /etc/syslog-ng/syslog-ng.conf
these are just the config files that I changed manually, so these
results are perfectly valid.
Too bad, I've no more ideas about how to go on. Any suggestions?