Hi Rafał,
On Sat, Oct 21, 2006 at 05:13:44PM +0200, [EMAIL PROTECTED] wrote:
> Max Vozeler wrote:
> > Can you please send /var/log/dpkg.log (ideally as bzip2) and tell me
> > roughly at which date you did this upgrade? Perhaps you can determine
> > the relevant entries from dpkg.log.
>
> Is this is important after information (see bellow) then let me know,
The log could still be useful to figure out why exactly the binary
was removed and not restored. If it's not much trouble, it would be
great if you could send it.
> > circumstances, but only if dpkg/apt got interrupted by power loss,
> > system shutdown/crash or kill (e.g. ctrl-c).
>
> Yes, this is the case, upgrade was interrupted few times. But after that
> it was left to finish all tasks normally - so I thought it will not be
> affected? Shouldn't apt be resist to such interrupting?
It certainly _should_ be able to recover. I've thought about the
different ways in which this could happen, but the only case I can
think of in which the current way of diverting mount et. al. could
fail is during the initial installation .. not during upgrade.
Could it be that one of the interruptions was a kind of system
crash, e.g. power loss or unclean shutdown?
Thinking aloud: In case loop-aes-utils gets upgraded, diversions
are already effective. This means dpkg operates directly on /bin/mount
in the way it normally does for non-diverted binaries, i.e.:
open("/bin/mount.dpkg-new", ..)
write(..)
link("/bin/mount", "/bin/mount.dpkg-tmp")
rename("/bin/mount.dpkg-new", "/bin/mount")
The rename() at the end is atomic, and should dpkg be interrupted
before, there would just be a leftover /bin/mount.dpkg-new and maybe
/bin/mount.dpkg-tmp. This is failsafe. I don't see how it could lead
to /bin/mount disappearing.
In case mount (the package) gets upgraded, the file operations are
redirected to /bin/mount.orig (the diverted to file). dpkg in this
case should never touch /bin/mount directly, but instead replace
/bin/mount.orig in the same atomic manner as above.
So, I wonder how the binary could end up disappearing during upgrade,
even in case of interrupted dpkg/apt. The only case I can think of
is that the system experienced a power loss or other unclean shutdown
while dpkg was running, and subsequent fsck removed the file.
cheers,
Max
