Re: after updating to latest, pkg base segfaults and leaves me unbootable

From: Lexi Winter <ivy_at_freebsd.org>
Date: Sat, 09 Aug 2025 10:52:08 UTC
Dan Mahoney:
> [598/1127] Deleting files for p5-MIME-Base32-1.303: 100%
> [599/1127] Deinstalling p5-MIME-Base64-3.16...
> [599/1127] Deleting files for p5-MIME-Base64-3.16: 100%
> Child process pid=21537 terminated abnormally: Segmentation fault

do you happen to know what process got SEGV here?  if you still have a
copy of the broken system it should be logged in /var/log/messages, e.g.:

Aug  8 16:52:34 tansy kernel: pid 80112 (su), jid 0, uid 0: exited on signal 11 (core dumped)

> root@poudriere:/home/dmahoney # pkg upgrade
> ELF interpreter /libexec/ld-elf.so.1 not found, error 2
> Abort

i believe this is a result of a pkg bug that causes it to remove
packages too early, which leaves the system in a broken state if
the upgrade fails for some reason.  Isaac has a fix for this which
is waiting to be merged: https://github.com/freebsd/pkg/pull/2488

this isn't the root cause of your issue, but it makes the result
much worse than it should be.

> Now, if this were 14.x, I'd fix this by untarring a distfile right
> over / to get back up and running.  Not quite an option in 15, is it?
> (I would encourage the people making this stuff to please consider
> keeping those built, even if bsdinstall uses pkgbase).

you can fix this by reinstalling the base system with pkg-static, which
is the pkgbase equivalent of extracting base.txz:

	pkg-static install -r base -g 'FreeBSD-*'

however, this will overwrite all your configuration files, including
/etc/master.passwd, so be very careful.

> But it's *really* not instilling me with a lot of confidence in the
> readiness of this pkgbase idea.

fwiw, i use pkgbase extensively and try to keep track of what the
current issues are, and i was aware of this one.  as far as i know,
we don't have any other critical issues in pkgbase right now.

so, it's not that no one is aware of problems, but there are some that
haven't been fixed yet.  i agree it is unfortunate that the pkg.f.o
repository update triggered this particular issue, so we should work
out what's going on there.

> * For all the debate about "pkgbase and pkg should be exactly the
> same", perhaps pkgbase could have an auto-bectl in it?

i would like a pkg option to always create a BE before upgrade, and i
don't think this needs to be restricted to base.  it's possible for
ports upgrades to go wrong and that still breaks the system if it
relies on ports for whatever its job is.

> * With something like -CURRENT, is there any support for saying "Okay
> not the current-current tree, but current-minus-one"

pkgbase itself supports this: the packages are published to versioned
directories and you can specify a particular version instead of latest.
for example:

# COLUMNS=72 ls /export/www/pkg.le-fay.org/htdocs/base/FreeBSD:15:amd64
15.snap20250620153806	15.snap20250719064609	15.snap20250723060537
15.snap20250621164409	15.snap20250720115500	15.snap20250730114516
15.snap20250625161336	15.snap20250720120932	15.snap20250731132603
15.snap20250717233446	15.snap20250721030138	latest

however, this doesn't seem to be exposed on pkg.f.o right now, you only
get the latest repository.  perhaps that should change.

> * And for running -CURRENT where this kind of breakage can happen,
> could we get a statically linked version of pkg?

pkg-static already exists in the pkg package.  if you mean we should
have pkg-static in base, that can't happen unless we import pkg into
src, which for various reasons isn't considered feasible right now.