Removing components with `freebsd-update`

In upgrading to 14.1-RELEASE using freebsd-update, I found the server apparently had the dbg and lib32 components installed. The server has only been updated/upgraded with freebsd-update.

Code:
The following components of FreeBSD seem to be installed:
kernel/generic kernel/generic-dbg world/base world/base-dbg world/lib32
world/lib32-dbg

The following components of FreeBSD do not seem to be installed:

Does this look reasonable (y/n)? y

Although these are small and likely reasonably secure, I'd prefer if they weren't there.

Is there a way to accomplish this using freebsd-update?

If not, is there a reasonable way to source freebsd-update to be able to use its metadata retrieval and filtering functionality such as fetch_filter_metadata_components
to get the expected list of files for deletion? Of course, if there is a place that information resides already, that would be even better.
 
if there is a place that information resides already, that would be even better.
There is not but that sounds like a great feature for bsdconfig. You should be able to delete base components like lib32 there.
Unfortunatly you can't.
 
There is not but that sounds like a great feature for bsdconfig.
Well, it would have been a great feature. I recently keep reading posts from people already using pkgbase, being quite happy with it; this will finally allow the same flexibility for binary installations you previously only had by building/installing from source (setting knobs from src.conf(5)). So my guess is that in the long run, this will lead to deprecation of freebsd-update(8) anyways.
 
Thanks for the pointer to the old thread as well as to https://wiki.freebsd.org/PkgBase and related.

It looks like I'll have to extract file lists from the tarballs or manifests to remove the unwanted components.

PkgBase looks interesting as a way to manage binary upgrades in the future. I will probably try it on a test host given the caveats on that wiki page.
 
Use at your own risk. Note that multiple components can install into the same directories (and even the same files). While the output seems reasonable to me, this was reverse engineered from looking at the file contents, not from knowledge of their intent. There is no cleanup of files generated.

Edit to untabify the code for better rendering

Code:
#!/bin/sh

PROCESS="kernel/generic-dbg world/base-dbg world/lib32 world/lib32-dbg"

WORKDIR=/var/db/freebsd-update

TMPDIR=$(date -r "$WORKDIR/tINDEX.present" +"$WORKDIR/%Y-%m-%d_%H%M")

mkdir -vp "$TMPDIR"
>&2 echo "Using $TMPDIR"

cat "$WORKDIR/tINDEX.present" | while IFS= read -r line; do
    inbase=$(echo "$line" | cut -d '|' -f 2)
    outfile=$(echo "$line" | cut -d '|' -f 1)
    gzcat "${WORKDIR}/files/${inbase}.gz" > "${TMPDIR}/${outfile}"
done

ls -l "$TMPDIR"

process_component () {

    component=$(echo "$1" | tr '/' '|')

    fname="${TMPDIR}/$(printf '%s' "$component" | tr '|' '_')"

    look "${component}|" "${TMPDIR}/INDEX-ALL" > "${fname}.index"

    cat /dev/null > "${fname}.dirs"
    cat /dev/null > "${fname}.match"
    cat /dev/null > "${fname}.mismatch"
    cat /dev/null > "${fname}.missing"

    echo "Processing $1"

    lineno=0
    cat "${fname}.index" | while read -r line ; do

        file=$(echo "$line" | cut -d '|' -f 3)
        type=$(echo "$line" | cut -d '|' -f 4)
        hash=$(echo "$line" | cut -d '|' -f 9)

        lineno=$((lineno + 1))

        printf "\\033[2K\\r%s: %s" "$lineno" "$file"

        case $type in
            d)
                echo "$file" >> "${fname}.dirs"
                ;;
            *)
                if ! [ -e "$file" ] ; then
                    echo "$file" >> "${fname}.missing"
                else
                    if sha256 -c "$file" ; then
                        echo "$file" >> "${fname}.match"
                    else
                        echo "$file" >> "${fname}.mismatch"
                    fi
                fi
                ;;
        esac
    done

    echo
}

for c in $PROCESS ; do
    process_component $c
