Solved Running pkg upgrade stalls at extracting step

A

a time to chill

I'm trying to run pkg upgrade but it keeps stalling at the extracting step. Below is what I see when trying to update via SSH.

Code: 
Proceed with this action? [y/N]: y
[1/13] Upgrading lidarr from 1.3.5.3530_2 to 2.0.7.3849...
===> Creating groups.
Using existing group 'lidarr'.
===> Creating users
Using existing user 'lidarr'.
[1/13] Extracting lidarr-2.0.7.3849: 100%
client_loop: send disconnect: Broken pipe
This happens with any package I try to upgrade. Any idea how I can fix?
 
What version of FreeBSD are you running when you do this, and can you tell us what happens when you try to:
  • upgrade any other package
  • install any other package
 
I'm using version 14.0. I tried installing another package (snort) and it worked. I was able to delete it afterwards. I was also able to upgrade another package already installed (i.e. screen). It seems like there's an issue with the arr apps I have installed (e.g. lidarr, radarr, tautulli, etc.). They get stuck on the extracting step.

Is it possible for me to downgrade, because those apps aren't working after I attempted the pkg upgrade command.
 
I think there's something wrong with that specific package. Just tried to install it on a test system.

Code: 
[75/75] Extracting lidarr-2.0.7.3849:  68%
pkg: Fail to extract /usr/local/share/lidarr/bin/System.Private.CoreLib.dll from package: Write error
[75/75] Extracting lidarr-2.0.7.3849: 100%

/usr/local/share/lidarr/ doesn't exist, which is odd.
 
SirDice said:
I think there's something wrong with that specific package. Just tried to install it on a test system.

Code: 
[75/75] Extracting lidarr-2.0.7.3849:  68%
pkg: Fail to extract /usr/local/share/lidarr/bin/System.Private.CoreLib.dll from package: Write error
[75/75] Extracting lidarr-2.0.7.3849: 100%

/usr/local/share/lidarr/ doesn't exist, which is odd.
Click to expand...
Thank you for checking. Is there a way I can essentially hit reset on that attempted upgrade? It was working before I attempted to update the packages on my system.
 
a time to chill said:
Is there a way I can essentially hit reset on that attempted upgrade?
Click to expand...
Look in /var/cache/pkg/ maybe you still have the old version cached there. You can force the installation of that with pkg add -f <package filename>. Then you should pkg lock <packagename> it, after you locked it a pkg upgrade will ignore it and not attempt to upgrade.
 
SirDice said:
I think there's something wrong with that specific package. Just tried to install it on a test system.
Click to expand...
Also did a poudriere testport on it. That doesn't complain about anything being wrong. Weird.
 
Yeah, I agree with SirDice 's assessment that something is wrong with that specific package...

The official way to deal with it is to see if the port has a maintainer and file a PR. It can be a bit time-consuming to figure out how to do that, and where to go.

Technically, there is a quick-and-dirty way to deal with it.
SirDice said:
I think there's something wrong with that specific package. Just tried to install it on a test system.

Code: 
[75/75] Extracting lidarr-2.0.7.3849:  68%
pkg: Fail to extract /usr/local/share/lidarr/bin/System.Private.CoreLib.dll from package: Write error
[75/75] Extracting lidarr-2.0.7.3849: 100%

/usr/local/share/lidarr/ doesn't exist, which is odd.
Click to expand...
Since the package is looking for a specific directory (and not finding it), I just create the missing directory by hand. Just to help things along a bit. Then I try the installation again. Usually, that helps, and it hasn't bitten me. If that kind of approach ever bites me - I'd complain on the Forums about it.
 
I also tried updating samba and it got stuck on the same extracting part. Not sure if something is wrong with my system that I need to correct.

Proceed with this action? [y/N]: y
[1/1] Upgrading samba413 from 4.13.17_6 to 4.13.17_8...
[1/1] Extracting samba413-4.13.17_8: 100%
Click to expand...

SirDice said:
Look in /var/cache/pkg/ maybe you still have the old version cached there. You can force the installation of that with pkg add -f <package filename>. Then you should pkg lock <packagename> it, after you locked it a pkg upgrade will ignore it and not attempt to upgrade.
Click to expand...
Unfortunately it looks like the current version of the package that was working is no longer there. Is there a website where I can pull a previous version to install?
 
Yeah, the dependency hell bites. Usually, there's not that many packages that one really wants to upgrade. There's gotta be ways to ameliorate that biting.

As for slightly older package versions: Try looking at http://pkg.freebsd.org/... this is a start.

I stick with ports, rather than pre-compiled packages (I can write a book about why I do that), at least in part because ports are more flexible, and bite less than packages.

Well, there's lots of people who got bitten by pkgupgrade and freebsd-update, thanks to that dependency hell. They do discover that it's easier to reinstall the system from scratch than to fight through the mistakes they make with the upgrading. Some of them get frustrated and move on to something else, but there's quite a few who do treat it as a learning experience.

