Mistakenly deleted some contents of OS sub-directory

Hi

Did rm -rf /usr/local/* in error.

Lost GUI after reboot. But able to login via terminal.

Some of the previously installed packages also don’t run correctly!

How to mitigate the issue? If possible will rebuilt of
Code:
/usr/local/*
work?

Thanks
rraj
 
If you don't have zfs snapshot, try:

su -
pkg prime-list > pkg-list.txt
pkglist=$(cat pkg-list.txt)
pkg install $pkglist
 
You basically ended up with a base FreeBSD system without ports. I think you should be able to rebuild your installation by re-creating /usr/local/etc/pkg/repos/FreeBSD.conf
and do a pkg upgrade -f .

Best option is, of course, restore from backup.
 
From under /var/db/, you may have to clear out ports/ and pkg before installing your ports and packages. Not sure about /var/cache/pkg/.

The important seed files to save next time are under /usr/local/etc/, but these are easier to configure than the /etc/ directory is.
 
Sorry, I only now remembered that ' prime-list' is an alias which resided in /usr/local/etc/pkg.conf so if there is nothing under /usr/local/ this will not work.

Instead of ' pkg prime-list' try with:

pkg query -e '%a = 0' '%n' > pkg-list.txt
 
Last edited:
That's bad.

Like fmc000 said, you end up with a basic system, and killed (almost) everything else.
That's why you can still login, but have no GUI anymore, because also completely removed X11, its config, and all what belongs to it...and many things more...
/usr/local/ does not contain the ports tree - that was the least problem to reinstall that:
After you installed gitup just do a gitup quarterly -c and your ports tree is back and usable again.


Best was, as fmc000 also already said: restore from backups. Maybe there is a snapshot you can fall back on.

Besides /home/ where my production data lives, I additionally also backup regulary all the config stuff I spent time on: /etc/, of course, also /var/cron/tabs/ (if you're using cron), and as sidetone also mentioned /usr/local/etc/ because that's where not only but above all X11's config lives.

If you don't have any copy of that directory, you need to at least reinstall all packages again. Then it's unvoidable to do all the config you spent time on again all by scratch again. In many cases it will be done when your X11 runs again as you are used to.

To put something positive into it:
This is an important learning experience on unix[like] systems. I guess every BSDer/Unixer at least once killed a crucial directory by accident 😁
The best part: You now learned to be really careful with your user root. Such will not happen again. :cool:

Tips:
- my user root's shell prompt is set to yellow text on red background, to see directly: "This is a root's shell!"
- as root change into the directories you're going to do work in. Many pathes start with / If using long path names it can cause larger damages if you hit the return button by accident before finished typing, especially on using something like rm -Rf :cool:
As root always use rm as rm [ ] ./[ ]

-Backups! Backups! Backups! DO BACKUPS!
To reconsider, test, adapt, upgrade, and improve your backup plan is a continous escorting #1 top priority job on all computer systems - no matter how stable they are. #1 reason by far for the need of backups are neither hacker attacks, nor hardware failures, but stupid accidents like this one.

If things like this happen - and they happen! sooner, or later to everybody 🤓,
it's either no big deal, because there are backups you can fall back on, and restore all quickly and easy,
or - if not - your backup plan is insufficient, and urgently needs to be revised, adapted, and upgraded.
 
Last edited:
Hi
You basically ended up with a base FreeBSD system without ports. I think you should be able to rebuild your installation by re-creating /usr/local/etc/pkg/repos/FreeBSD.conf
and do a pkg upgrade -f .

Best option is, of course, restore from backup.
Hi fmc000

Already tried that but no luck!

Thanks
rraj
 
Basically, vmisev's way on comment #2 (with amendment in #5) would work, but AFTER bootstrapping pkg with pkg bootstrap -f, as /usr/local/sbin/pkg is gone.

This command should work if you just deleted /usr/local/, because there's /usr/sbin/pkg just for bootstrapping (installing) /usr/local/sbin/pkg for the running version of FreeBSD.

And databases for installed packages are stored under /var/db/pkg/, thus, wouldn't have been lost with your operation. This is why I estimate that vmisev's way would work.

Not 100% sure, but using pkg upgrade -f can fail, as old version to be deleted are already gone, thus, possibility to error out is not purely zero (hope lim0, though).
 
Sorry, I only now remembered that 'prime-list' is an alias which resided in /usr/local/etc/pkg.conf so if there is nothing under /usr/local/ this will not work.

Instead of 'pkg prime-list' try with:

pkg query -e '%a = 0' '%n' > pkg-list.txt
Hi vmisev

Sorry did not work out!

No effect visible.

Thanks
rraj
 
pkg query -e '%a = 0' '%n' > pkg-list.txt
Hi vmisev

Sorry did not work out!

No effect visible.

Thanks
rraj
That one line, by itself, will only make file pkg-list.txt. But, T-Aoki is right, you need to bootstrap pkg again, I forgot about that “smal” detail as well 🤦‍♂️ So, try:
su -
pkg bootstrap -f
pkg query -e '%a = 0' '%n' > pkg-list.txt
pkglist=$(cat pkg-list.txt)
pkg install $pkglist
 
Last edited:
That one line, by itself, will only make file pkg-list.txt. But, T-Aoki is right, you need to bootstrap pkg again, I forgot about that “smal” detail as well 🤦‍♂️ So, try:
su -
pkg bootstrap -f
pkg query -e '%a = 0' '%n' > pkg-list.txt
pkglist=$(cat pkg-list.txt)
pkg install $pkglist
Hi vmisev

Apart from pkg bootstrap everything went as usual.

Still no luck!

Thanks
rraj
 
That's bad.

Like fmc000 said, you end up with a basic system, and killed (almost) everything else.
That's why you can still login, but have no GUI anymore, because also completely removed X11, its config, and all what belongs to it...and many things more...
/usr/local/ does not contain the ports tree - that was the least problem to reinstall that:
After you installed gitup just do a gitup quarterly -c and your ports tree is back and usable again.


Best was, as fmc000 also already said: restore from backups. Maybe there is a snapshot you can fall back on.

Besides /home/ where my production data lives, I additionally also backup regulary all the config stuff I spent time on: /etc/, of course, also /var/cron/tabs/ (if you're using cron), and as sidetone also mentioned /usr/local/etc/ because that's where not only but above all X11's config lives.

If you don't have any copy of that directory, you need to at least reinstall all packages again. Then it's unvoidable to do all the config you spent time on again all by scratch again. In many cases it will be done when your X11 runs again as you are used to.

To put something positive into it:
This is an important learning experience on unix[like] systems. I guess every BSDer/Unixer at least once killed a crucial directory by accident 😁
The best part: You now learned to be really careful with your user root. Such will not happen again. :cool:

Tips:
- my user root's shell prompt is set to yellow text on red background, to see directly: "This is a root's shell!"
- as root change into the directories you're going to do work in. Many pathes start with / If using long path names it can cause larger damages if you hit the return button by accident before finished typing, especially on using something like rm -Rf :cool:
As root always use rm as rm [ ] ./[ ]

-Backups! Backups! Backups! DO BACKUPS!
To reconsider, test, adapt, upgrade, and improve your backup plan is a continous escorting #1 top priority job on all computer systems - no matter how stable they are. #1 reason by far for the need of backups are neither hacker attacks, nor hardware failures, but stupid accidents like this one.

If things like this happen - and they happen! sooner, or later to everybody 🤓,
it's either no big deal, because there are backups you can fall back on, and restore all quickly and easy,
or - if not - your backup plan urgently needs to be revised, and adapted.
Hi Maturin

Your detailed reply is much appreciated. Promise to incorporate the suggestions.

Wanted to update about the gitup command as mentioned in your post. It returns that
Code:
/usr/ports
contains files, to remove them to proceed. rm -rf /usr/ports/* does not work here as intended. Even rm -Rf does no good to the situation as it seems!

How do i go forward?

Thanks
rraj
 
Hi vmisev

Apart from pkg bootstrap everything went as usual.

Still no luck!

Thanks
rraj
You are not telling us much.

What was the output of pkg bootstrap -f, what is a content of your pkg-list.txt made by pkg query -e '%a = 0' '%n' > pkg-list.txt, and what was the output of pkg install $pkglist?
 
Last edited:
You are not telling us much.

What was the output of pkg bootstrap -f, what is a content of your pkg-list.txt made by pkg query -e '%a = 0' '%n' > pkg-list.txt, and what was the output of pkg install $pkglist?
Hi vmisev

Sorry for not being specific!

bootstrap says version already installed, just reinstalled the same. Basically the latest one.

Can’t locate pkg-list.txt.

pkg install mentioned therein, says most recent version already installed.

Hope this helps.

Thanks
rraj
 
OK, lets do it step by step.
First are you the root user and in the /root directory? You should be if you did su - first.
Do
su -
enter root password and check who and where you are with
whoami; pwd
If output is
root
/root
Then check that you are using sh shell
echo $SHELL
Output should be
/bin/sh
Then do
pkg query -e '%a = 0' '%n'
You should see bunch of packages listed in the console. If that works, do
pkg query -e '%a = 0' '%n' > pkg-list.txt
ls
If pkg-list.txt is there, do
cat pkg-list.txt
Output should be same as just pkg query without redirection.
Then make variable with a contest of that file:
pkglist=$(cat pkg-list.txt)
check that variable has right content with
echo $pkglist
If you see number of packages printed in one long line, proceed with
pkg install -f $pkglist
 
Last edited:
Wanted to update about the gitup command as mentioned in your post.
It's not so much an "upgdate", as a complete deletion of the ports tree, and then a complete new installation of it.
rm -rf /usr/ports/* does not work here as intended.
I crossed it out this of my post again, since ports don't live under /usr/local/, what as you was saying was the "only" directory you killed. So there was no need to reinstall the ports tree. But since you did a rm -Rf on it, now there is.
Change into the ports tree cd /usr/ports/, check if it's empty ls -la I bet you'll see some files left - those may the reason why it fails. Delete them all by hand, then repeat the gitup command I posted above (Of course gitup needs to be installed first, since it's not part of the basic system, which may the other cause why this fails if it's not.)

It was a lot more helpful if you could post the error messages you receive instead of just saying 'it fails.'

For the case if and when all other help here posted fail, I like to add the "cracauer@"-solution as an option to this topic:
Before you consider to kill your disk, to reinstall completely new by scratch, it was worth as some kind of a last try: Just overwrite your killed directories (/usr/local) from another basic installation (same FreeBSD version!), e.g. a USB flash drive you dd the according imagefile to (it's in the HB how this is done.)
This way you get some basic /usr/local/ maybe again working insofar, so you can install packages again.

With FreeBSD there always is a way. But it depends on the ratio between the damage and the individual's experience of the system if a reinstallation wasn't the better/quicker way.
Don't forget to always backup your current system to another storage first, before you try any stunt like this! There will be the one or the other useful file you may miss later.

Of course, your /home/ and other any even remote valuable data containing directories are not going to be touched, and certainly being already part of your backup plan anyway, naturally, of course.
 
OK, lets do it step by step.
First are you the root user and in the /root directory? You should be if you did su - first.
Do
su -
enter root password and check who and where you are with
whoami; pwd
If output is
root
/root
Then check that you are using sh shell
echo $SHELL
Output should be
/bin/sh
Then do
pkg query -e '%a = 0' '%n'
You should see bunch of packages listed in the console. If that works, do
pkg query -e '%a = 0' '%n' > pkg-list.txt
ls
If pkg-list.txt is there, do
cat pkg-list.txt
Output should be same as just pkg query without redirection.
Then make variable with a contest of that file:
pkglist=$(cat pkg-list.txt)
check that variable has right content with
echo $pkglist
If you see number of packages printed in one long line, proceed with
pkg install -f $pkglist
Hi vmisev

Thanks for showing interest in your responses.

Output for all the commands except the pen-ultimate one matches expected results. The exception one yields same list of packages as the previous command but with a horizontal orientation. Looks that’s the one which needs fine tuning.

I guess no point running the last one, given the current scenario.

Thanks
rraj
 
pkg install $pkglist
You have to force install them. According to pkg(8) (database at /var/db/pkg/local.sqlite) those packages are already installed. Doesn't matter if the actual files are gone, the package is registered as being installed. You have to force in order to reinstall.

Code:
     -f, --force
                Force the reinstallation of the package if already installed.
pkg-install(8)

Probably the best and easiest way to restore everything is to pkg upgrade -f
This will download and reinstall and/or upgrade everything you had installed.

Code:
     -f, --force
                 Force the reinstallation or upgrade of the whole set of
                 packages.
pkg-upgrade(8)
 
Can’t locate pkg-list.txt.
locate(1) is NOT a good tool here.

If I read the codes, configs and related scripts correctly, it uses a database of files that are updated in nightly job. Files created after the DB updates wouldn't be found. This is because locate(1) pre-generated DB instead of scanning filesystem on-the-fly to make it far more faster.

Use find(1) instead. It is far more slower than locate(1), but finds newly created files as it "actually scans" under the directory specified on running.

And as of the command line already given, the redirected file should be generated directly under the current working directory you're on.
If you don't have write access priviledge there, the redirection should be errorer out and nothing would be generated. So su to root is already adviced.
 
You have to force install them. According to pkg(8) (database at /var/db/pkg/local.sqlite) those packages are already installed. Doesn't matter if the actual files are gone, the package is registered as being installed. You have to force in order to reinstall.

Code:
     -f, --force
                Force the reinstallation of the package if already installed.
pkg-install(8)

Probably the best and easiest way to restore everything is to pkg upgrade -f
This will download and reinstall and/or upgrade everything you had installed.

Code:
     -f, --force
                 Force the reinstallation or upgrade of the whole set of
                 packages.
pkg-upgrade(8)
You are absolutely right, but I already corrected myself in #16
If you see number of packages printed in one long line, proceed with
pkg install -f $pkglist
 
You have to force install them. According to pkg(8) (database at /var/db/pkg/local.sqlite) those packages are already installed. Doesn't matter if the actual files are gone, the package is registered as being installed. You have to force in order to reinstall.

Code:
     -f, --force
                Force the reinstallation of the package if already installed.
pkg-install(8)

Probably the best and easiest way to restore everything is to pkg upgrade -f
This will download and reinstall and/or upgrade everything you had installed.

Code:
     -f, --force
                 Force the reinstallation or upgrade of the whole set of
                 packages.
pkg-upgrade(8)
Hi SirDice

Thanks for the advice!

Package upgrade force did some newer pkg’s albeit not all as were before, as were this time.

Still no luck contents of /usr/local are the same as before, looks like nothing much as visible has changed.

Thanks
rraj
 
Hi SirDice

In reference to your last post, may i assume that only the recently installed pkg list is available and all the pkg's install list since OS's install are lost.

Thanks
rraj
 
Hi SirDice

In reference to your last post, may i assume that only the recently installed pkg list is available and all the pkg's install list since OS's install are lost.

Thanks
rraj
Not every records would be preserved, but all info about "what was installed at the moment you missingly deleted /usr/local" should be kept at least at the moment.
 
Back
Top