Autoremoving Packages

J

jbl85

My understanding is the pkg autoremove command removes all unused packages, and I have used the command to successfully clean up my system. However, when I ran it this morning, the system told me I could recover 2gigs by removing 333 unused packages. Of course, let's remove them! But that action rendered my system unusable, turned it into a brick. Had to restore a backup.

What am I missing about this once useful command to removed unused packages and restore some disk space?

Thanks in advance. Running FreeBSD 14.2 p2 in a Virtual Machine using VMware 17.6.2.
 
jbl85 said:
Of course, let's remove them!
Click to expand...
You're supposed to verify, then agree or not. And when my system wants to remove 333 packages, I'm going to verify why before I let it.

jbl85 said:
But that action rendered my system unusable, turned it into a brick.
Click to expand...
That's doubtful. Even if you remove all packages the system would still boot and be usable. You will not 'brick' it that way.
 
So here is the screenshot of the operation. I only have two choices, yes or no, but no verify. Can you elighten me on where the verification routine would be?

1741015124684.png
 
My apologies. I mistakened this forum for a place you could get a simple pointer on an issue. In the time it took you to belittle and insult me, you could have very well have explained what is probably a very simple process. Feel good? Good for you.
 
jbl85 said:
I only have two choices, yes or no, but no verify.
Click to expand...
You don't have to decide right away to purge the listed packages from the system. Use the pkg-autoremove(8) "-n" option and redirect the output into a file. Afterwards, inspect (and verify) all packages on the list, i.e.: pkg autoremove -n > a-rm.

It should be obvious which packages you want to keep, and which not.

333 packages to be reported as orphaned is suspicious. Removing them results in losing essential applications. Have you ran pkg-upgrade(8) before pkg-autoremove(8)?
 
jbl85 said:
My apologies. I mistakened this forum for a place you could get a simple pointer on an issue. In the time it took you to belittle and insult me, you could have very well have explained what is probably a very simple process. Feel good? Good for you.
Click to expand...
The process is really quite simple. You, as the admin, have the last word. You need to know what you want. No one else can do that for you.

I suppose you tried to remove some desktop environment, in that case you can very well end up with 333 packages who are no longer needed. It would also explain why you say the system was bricked - it is plenty hard to brick a *BSD system, the base is not a package and will not be removed. You will get a command prompt at least. Maybe you did not describe the problem correctly?
 
Maybe I am not explaining it correctly. I didn't remove any desktop environment, but I did just recently upgrade to 14.2 p2. Not sure if that has anything to do with it. As I read further into this issue, I am finding out the pkg autoremove is just not something you can blindly trust to run and remove all of the really unused components. Still rather new to all of this, but learning slow but sure. When I did allow all of the packages to be removed, there were no applications on my system, and when I would try to hit the power button to shut down or restart, that option is no longer in the dropdown. Just Log Out...Anyway, thank you for your insight, I will continue to read up and see what I can find out.
 
T-Daemon said:
You don't have to decide right away to purge the listed packages from the system. Use the pkg-autoremove(8) "-n" option and redirect the output into a file. Afterwards, inspect (and verify) all packages on the list, i.e.: pkg autoremove -n > a-rm.

It should be obvious which packages you want to keep, and which not.

333 packages to be reported as orphaned is suspicious. Removing them results in losing essential applications. Have you ran pkg-upgrade(8) before pkg-autoremove(8)?
Click to expand...
Thing is a lot of those packages that are in the list of 333 are completely unknown to me. And yes, I try to make it a habit to run pkg-autoremove after pkg-upgrade to try to keep things tidy, but yes, I've never seen that many packages to be autoremoved. There's probably a reason for this, but to much to get into a single post. Thank you for your response, I will keep digging.
 
