Remove components post-installation

edogawaconan

New Member

Reaction score: 1
Messages: 12

A long time ago I installed freebsd with all distribution sets.

Now I want to remove some of the sets (notably catman, info and proflibs). Is it possible?

(or I missed something, somewhere?)
 

brd@

Administrator
Staff member
Administrator
Moderator
Developer

Reaction score: 92
Messages: 295

Yeah, you could find the tarballs that contain these sets and use something like:
Code:
tar -t <tarball>
So you know what files are included in it and make sure you want to remove them. Then you could probably do something like this to remove them:
Code:
tar -t <tarball> | xargs rm
 
OP
edogawaconan

edogawaconan

New Member

Reaction score: 1
Messages: 12

doesn't seem to cleanly remove the component (namely freebsd-update upgrade still recognizes these components: world/dict world/info) which I want to remove.
 

tnpimatt

New Member

Reaction score: 5
Messages: 12

For the sake of other search engine visitors, the reason it may not have worked cleanly for edogawaconan is likely because the file paths in the component tarballs are relative. If he wasn't in / when he ran the command, it wouldn't have deleted the files. Here's an example command that will remove the doc sources from a FreeBSD machine:

Code:
cd /
export FREEBSD_VERSION=`/bin/freebsd-version | /usr/bin/cut -f1-2 -d'-'`
export COMPONENT_URL="ftp://ftp.freebsd.org/pub/FreeBSD/releases/`uname -m`/$FREEBSD_VERSION"
fetch -o - $COMPONENT_URL/doc.txz | tar -tzf - | xargs rm

If you're removing the lib32 distribution, you might also have to remove some flags like so:

Code:
tar -tzf lib32.txz | xargs chflags noschg
tar -tzf lib32.txz | xargs rm
 

ShelLuser

Son of Beastie

Reaction score: 2,097
Messages: 3,790

For the sake of other search engine visitors, the reason it may not have worked cleanly for edogawaconan is likely because the file paths in the component tarballs are relative.
First, you're responding to an almost 10 year old thread, just saying ;)

I'm not sure which post you're referring to, but if you meant the last post about freebsd-update then the cause is a completely different one: /etc/freebsd-update.conf also needs to be told about any removed components. See freebsd-update.conf(5) for that.
 

tnpimatt

New Member

Reaction score: 5
Messages: 12

> First, you're responding to an almost 10 year old thread, just saying

Please be nice. I already pointed out my awareness.

>> the reason it may not have worked cleanly
>the cause is a completely different one

Apparently you missed the paragraph where I described who my post was aimed to benefit.

There is no uninstaller for FreeBSD components such as doc, games, src, ports, and lib32. By default, freebsd-update.conf has Components src world kernel. Within world are optional installs (doc, games, lib32) and freebsd-update does filesystem checks to determine whether it should update them. Without touching freebsd-update.conf at all, uninstalling the no-longer-desired components as I described does exactly what the OP and other search visitors likely want: removes the components and prevents freebsd-update from updating them.

FreeBSD users who have FreeBSD installed for them (think: cloud provider) or don't wish to re-install to get rid of components may well search for how to remove those components and land on this thread. My post was for them.
 

kjpetrie

Active Member

Reaction score: 8
Messages: 157

tnpimatt pointed me in the right direction but (fortunately) his code didn't work for me, possibly because my root user doesn't use Bash and also because rm only removes directories if the recursive option is used. If he had used that option I think I would have lost my whole system as the first error I got was
Code:
rm: ./: is a directory
!

Definitely carry out the steps manually to ensure you only remove the parts you want to remove.
Code:
rm -r
is irreversible.
 

marian_cerny

New Member

Reaction score: 14
Messages: 18

Since FreeBSD 12.0 freebsd-update shows there is world/doc installed, even when it is not. Because since FreeBSD 12.0 the doc.txz is an empty archive:

FreeBSD 12 no longer includes the 'doc' set, it was postscript files from the 1970s. The file was removed from the MANIFEST file, so everything should stop referencing it, but a valid empty tar is there in case an application wrongly depends on it being there.

The list shows a single directory ./, that's why @kjpetire (above) saw rm: ./: is a directory error.

In case you want to be sure there are no files from the previous world/doc component, you can check and/or remove the following directories:
Code:
/usr/share/doc/papers/
/usr/share/doc/psd/
/usr/share/doc/smm/
/usr/share/doc/usd/
In case you want to delete kernel/generic-dbg coponent than you can delete the following directory:
Code:
/usr/lib/debug/boot/kernel/
(Or you the whole /usr/lib/debug/ directory. It's not present if you have no debug components.)
 

kjpetrie

Active Member

Reaction score: 8
Messages: 157

Thank you for your contribution. However, it is incorrect. Firstly, this happened long before FreeBSD 12 came out, so what is or isn't included there is irrelevant, and secondly, whatever the reason, my purpose was to point out how dangerous a 9-year-old instruction was on the system as it was 3 years ago. From what you write it sounds as if it remains equally dangerous now.
 

marian_cerny

New Member

Reaction score: 14
Messages: 18

You are right that
that's why @kjpetire (above) saw rm: ./: is a directory error.
was incorrect. Your post is from 2017 and FreeBSD 12.0 was released in 2018.

However I think all the other info is correct. I came to this post because I wanted to get rid of kernel/generic-dbg component. I also noticed that world/doc component is installed which I never install, however after little research I found out that it's listed there because the component is empty and one can ignore it on FreeBSD 12+.

The reason you have seen that error is that every .txz archive contains an empty directory ./ as the first item. I agree it might dangerous to follow any instructions on internet. However, neither the original 9 years old post nor tnpimatt's 3 years old answers seems that dangerous to me, because they didn't use the recursive option. So the error is in fact only a warning. I personally didn't run those instructions blindly. I have listed the contents of an archive and deleted the files manually (for me it was just a single directory /usr/lib/debug/boot/kernel/).
 
Top