To me, this is another use case for a Poudriere-based project whose goal is to iron out upgrading for a specific list of ports by compiling them against the existing stuff. I sometimes want to upgrade KDE while leaving everything else untouched. That's because as things stand now, an 'upgrade' really means 'complete reinstall of the system, using up-to-date components'. ? On FreeBSD, this is at least way less painful than on Linux.
 
Installing from ports got most of the apps I use functional again. There are just two apps that aren't working that I will need to continue to troubleshoot.
 
The last couple of apps I'm trying to fix are calibre and tautulli. When I try to start the calibre_server service I get the following traceback error message:

Code: 
Starting calibre_server.
Traceback (most recent call last):
  File "/usr/local/bin/calibre-server", line 20, in <module>
    from calibre.srv.standalone import main
  File "/usr/local/lib/calibre/calibre/__init__.py", line 22, in <module>
    initialize_calibre()
  File "/usr/local/lib/calibre/calibre/startup.py", line 147, in initialize_calibre
    from calibre.utils.icu import title_case, lower as icu_lower, upper as icu_upper
  File "/usr/local/lib/calibre/calibre/utils/icu.py", line 13, in <module>
    from calibre_extensions import icu as _icu
ImportError: Shared object "libicudata.so.73" not found, required by "icu.so"
/etc/rc.d/calibre_server: WARNING: failed to start calibre_server

When I try to start Tautulli:

Code: 
Traceback (most recent call last):
  File "/usr/local/www/tautulli/Tautulli.py", line 39, in <module>
    import plexpy
  File "/usr/local/www/tautulli/plexpy/__init__.py", line 67, in <module>
    from plexpy import activity_handler
  File "/usr/local/www/tautulli/plexpy/activity_handler.py", line 37, in <module>
    from plexpy import activity_processor
  File "/usr/local/www/tautulli/plexpy/activity_processor.py", line 32, in <module>
    from plexpy import database
  File "/usr/local/www/tautulli/plexpy/database.py", line 31, in <module>
    from plexpy import helpers
  File "/usr/local/www/tautulli/plexpy/helpers.py", line 36, in <module>
    import ipwhois
  File "/usr/local/www/tautulli/lib/ipwhois/__init__.py", line 26, in <module>
    from .net import Net
  File "/usr/local/www/tautulli/lib/ipwhois/net.py", line 27, in <module>
    import dns.resolver
  File "/usr/local/www/tautulli/lib/dns/resolver.py", line 39, in <module>
    import dns.query
  File "/usr/local/www/tautulli/lib/dns/query.py", line 37, in <module>
    import dns.quic
  File "/usr/local/www/tautulli/lib/dns/quic/__init__.py", line 4, in <module>
    import aioquic.quic.configuration  # type: ignore
  File "/usr/local/lib/python3.9/site-packages/aioquic/quic/configuration.py", line 6, in <module>
    from ..tls import (
ValueError: source code string cannot contain null bytes
/usr/local/etc/rc.d/tautulli: WARNING: failed to start tautulli
Something got messed up with my python install when I tried to run pkg update. Any idea on how to resolve?
 
For calibre-server:
run locate libicudata.so.73. This should spit out a location that is not in /usr/ports. Verify that result by running an ls /path/to/libicudata.so.73 If path is in /usr/ports/category/calibre/work, then copy the lib from ports dir into system dir...

Well, if locate turns up empty, you can just fake it by touching the missing lib in the correct spot: touch /usr/local/lib/libicudata.so.73... I sometimes do that. Yeah, it's better to have a properly working port, but sometimes faking the missing file does the trick.

As for Python - what happens when you try to reinstall it?
 
I was able to get calibre working. However, I had to do a hard reset and then my system was stuck in a boot loop.

zpool status -v shows that there is a permanent error on zroot with the file /usr/local/lidarr/lidarr.db

1705627538271.png


I tried running zpool clear zroot, doing a scrub, and deleting the file. When I tried to delete the file, the system just rebooted. I guess this lidarr.db file got corrupted when I was trying to run the pkg update.
 
I was able to clear the error on the zroot pool by running a scrub and stopping it while it was ongoing as described here (run command zpool scrub -s zroot). However, I'm still facing a boot loop. It looks like it is still unable to mount local file systems.

It seems to complain about not finding the swap.

1705632215103.png


This is what shows when I run gpart show ad0 command.

1705632327847.png


How can I add the swap back?
 
Frankly, this looks like a bad HDD... I had similar errors on a crappy cheap SSD from the TeamGroup brand. Replaced it with a Samsung 970 EVO SSD. Yeah, I had to restart the install from scratch, but it went just fine, and way faster, too.
 
Thanks all for your help. I have been using this freebsd install for a while now and forgot about the snapshots I had for zroot. I did a rollback using my latest snapshot and the problem went away. I'm able to boot normally now. Frustrating as this was, it was a good learning experience. Now I need to figure out how to safely update packages going forward. I think I'm going to take a snapshot of zroot before running pkg update again from now on.
 
You must log in or register to reply here.
Back
Top