Pkg upgrade failed and "lost" packages

tuaris

tuaris

When you do a pkg upgrade and it happens to fail and exit midway through the process, this could potentially leave the system in a state where packages are 'lost'.

In this case I did run pkg info prior to starting so I can have a record of what's installed (I've been burned by this before). The pkg() tool shouldn't behave this way. Also notice how it also wanted to remove the DNS server and not upgrade it.

(full log here)

Code: 
[162/276] Installing libgpg-error-1.55...
[162/276] Extracting libgpg-error-1.55: 100%
[163/276] Installing libgcrypt-1.11.1...
[163/276] Extracting libgcrypt-1.11.1: 100%
[164/276] Installing libnghttp2-1.66.0...
[164/276] Extracting libnghttp2-1.66.0: 100%
[165/276] Installing curl-8.15.0...
[165/276] Extracting curl-8.15.0: 100%
[166/276] Installing mongodb70-7.0.22...
pkg: mongodb70-7.0.22 conflicts with mongodb60-6.0.20_2 (installs files into the same place).  Problematic file: /usr/local/bin/mo                                                                                                           ngod
root@saturn:~ # pkg upgrade
Updating Saturn repository catalogue...
Saturn repository is up to date.
All repositories are up to date.
Checking for upgrades (49 candidates): 100%
Processing candidates (49 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
 
T-Aoki said:
You shouldn't have been checked UPDATING, don't you?
There seems to be more entries related with mongodb.
If you're using net-mgmt/unifi9, there is related entry.


And for default versions, monitoring updates for Mk/bsd.default-versions.mk would be a good habit (mongodb is not included, but knowing what changed there is worth enough).
Click to expand...
That's fine and all, but the core of the issue is what happens regardless of what causes it. You can have an oom kill, segfault, a power outage. If you are doing this remotely over ssh someone could trip over the network cable and knock it loose, your ISP can have a sudden outage, your wifi could drop, etc... Yes, even as mentioned, you can run out of storage because in this one instance you forgot to check it, or you thought there was enough. Anything can cause pkg to suddenly die like this.
 
This is why I've commented in #2.
tuaris said:
[166/276] Installing mongodb70-7.0.22... pkg: mongodb70-7.0.22 conflicts with mongodb60-6.0.20_2 (installs files into the same place). Problematic file: /usr/local/bin/mo ngod root@saturn:~ # pkg upgrade
Click to expand...
Something depending on databases/mongodb60 switched its dependency to databases/mongodb70, which conflicts each other (regardless by default [maybe net-mgmt/unifi9 only by looking into databases/mongodb60 and databases/mongodb70 in addition to already mentioned UPDATING entry] or not) and aborted.

You're strongly advised to dry-run before actual upgrade to see what are going to be installed and what are going to be deinstalled.
 
T-Aoki said:
This is why I've commented in #2.

Something depending on databases/mongodb60 switched its dependency to databases/mongodb70, which conflicts each other (regardless by default [maybe net-mgmt/unifi9 only by looking into databases/mongodb60 and databases/mongodb70 in addition to already mentioned UPDATING entry] or not) and aborted.

You're strongly advised to dry-run before actual upgrade to see what are going to be installed and what are going to be deinstalled.
Click to expand...
Yes, I understand why it aborted. That's not the problem I am describing.
 
Not consulting ports-mgmt/pkg sources, but possible scenario:
  1. Delete to-be-upgraded pkg
  2. Delete not-yet-upgraded dependencies for it and one of them are the conflicting one, but CONFLICT line is not properly described
  3. Install upgraded versions from root to leaves
  4. Detected unknown (as of insufficient CONFLICT list) conflict and crash
  5. Not yet installed upgraded versions are lost
 
I haven't run into any real problems (yet), but I also noticed a significant change in behavior of recent pkg versions.
While previously it would always delete an old version and install a new version one-by-one, now it sometimes deletes a big batch of packages and then starts installing their new versions.
The new behavior seems much less safe.

P.S.
I always create a ZFS snapshot just before pkg upgrade.
 
Andriy said:
I haven't run into any real problems (yet), but I also noticed a significant change in behavior of recent pkg versions.
While previously it would always delete an old version and install a new version one-by-one, now it sometimes deletes a big batch of packages and then starts installing their new versions.
The new behavior seems much less safe.

P.S.
I always create a ZFS snapshot just before pkg upgrade.
Click to expand...
Yeah, I noticed the same and I don't like it as well. I guess I will update more often to minimize the risks.
 
If the whole process from delete to install is atomic (100% finish or 100% reroll, just like updating records on commercial huge scale DBs on mainframes), upgrade of multiple pkg at once is acceptable.

But if it's not realistic, per-single-pkg atomic operation should be preferred.
It should be possible, as oldest (if I'm not missing something others) ports upgrading tool, portupgrade does backup-delete-install procedure AFTER successful builds, and if deletion or installation fails, clean up on-install new version and forcibly reinstall previous version from the backup.

IIRC, portmaster was created by developers who don't like ruby to be pulled in and hesitates to keep backups of old libraries by default at /usr/local/lib/compat/pkg/.

I've intentionally didn't set PORT tag, as both portupgrade and portmaster (at least portupgrade) was first introduced when category ports-mgmt was not yet created. Such long living tools does so, so why pkg can't?
 
For ZFS users, boot environment and snapshot is useful
But for UFS users? Other way should be wanted.

As pkg uses its own cache directory instead of legacy /usr/ports/packages/All/, and maybe filename of to-be-upgraded previous version of pkg is hard, script to dry-run pkg to redirect its output to temporary file, cut unneeder parts, generate category/port[@flavor] form of list, create pkg by pkg create -o /usr/ports/packages/All [each ports in the list] for the listed currently installed pkg into /usr/ports/packages/All/, then, upgrade would be wanted. If anything fails, previous version would be forcibly installed from backup.
 
T-Aoki said:
But for UFS users? Other way should be wanted.
Click to expand...
I agree, while it is a bit experimental and not very known, there is this alternative.
I've tried it once in VM, it worked, but it has flows too:
_ it takes a lot of space as each boot environment(which is in fact a partition per BE) should be "large" enough to contain data.
_ partitions should be done before installing FreeBSD which implies that you already planed to use ufsbe.sh, most of the time you don't, and when you do it's already too late.
_ according to the script BE are limited to 3, unless you are willing to modify the script itself and the number of partition.

But as a proof of concept I think it is good that it exists.
 
You must log in or register to reply here.
Back
Top