Look in /var/log/messages, package actions are logged there. Look at what happened with the last pkg-upgrade(8). Specifically look for things that may have ended up getting deleted. Suppose you have installed "packageA" that depends on "packageB". That "packageA" may have had build issues and the package would go missing on the package repositories. But your pkg-upgrade(8) may have upgraded "packageB" and as a consequence "packageA" needs to be updated too (or else its dependency chain is broken). But "packageA" has gone missing, so the system can only remove "packageA". A further pkg-autoremove(8) would then remove "packageB" because it was automatically installed and there's nothing depending on it any more ("packageA" got removed).

All pkg(8) commands tend to ask "Are you sure (Y/N)?", it also defaults to "No". The idea here is that you check what it wants to do. Just press "No" if you don't know why it wants to remove things. Double check versions. Also check pkg version -vRL= and specifically look for version mismatches and packages that have gone missing (they'll have a '?'). Find out why that package is missing (could be various reasons, but most often because a certain build failed). Don't just blindly accept what it wants to do.
 
'pkg autoremove' removing 333 packages is not strange, depending on the package you installed/updated and/or removed, leaving loose dependencies.

What is strange is your system being unusable after doing this.
All third-party packages (pkg) are installed on /usr/local/ prefix, keeping the base system untouchable and safe. You could remove all packages (removing /usr/local/ entirely), and still your system will be working.

Every system administrator MUST verify that some system action is consistent with reality.
So, when you see that the removal of 333 packages does not match reality, you should not accept this action. The final decision is yours.

