Solved recurring problem in upgrading python39

[hakova]

Hi all,

I am attempting to remotely upgrade python39 and consistently get the following behavior:

# pkg upgrade python39
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        python39: 3.9.14 -> 3.9.15

Number of packages to be upgraded: 1

18 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching python39-3.9.15.pkg: 100%   18 MiB   6.1MB/s    00:03  
Checking integrity... done (0 conflicting)
[1/1] Upgrading python39 from 3.9.14 to 3.9.15...
client_loop: send disconnect: Broken pipe

The debug option doesn't provide useful information either.

# pkg -d upgrade python39
DBG(1)[971]> pkg initialized
Updating FreeBSD repository catalogue...
DBG(1)[971]> PkgRepo: verifying update for FreeBSD
DBG(1)[971]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
DBG(1)[971]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/meta.conf
DBG(1)[971]> opening libfetch fetcher
DBG(1)[971]> Fetch > libfetch: connecting
DBG(1)[971]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/meta.conf with opts "i"
DBG(1)[971]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/packagesite.pkg
DBG(1)[971]> opening libfetch fetcher
DBG(1)[971]> Fetch > libfetch: connecting
DBG(1)[971]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.pkg with opts "i"
DBG(1)[971]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/packagesite.txz
DBG(1)[971]> opening libfetch fetcher
DBG(1)[971]> Fetch > libfetch: connecting
DBG(1)[971]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.txz with opts "i"
FreeBSD repository is up to date.
All repositories are up to date.
DBG(1)[971]> want to get an advisory lock on a database
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        python39: 3.9.14 -> 3.9.15

Number of packages to be upgraded: 1

18 MiB to be downloaded.

Proceed with this action? [y/N]: y
DBG(1)[971]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/All/python39-3.9.15.pkg
DBG(1)[971]> opening libfetch fetcher
DBG(1)[971]> Fetch > libfetch: connecting
DBG(1)[971]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/All/python39-3.9.15.pkg with opts "i"
DBG(1)[971]> Fetch: fetcher chosen: http
[1/1] Fetching python39-3.9.15.pkg: 100%   18 MiB   3.7MB/s    00:05   
Checking integrity...DBG(1)[971]> Binary> loading /var/cache/pkg/python39-3.9.15~3d12bd9496.pkg
DBG(1)[971]> check integrity for 1 items added
 done (0 conflicting)
DBG(1)[971]> want to upgrade advisory to exclusive lock
[1/1] Upgrading python39 from 3.9.14 to 3.9.15...
client_loop: send disconnect: Broken pipe

Other python versions (37 and 38) upgraded fine with no problems. Thanks in advance for your suggestions.

 

[T-Daemon]

I am attempting to remotely upgrade python39

client_loop: send disconnect: Broken pipe

A web search of that error message points to a ssh problem:

"client_loop: send disconnect: Broken pipe" at DuckDuckGo

html.duckduckgo.com

As a workaround you could try fetching the package
fetch http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/All/python39-3.9.15.pkg

backup old version pkg create python39

pkg delete -f python39, pkg add python39-3.9.15.pkg

 

[hakova]

Thank you for the response but I was able to have console access to the VM just now and attempting the upgrade there led to a kernel panic due to what I am guessing is a bit rot. Please see the screenshot below. I rebooted in single user mode and ran

#fsck -y

but it didn't resolve the issue. Any pointers of how to correct this "mangled entry" will be very much appreciated.

 

[hakova]

After doing some searching I found the following link which actually cleaned the inode and help solve the problem. It is getting a little off-topic but this is the second time I am having issues with ufs in the virtual machine. The first one was some corrupted entries in Caldav server radicale running this machine. I had to remove and re-enter them one-by-one at that time. The hardware that keeps the virtual disk is an M.2 drive. I wonder if there is a way to test that. I will look into that next I guess. On the flip side, that drive contains the hypervisor OS (linux) which has not shown any signs of corruption, even though that may not mean much.

Here is the link that solved my problem:
https://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/