done
 
… I will probably try it on a test host given the caveats on that wiki page.

A test is reasonable.

For what it's worth: since I switched to pkgbase in February, more than three hundred upgrades have included base.

Code:
% wc -l /home/grahamperrin/Documents/boot\ environments.txt
     409 /home/grahamperrin/Documents/boot environments.txt
% cat /home/grahamperrin/Documents/boot\ environments.txt | grep base | wc -l
     314
% cat /home/grahamperrin/Documents/boot\ environments.txt | grep -v ports | wc -l
     335
% bectl list -c creation | grep -v Active | wc -l
      80
%
  • never a problem, with sensible use of bectl
  • I normally weed to have far fewer environments – 80 is extraordinarily high (slowly, occasionally, troubleshooting a possible regression affecting wake from sleep)
Attached: a detailed record of today's upgrade from 1500025 to 1500026. The tail:

Code:
root@mowa219-gjp4-zbook-freebsd:~ # cp /tmp/up/boot/loader.efi /boot/efi/efi/freebsd/loader.efi && cp /tmp/up/boot/loader.efi /boot/efi/efi/boot/bootx64.efi
root@mowa219-gjp4-zbook-freebsd:~ # cp /root/.history /tmp/up/root/.history
root@mowa219-gjp4-zbook-freebsd:~ # history -S
root@mowa219-gjp4-zbook-freebsd:~ # cp /root/.history /tmp/up/root/.history
root@mowa219-gjp4-zbook-freebsd:~ # bectl umount 1500026-001-base
root@mowa219-gjp4-zbook-freebsd:~ # bectl activate -t 1500026-001-base ; exit
Successfully activated boot environment 1500026-001-base
for next boot
logout
% exit

- note, option -t



Elsewhere:
1729745958301.png
 

Attachments




2021:

… I wanted to get rid of kernel/generic-dbg

Deinstalled with a single command:

Code:
root@fourteen-pkgbase:~ # pkg iinfo FreeBSD-kernel
FreeBSD-kernel-generic-14.1p5
FreeBSD-kernel-generic-dbg-14.1p5
FreeBSD-kernel-generic-mmccam-14.1p5
FreeBSD-kernel-generic-mmccam-dbg-14.1p5
FreeBSD-kernel-minimal-14.1p5
FreeBSD-kernel-minimal-dbg-14.1p5
root@fourteen-pkgbase:~ # pkg delete -y FreeBSD-kernel-generic-dbg
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        FreeBSD-kernel-generic-dbg: 14.1p5

Number of packages to be removed: 1

The operation will free 515 MiB.
[1/1] Deinstalling FreeBSD-kernel-generic-dbg-14.1p5...
[1/1] Deleting files for FreeBSD-kernel-generic-dbg-14.1p5: 100%
root@fourteen-pkgbase:~ # freebsd-version -kru ; uname -aKU
14.1-RELEASE-p5
14.1-RELEASE-p5
14.1-RELEASE-p5
FreeBSD fourteen-pkgbase 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 releng/14.1-n267718-524a425d30fc GENERIC amd64 1401000 1401000
root@fourteen-pkgbase:~ # pkg -vv | grep -B 1 -e url -e enabled
  FreeBSD-ports: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/quarterly",
    enabled         : yes,
--
  FreeBSD-base: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/base_release_1",
    enabled         : yes,
root@fourteen-pkgbase:~ #

If you're curious about affected files, see the attached transcript. sorry, the file failed to upload.

Code:
% file /tmp/pkg\ -ddd\ delete\ -y\ FreeBSD-kernel-generic-dbg.txt
/tmp/pkg -ddd delete -y FreeBSD-kernel-generic-dbg.txt: ASCII text
% ls -hln /tmp/pkg\ -ddd\ delete\ -y\ FreeBSD-kernel-generic-dbg.txt
-rw-r--r--  1 1002 0  187K 28 Oct 20:33 /tmp/pkg -ddd delete -y FreeBSD-kernel-generic-dbg.txt
%
 
Back
Top