Now another question is: what went wrong?
I don't know. Probably some package was upgraded, leaving orphan dependencies, and your pkgdb file pointed to autoremove many orphan packages.
Something like below (probably I'm missing something), where origin packages marked as dependency are not in deps.

sqlite3 /var/db/pkg/local.sqlite "SELECT id, origin FROM packages where automatic=1 and origin not in (select distinct origin from deps);"


Check /var/log/messages for some clue about upgraded or removed packages.
 
rafael_grether said:
Yeah, if he is using some graphical application. But still, the system is fully operational. Saying that the system is unusable due to a X failure (or some X components) is incorrect.
Click to expand...
That depends on the skill level of the user, or the willingness to get typing instead of clicking. As far as I can tell, he did not specify this exactly.
 
jbl85 said:
Thing is a lot of those packages that are in the list of 333 are completely unknown to me. And yes, I try to make it a habit to run pkg-autoremove after pkg-upgrade to try to keep things tidy, but yes, I've never seen that many packages to be autoremoved. There's probably a reason for this, but to much to get into a single post. Thank you for your response, I will keep digging.
Click to expand...
One of reasons -- pkg-upgrade remove some packages. For example now (april 2025) after upgrade I lost meta-packages "mate", "mate-base" and "okular" (among some others). Thus, while system is still working, usable, many packages (needed by me, I use them) can be autoremoved, -- they installed by dependencies of aforementioned packages, but now the "free".

So conclusion -- pkg-autoremove is good thing, but if you see it want to remove a lot of packages, and you did non know, why -- dig what packages was deleted. And after that make decision -- to accept removal or restore removed "main" packages.
 
hex_messer said:
So conclusion -- pkg-autoremove is good thing, but if you see it want to remove a lot of packages, and you did non know, why -- dig what packages was deleted. And after that make decision -- to accept removal or restore removed "main" packages.
Click to expand...
Yep, this is the job of the "sysadmin"; don't blindly click OK, understand what the system is saying before you say yes or no. If one gets used to this flow/process on small things, when the big things happen you reduce the chances for messing up.
 
T-Daemon said:
You don't have to decide right away to purge the listed packages from the system. Use the pkg-autoremove(8) "-n" option and redirect the output into a file. Afterwards, inspect (and verify) all packages on the list, i.e.: pkg autoremove -n > a-rm.

It should be obvious which packages you want to keep, and which not.

333 packages to be reported as orphaned is suspicious. Removing them results in losing essential applications. Have you ran pkg-upgrade(8) before pkg-autoremove(8)?
Click to expand...

Executed that command, but now, any pkg autoremove command just hangs indefinitely. I rarely use this system, update it regularly. Not sure what could have gone amiss with this install. Moving on.
 
rafael_grether said:
Yeah, if he is using some graphical application. But still, the system is fully operational. Saying that the system is unusable due to a X failure (or some X components) is incorrect.
Click to expand...
Just for clarification, when I removed all 333 packages, the system was unusable, for me anyway. When I tried to restart or shut down via the GUI, none of those options were available. I rebooted via terminal, and then the graphical interface never came back.
 
As others have pointed out, there is a big difference between a system being bricked and not having a usable graphical interface.

Not sure how long you've been using Linux/*BSD, but a fundamental truth is you need to get comfortable with using the command line. In the long run, it makes it easier/more efficient to administrate a system.
In fact, if you have a CLI you have a chance to fix problems with a graphical interface.

For years, CLI was all one had and it worked just fine.

My opinions only, and honestly we've all probably been bitten by not paying attention when doing pkg commands.
One thing people will do is type "pkg autoremove -y" so automatically answering yes and then frantically hitting ctrl-C.
If you are following quarterly and try to upgrade too close to the start, you may get bad results because builds have failed or not fully pushed to all pkg servers.
I personally wait for 2 weeks just to see if anything shakes out (I think we get new threads about this every quarter) and I use ZFS on everything. Creating a new Boot Environment before doing pkg upgrade -y simply consumes disk space but gives you a trival way to get back to a working system.
 
SirDice said:
Look in /var/log/messages, package actions are logged there. Look at what happened with the last pkg-upgrade(8). Specifically look for things that may have ended up getting deleted. Suppose you have installed "packageA" that depends on "packageB". That "packageA" may have had build issues and the package would go missing on the package repositories. But your pkg-upgrade(8) may have upgraded "packageB" and as a consequence "packageA" needs to be updated too (or else its dependency chain is broken). But "packageA" has gone missing, so the system can only remove "packageA". A further pkg-autoremove(8) would then remove "packageB" because it was automatically installed and there's nothing depending on it any more ("packageA" got removed).

All pkg(8) commands tend to ask "Are you sure (Y/N)?", it also defaults to "No". The idea here is that you check what it wants to do. Just press "No" if you don't know why it wants to remove things. Double check versions. Also check pkg version -vRL= and specifically look for version mismatches and packages that have gone missing (they'll have a '?'). Find out why that package is missing (could be various reasons, but most often because a certain build failed). Don't just blindly accept what it wants to do.
Click to expand...
Thank you for the reply.

As for your suggestion to review the messages file, I looked it through, there are 1000's of lines, but on lines that have pkg entries, the only notes on those that either they were installed or upgraded. None deleted. I searched for the word "deleted" and it hit 31 times, and it was the same entry multiple times: Apr 7 13:48:47 freebsd14 kernel: WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 15.0.

Ran the command you suggested (pkg version -vRL=), after of course restoring to a version of the OS that behaves "normally"? Anyway, here is what I get. Overwhelmingly there are probably 100 entries that look like this:

All repositories are up to date.
accountsservice-23.13.9_2 < needs updating (remote has 23.13.9_3)
apr-1.7.5.1.6.3_3 < needs updating (remote has 1.7.5.1.6.3_4)

And out of those 100, there are only two that look like this:
tracker-2.3.4_13 ? orphaned: sysutils/tracker
tracker3-3.5.3_3 ? orphaned: sysutils/tracker3

Of these two orphaned packages, would it be prudent to remove only those two, and then update the rest that legitimately need to be updated? Why they are listing like this I'm afraid I haven't a clue. My first thought would be to remove them and then reinstall if needed. Any thoughts and replies are appreciated. Am still learning, and thanks to all for their patience.
 
You must log in or register to reply here.
Back
Top