Some binaries not replaced by 'pkg install -f' #1394
Comments
|
I was running today into the same issue by upgrading postfix on some systems to a new current version. And a bunch of files where not replaced during the upgrade During the second try postfix was not running, but old files where also not replaced. |
|
@dumbbell is seeing this too: https://gist.github.com/dumbbell/1de188226b7dc652f124 |
|
This is a longstanding feature in the code -- pkg(8) will not touch a file where the checksum doesn't match what it has in its database. The idea being that the admin had overwritten some package files deliberately and pkg(8) didn't want to wipe out those changes. You can see the logic there, but this doesn't make sense in all circumstances:
At the moment, the only way to clear mismatched checksums is to remember to run 'pkg check -r ...' before trying to upgrade. There's no early warning that you're going to run into this problem, and once you see the error occurring there's no way to force pkg(8) to ignore the mismatched checksums and install the files anyway. Or to clean up the extra copies of file it leaves laying about. Ideally the solution would be to have a full rollback capability (to avoid the accidental breakage), and change the default to always do a clean install of a package. I think any admin deliberately overwriting package files is sailing close to the anyhow (and maybe should investigate pkg-lock(8)). Plus maybe overload 'pkg install -f' or 'pkg upgrade -f' to force overwriting files irrespective of their current checksum. |
|
On conflicts resolution step (or just after), we could check files checksums as well. The only question is the cost of such an operation. For large files, we could have not a single checksum but a chain of checksums to detect issues early. We could also check mtime and compare it with ctime as well as perform sizes comparision. Transactional upgrade is far harder than my approach (but obviously better) - do we have sufficient manpower for this? |
|
Hm, don't know what works best, to prevent such issues. First I thought it was a issue because postfix was running during the update but second run didn't solve the issue. At the moment I'm ranting if a pre-upgrade and post-upgrade script (stopping postfix and restarting postfix) could be helpful, since debugging issues on the user site seems harder. |
|
PS: How can I format text the same as Matthew? |
|
@ohauer use backticks |
|
@brd Thanks! |
|
On 22/02/2016 20:08, ohauer wrote:
postfix being run at the time won't make any difference to the install.
I've used: find -E /usr/local -regex '.*.[a-zA-Z0-9]{12}$' to identify pkg(8)'s leavings. Beware of just deleting such files |
In case of hardlinks, `pathname` var was incorrectly restored from `rpath` which is intended to be a temporary name. Hence, renaming was meaningless afterwards. Issue: #1394 Reported by: many
|
Maybe an interesting finding. |
|
I've done some tests with pkg-static-1.6.1 .. 1.6.4 and suspect the issue is only in 1.6.4 present. For the test I've build two postfix versions one was always the installed starting point and the other was the upgrade target. pkg-static.1.6.(1-3) went without issues, all files where upgraded and no leftovers where found, 1.6.4 failed and some binaries and documents where not upgraded but left over, but checksums where updated in the database. |
|
I've added patch to the master that fixes this issue. |
|
@vstakhov |
In case of hardlinks, `pathname` var was incorrectly restored from `rpath` which is intended to be a temporary name. Hence, renaming was meaningless afterwards. Issue: #1394 Reported by: many
|
fixed |
So, I'm upgrading a machine from FreeBSD-9.3 to 10.2, and consequently reinstalling all packages.
However, it seems some binaries are not replaced even by
pkg install -f:To fix this I had to:
perl5 isn't the only pkg to suffer from this. Looks like git and binutils also do. (And, yes, these are with freshly installed 10.x versions of the pkgs.)
The text was updated successfully, but these errors were encountered: