Bug 263879 - pkgbase removes critical etc files upon upgrade
Summary: pkgbase removes critical etc files upon upgrade
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-09 13:48 UTC by Mark Johnston
Modified: 2022-05-20 16:47 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Johnston freebsd_committer 2022-05-09 13:48:43 UTC 
Upgrading a pkgbase system, I lost /etc/group and /etc/master.passwd, among other files, because pkg split the FreeBSD-runtime upgrade job:

  - FreeBSD-runtime-dev-lib32-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-14.snap20220503053224 [installed] on /usr/libdata/pkgconfig/zlib.pc
  - FreeBSD-runtime-dev-lib32-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-runtime-dev-14.snap20220509053256 [FreeBSD-base] on /usr/libdata/pkgconfig/zlib.pc
  - FreeBSD-libmagic-dev-lib32-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-libmagic-dev-14.snap20220503053224 [installed] on /usr/libdata/pkgconfig/libmagic.pc
  - FreeBSD-libmagic-dev-lib32-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-libmagic-dev-14.snap20220509053256 [FreeBSD-base] on /usr/libdata/pkgconfig/libmagic.pc
  - FreeBSD-liblzma-dev-lib32-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-liblzma-dev-14.snap20220503053224 [installed] on /usr/libdata/pkgconfig/liblzma.pc
  - FreeBSD-liblzma-dev-lib32-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-liblzma-dev-14.snap20220509053256 [FreeBSD-base] on /usr/libdata/pkgconfig/liblzma.pc
  - FreeBSD-hyperv-tools-14.snap20220509053256 [FreeBSD-base] conflicts with FreeBSD-runtime-14.snap20220503053224 [installed] on /etc/devd/hyperv.conf
...
[1/389] Deinstalling FreeBSD-runtime-14.snap20220503053224...                                                                                                                                                                                                                                                                 
[1/389] Deleting files for FreeBSD-runtime-14.snap20220503053224: 100%                                                                                         
[2/389] Deinstalling FreeBSD-runtime-dev-14.snap20220503053224...                                                                                              
[2/389] Deleting files for FreeBSD-runtime-dev-14.snap20220503053224: 100%
[3/389] Deinstalling FreeBSD-libmagic-dev-14.snap20220503053224...
[3/389] Deleting files for FreeBSD-libmagic-dev-14.snap20220503053224: 100%
[4/389] Deinstalling FreeBSD-liblzma-dev-14.snap20220503053224...
[4/389] Deleting files for FreeBSD-liblzma-dev-14.snap20220503053224: 100%
[4/389] Installing FreeBSD-runtime-14.snap20220509053256...
[4/389] Extracting FreeBSD-runtime-14.snap20220509053256:   0%
pkg: getgrnam_r(wheel): No such file or directory
...

So this seems to be a consequence of https://cgit.freebsd.org/src/commit/?id=7ac164dc8e2ec3e6d3cda1d9ca13d461a534a6e8 .  In particular, pkg sees that hyperv.conf moved out of FreeBSD-runtime, so to both upgrade FreeBSD-runtime and FreeBSD-hyperv-tools, pkg deleted the former and reinstalled it, so all the etc files that it manages get reset to their defaults.  A workaround is to delete FreeBSD-hyperv-tools before upgrading.

In this case, it looks simply like a deficiency of the solver.  Moving hyperv.conf just means that pkg must upgrade FreeBSD-runtime before FreeBSD-hyperv-tools; it does not need to delete then install FreeBSD-runtime.

More generally, pkg/pkgbase really need some mechanism to avoid deleting critical files.
Comment 1 Ed Maste freebsd_committer 2022-05-20 16:47:15 UTC 
Cherry-picking part of what you wrote,
> to ... upgrade FreeBSD-runtime... pkg deleted ... and reinstalled it, so all the etc files that it manages get reset to their defaults.

This is caused by FreeBSD-runtime being removed and installed, rather than upgraded? It seems like this is a critical deficiency independent of whether something is done with the solver or not - even if the user does something like using override/force flags to delete critical packages we need to protect these critical files.