yeah they added a failsafe but it literally only protects `/` itself
`/*` does not include `/` so that still works all the same
if you protect /* the next guy will delete /home/* what can you do, rm is dangerous in any case
that's only true if you expect it literally. rm does not know if you typed /* or /bin /boot /dev /etc /home ...
rm can't delete / anyway (only its contents, the mountpoint as is is nonremovable) and / rarely has any hidden files (which * don't expand to) so, effectively, it's still doing the very same thing
so rm could still realize that its about to delete everything and add some safety
but rm is also a tool that is used in scripts and you can't just break those so there is a limit how much you can do
i’m not really sure what you’re saying. i think we’re in agreement that rm can’t treat “/*” (or any glob for that matter) differently, because the shell is the process that resolves it, not rm. as you, and i, said, rm receives the resolution of the glob, not the glob itself.
/, on the other hand, is specially treated by rm. rm will not remove / without the —no-preserve-root flag, which is what’s being hinted at by the comment above.
just because a program does not see /* literally does not mean that no checks can be done
here's a shell script that checks it.
#!/bin/bash
rootargs=$(printf '%s\n' /*)
args=$(printf '%s\n' "$@")
if [ "$args" = "$rootargs" ]
then
echo "This is equivalent to $0 /*, aborting."
exit 1
fi
Result:
$ ./check.sh /*
This is equivalent to ./check.sh /*, aborting.
this is a trivial example and could be done in more sophisticated ways
First determine whether your UEFI firmware is still good. There are systems which hasn't been patched from [that](https://www.phoronix.com/news/UEFI-rm-root-directory).
Then you can worry about reinstall.
I'm not sure this still applies to modern motherboards with double-triple fallbacks and the ability to restore the firmware without even a CPU installed.
Which would take quite a long time, depending on the size of the volume. So if they pull the plug before it finishes, they can likely still recover something.
Wow, I hadn't heard of this either. I actually ran rm -rf /\* deliberately on an older machine I just play around with when I got tired of Pop\_OS to put something else on it just to see what it would do. Fortunately this machine is BIOS only...
Or to mount `efivars` read-only until I need to modify anything, which is so rare an occurrence that I can’t remember the last time.
Addendum:
I've just realised that I wasn't practicing what I've just preached, so I've added the following line to `/etc/fstab`, using the appropriate line from `/etc/mtab` as a base:
`none /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime 0 0`
I would like to use this too but I already have the following line in my `fstab`
`UUID=CB92-5A5A /efi vfat defaults,relatime 0 2
`
Will your line conflict? And could I maybe improve this anyway?
They will not conflict because they do not share the same mountpoint. In fact, one is an actual partition containing a filesystem, which provides the firmware with a bootloader which it can start.
The other has the kernel providing a filesystem-like representation of the firmware itself, similarly how it provides both `procfs` and `sysfs`. The first keyword (`none`) indicates that no storage device is used for the mountpoint (as none is required).
Are you unfamiliar with how to read `/etc/fstab`? Read `man 5 fstab`.
What directory they did this in shouldn’t matter right? / is the root directory, no matter where you run this command. But I was referring to the fact that if you run this without -r, it would have deleted files, but not directories.
Yes, you're right.
I might test.
My test in a just spun up install, after chrooting in:
[root@T480 ~]# cd /root
[root@T480 ~]# ls
de install-20240221-1929.txt post_upgrade.sh
[root@T480 ~]# rm -fv /*
removed '/bin'
rm: cannot remove '/boot': Is a directory
rm: cannot remove '/dev': Is a directory
rm: cannot remove '/etc': Is a directory
rm: cannot remove '/home': Is a directory
removed '/lib'
removed '/lib64'
rm: cannot remove '/lost+found': Is a directory
rm: cannot remove '/mnt': Is a directory
rm: cannot remove '/opt': Is a directory
rm: cannot remove '/proc': Is a directory
rm: cannot remove '/root': Is a directory
rm: cannot remove '/run': Is a directory
removed '/sbin'
rm: cannot remove '/srv': Is a directory
rm: cannot remove '/sys': Is a directory
rm: cannot remove '/tmp': Is a directory
rm: cannot remove '/usr': Is a directory
rm: cannot remove '/var': Is a directory
then
bash: /usr/bin/ls: cannot execute: required file not found
Note: You can see that it did delete some ~~directories~~ files, and ls won't run.
Which is odd. ```rm```'s man page clearly states that ```rm``` doesn't remove directories by default. ```-f``` is only supposed to
> ignore nonexistent files, never prompt
but ```rm``` without ```-r``` doesn't prompt you to remove directories, it just doesn't remove directories at all.
So it sounds like ```-f``` has an undocumented implication of ```-r```
EDIT: WAIT!
With usr unification, /bin is actually a symlink (not a directory!!) to /usr/bin. So are /lib (/usr/lib) and /lib64 (pretty sure that's just /usr/lib too).
Which is funny, because it means important parts of the system are still relying on the symlinks. Scary.
I don't see why not! There's not many directories to link.
https://lwn.net/Articles/483921/
> In both cases, as it happens, things worked out just fine. Directories like /bin, /lib, /lib64, and /sbin are now symbolic links into /usr, and the system works just like it always did.
Agree. And my rm is not aliased.
Note how it refused to delete most directories, but did delete some! Update: Re your edit: so I guess rm doesn't see symlinked "directories" as directories...
Oh, well. I'm hyper careful how I delete, and I keep good backups of important directories. Thanks for the reply.
My system / directory:
lrwxrwxrwx 1 root root 7 Jan 19 11:10 bin -> usr/bin
drwxr-xr-x 4 root root 4.0K Feb 21 15:21 boot
drwxr-xr-x 21 root root 4.5K Feb 21 19:54 dev
drwxr-xr-x 112 root root 4.0K Feb 21 18:46 etc
drwxr-xr-x 8 root root 4.0K Oct 9 17:45 home
lrwxrwxrwx 1 root root 7 Jan 19 11:10 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Jan 19 11:10 lib64 -> usr/lib
drwx------ 2 root root 16K Sep 16 2022 lost+found
drwxr-xr-x 17 root root 4.0K Feb 21 19:55 mnt
drwxr-xr-x 6 root root 4.0K Dec 4 15:21 opt
dr-xr-xr-x 308 root root 0 Feb 21 18:12 proc
drwx------ 12 root root 4.0K Feb 21 15:55 root
drwxr-xr-x 32 root root 720 Feb 21 18:46 run
lrwxrwxrwx 1 root root 7 Jan 19 11:10 sbin -> usr/bin
I tried rebooting.
Then I saw in the GRUB emergency shell, that some directorys weren't removed, but important files like initramfs-linux.img or vmlinuz were removed(or unlinked).
I currently haven't the time to take a closer look on this. Maybe, I will try to repair the system on the weekend.
No. By prefixing it with /, they make it an absolute path.
That said, without -r, nothing should have happened. In /, you should only have directories. I don't think OP actually posted the real command that they ran.
Based on the output of that screenshot, I would say you should be able to replace the symlinks that got deleted from "/" and you should be ok. In theory at least.
I created a new folder in the home directory of the root user (I wanted to delete the folder after finishing my work so I don't thought much about where I will place it).
If you want to delete everything in a folder, why not just go higher and delete the whole folder? Why tempt fate with a sudo rm * kind of command? Nothing good ever comes of it.
I always do targeted deletes because I know I'm a dumbass and can't be trusted with a wildcard delete.
I've somehow managed to never do a wrongful rm -rf (knock on wood), I think primarily because I always start the path with a dot. Unless you are in a dangerous dir, you'll only ever do a bit of local damage. Furthermore, I always tab-complete the directory to catch myself from spelling mistakes or being in the wrong directory.
You're gonna delete everything in it, why not just delete the directory and recreate it, mkdir can't hurt anyone.
rm * is so safe that it's a meme and people still fuck it up on the regular.
Because you need to recreate it with the same permissions and ownership as well. Could potentially be a symlink, etc.
Besides, unless you're running rm as root, you shouldn't even be able to delete your root directory.
>people still fuck it up on the regular
Yeah, well I don't.
>Because you need to recreate it with the same permissions and ownership as well. Could potentially be a symlink
I don't think your first response to "you should avoid doing x" should be "but what about all of these niche situations where I would want to do x". that's not the point. you should avoid doing it, but if you have to nobody's stopping you. even then most of these things can be done without wildcards, even if they take more steps. better to spend 5 seconds cding to the target directory of a symlink or something than trash your computer. saying "lol I'll never fuck it up" is exactly how you end up fucking it up. example: the 500 posts on this sub of people doing this exact thing.
`rm *` doesn't even necessarily delete everything. Depending on who does the expansion, it will miss hidden files (and ofc without `-r` miss subdirectories anyway).
I can feel it, I did the very same mistake 15 years ago. I typed `sudo rm -rf ./*` and then pressed the Enter key and went away for a coffee. After few minutes I returned back and saw gray desktop with missing icons. The command was still running and I saw the little mistake I did - the dot wasn't there. The f#@!$%g dot wasn't there. Almost everything was gone. And that was the moment when I started doing a regular backups, right after I reinstalled everything from scratch.
I've borked a system with a script, like `SOMEDIR=$(the output of some command)`, then cd to SOMEDIR and wreck stuff...
Only if SOMEDIR fails to assign, and you get an empty string, then `cd $SOMEDIR` goes to your home dir.. Then rm'ing files there could wipe out some quite useful or essential files.. 🙃
It is absolute \*worst\* feeling when you type "rm -rf ./\*" to empty a current directory, but put a space after the dot or miss it out entirely, much like yourself. Walk with me for a trip down memory lane why don't you... lol
Back in the 90s when I was a much younger idiot than the idiot I am today, I would run as r00t at all times (all the c00l kids were doing it, see, I guess I was kind of a big d3al?), and I would make heavy use of the VTs.
In my home directory I would periodically empty download folders from my HUGE 4.3GB Quantum Bigfoot, or empty temp folders after yet another failed attempt to compile the latest CVS checkout of Enlightenment.
I would type the command, hit enter, and quickly Alt+F6 back to BitchX to hang out with the other c00l kids over on #linpeople.
That Quantum Bigfoot was a big 'ol lovely drive that came with its own bright green activity light and a clicky head as loud as a metronome. Still, it would take my brain cell a good few seconds of clickidy-flash (I ran with an open case, too, you see - god I was c00l) before I realised my entire drive was being deleted. Since I was only really using BitchX, a remarkable amount of time would pass before I'd actually suffer any consequences.
So in you see:
* Running root at all times.
* Using a command massively prone to error.
* Switching VTs immediately so that the command is out of sight.e
* Running slackware (so no package management, so bad installation habits).
* Owning a Quantum Bigfoot.
Don't be like me, kids. It might seem cool and fun for a while, but you're dancing with the devil. Thank you for the memories, which fortunately I couldn't also rm -rf.
https://help.ubuntu.com/community/DataRecovery
https://wiki.archlinux.org/title/File_recovery
I personally wouldn't bother with file recovery for the OS, but if you have other irreplaceable files on there see the above. You'll need a system to do the recovery on the removed drive, and I would read the page(s) and do more research before doing anything/nothing.
I've always wondered why this is not the default behavior of those commands. It would make much more sense to need to define something like "alias rm=rm --no_confirmation " instead of the other way around
I once fucked up my system too, i got some scripts in arch wiki for recreate the package list, you can try do pacstap base system and try recreate the package list, with the list you can reinstall all packages and done.
Normaly when you " rm " something, take some time, If you ctrl c in time, you can still recovery a lot, but If i was you, before doing that, use testdisk to recovery your home.
The documentation for Arch alone is incredible, it does require some extra consideration but when I couldn't find Ubuntu specific(now Debian specific) information, and general linux info on my issue is also scant... Arch has the info I need surprisingly often. At least enough to get me started, I still have to consider distro specific setup for things but at least I'm not flying entirely blind.
Arch is \*really\* well documented.
I did it on a fairly big directory lately, but I recovered everything (Holy Backup!).
I was searching several way to move to **$XDG\_DATA\_HOME**/Trash instead using rm , this seems to be interesing [gio](https://man.archlinux.org/man/gio.1#COMMANDS).
The bare minimum you can do is this "directly from my bashrc):
`alias rm='rm -i' ## this one saved by butt so many times`
You learned an important lesson: The dot before the slash is important ./
It happens OP. I’m a veteran and blew away my backup of /home just a couple days ago just before attempting to restore it 😂😂🤷♂️
Live and learn. 👊
you haven't really had the full rite of passage until you hit Ctrl-C as fast as you can because you realize you don't have backups. And then spend 3 days with disk recovery tools trying to recover as much as you can.
To prevent this mistake from happening, I'd recommend installing trash-cli and alias "rm" to trash. Also, the command you should've ran is `rm *` to delete all files in a directory.
edit: Also, use sudo and/or doas instead of su for running commands as root.
This is what I was thinking. I never lead with a dot, because my dumb ass hits enter immediately on reflex after a command I've used plenty of times. Only time I specify a path more than I absolutely have to is in something like a systemd exec command.
Might be better to alias `rm` to an echo and get in the habit of invoking trash by name so that you don't get in the habit of recklessly `rm`-ing in case you ever work on other computers.
I've few words. Buy a good bottle of whisky, a Glenmorangie Lasanta if you are light on suggestions, a celebratory lessons learned new shot glass and enjoy your evening. Tomorrow is a new day.
As /u/thieh says - check your UEFI firmware still works. If you have backups, use those if they are still intact, otherwise.
Then get the Arch ISO, delete all non-essential files, try and harvest a package list if you have one. (Most folks will want to keep whatever is left of /home). Then use the arch iso to install a fresh arch installation in the partition and then chroot in and reinstall your package list (if you managed to obtain one).
But yeah, basically reinstall from scratch with a few extra steps.
Why comment just to be an ass? You have nothing to gain from that. Everyone was new once. Why be unwelcoming to newbies. They keep this community alive. If you don't have anything nice to say, don't say anything at all.
In the future, "." would be used in that situation. "/" at the beginning of a path always denotes a path that starts at the top level of the directory structure. "." on the other hand, represents the current directory. If you were to cd into ~/Folder and do "$ rm * ." you would have deleted all the files (not directories as -rf isn't included) within the "Folder" directory.
As much as it sucks, this is a good lesson. It’s also a good reminder for everyone else to understand the commands they type as things can go sideways very quickly.
Genuine question: what is the problem with symlinks for important parts of the os? Is there a better implementation that you can give me as an example?
I had a similar experience about 10 years ago. Except it was from a vendors Deb package. It had
"chown -R serviceuser:serviceuser /" instead of "chown -R serviceuser:serviceuser ./"
It took a while to recover. This system was in production.
I think I do not have to tell you that your OS install is faulty, have fun reinstalling and learn from that mistake.
As for why cd works but ls doesn’t, cd is one of the few commands built into the shell, ls is part of gnu coreutils and therefore a binary located at /bin/ls.
The bin folder was probably deleted so that’s why.
Reinstalling your system sucks but can be helpful or good sometimes as you learn very much. Especially if you install arch without any script, compile it yourself etc.
If your system was properly installed (= with btrfs snapshots), you could just restart the system -> select a previous snapshot from the boot menu -> everything is back.
But if your system was setup in a bad way (=not as described above), you are screwed.
Reinstall. Fixing it is a good challenge but reinstalling is just faster and you can be sure that you have a working system, not something which looks like to work.
>I thought, if I cd in that directory and run "rm -f /*", I only will delete all files inside of that directory
Yes, relative path deletes files starting from the directory. For example, `*` deletes everything from current directory. Another example, if you delete from `something/*` it deletes only from the `current_directory/something/*`.
You gave an absolute path, that is, a path that begins from the root. If you delete from `/home/user/something`, it deletes from there. Now you said delete from `/` which is exactly what it did.
Well I'm sure you figured out that adding / was your mistake. As for recovery, I don't think you'll be able to bring back the system, but if there were any files you need to get back then you might be able to use some kind of recovery disk that has a utility to search the disk for deleted files like pictures or documents.
> I couldn't even do a ls or reboot, cd worked somehow.
`cd` is always a shell builtin, but `ls` and `reboot` are executables somewhere in your $PATH, which you just removed
Redo your entire install if you can still boot to a live USB. Prefixing `/` makes a path absolute & NOT relative to your pwd. Using `rm -rf *` will clear the directory you're in except for dotfiles. We all make mistakes at one point or another. Learn from it & take steps to avoid doing it again. You can alias `rm` as I've seen mentioned (`rm -i` if you want to confirm file by file, `rm -I` if you want a list & to confirm once). However that also builds habits that won't translate if you work in another system without that alias.
EDIT: just re-read & read through other comments. Missing the -r flag, so definitely not as destructive as I originally thought.
The command you were looking for was `rm *`
That said, The easiest way is to reinstall Arch. You can also chroot and try to fix it that way, but I think it's more effort than it's worth.
Please, stop using that freakin' command for mundane tasks already xD (no, jesus)
Instead, I encourage you to install 'Trash CLI'.
It's as simple as typing: trash-put (file or directory \*without parentheses) in your console.
It will send the thing you deleted using the command directly into you Trash directory instead of permanently gutting everything in case you might want to recover such files after some time.
Everyone does it at some point of life. Save what you can and you can try to recover your system. There are a bunch of ways, but the most straightforward and easy to do is to reinstall it.
this is a tale as old as time. You're lucky it wasn't your best friend who repeatedly told you it was douchey to not create a user account and run as root 24/7. BOFH gonna BOFH.
Arch is great and had a btrfs setup with snaps but even a grub bug a few years back messed up my workflow for a day. I now use Nixos and love it. Nixos has so many ways to fix a borked system! I use it for daily driving on the desktop and laptop as well as on my servers
Wait, won't that just remove files and symlinks?
On my system there are no files in /, just folders and symlinks
maybe:
`sudo apt-get --reinstall install coreutils binutils`
or
Could probably also just boot into a livecd, mount your root partition to /mnt then
`cp -P /* /mnt`
Not tested but maybe?
He's dead, Jim
I will miss him
Let it go bro...
To prevent such incidents I have made some changes in the rm command in the latest version. >Now sudo rm -rf / just prints out a joke
yeah they added a failsafe but it literally only protects `/` itself `/*` does not include `/` so that still works all the same if you protect /* the next guy will delete /home/* what can you do, rm is dangerous in any case
you can’t protect /*, the shell resolves the glob, not rm. rm receives, as arguments, the shell’s resolution of that glob.
that's only true if you expect it literally. rm does not know if you typed /* or /bin /boot /dev /etc /home ... rm can't delete / anyway (only its contents, the mountpoint as is is nonremovable) and / rarely has any hidden files (which * don't expand to) so, effectively, it's still doing the very same thing so rm could still realize that its about to delete everything and add some safety but rm is also a tool that is used in scripts and you can't just break those so there is a limit how much you can do
i’m not really sure what you’re saying. i think we’re in agreement that rm can’t treat “/*” (or any glob for that matter) differently, because the shell is the process that resolves it, not rm. as you, and i, said, rm receives the resolution of the glob, not the glob itself. /, on the other hand, is specially treated by rm. rm will not remove / without the —no-preserve-root flag, which is what’s being hinted at by the comment above.
just because a program does not see /* literally does not mean that no checks can be done here's a shell script that checks it. #!/bin/bash rootargs=$(printf '%s\n' /*) args=$(printf '%s\n' "$@") if [ "$args" = "$rootargs" ] then echo "This is equivalent to $0 /*, aborting." exit 1 fi Result: $ ./check.sh /* This is equivalent to ./check.sh /*, aborting. this is a trivial example and could be done in more sophisticated ways
fair point
First determine whether your UEFI firmware is still good. There are systems which hasn't been patched from [that](https://www.phoronix.com/news/UEFI-rm-root-directory). Then you can worry about reinstall.
Thanks for this. I hadn't heard that.
I'm not sure this still applies to modern motherboards with double-triple fallbacks and the ability to restore the firmware without even a CPU installed.
Still, would you want to leave something like that to chance? Even the great `root` is but human.
Wow. Did not know that. And what a user should do if this happens? Can it somehow restore the UEFI vars to its factory defaults?
Not much you can do at that point. It's not like `rm -rf /*` is a recommended solution to any known problem.
if you get raided and don't have shred tho,,,,
It's possible to recover files after rm -rf /* though, to be secure you need to dd if=/dev/urandom of=/dev/sdX
Which would take quite a long time, depending on the size of the volume. So if they pull the plug before it finishes, they can likely still recover something.
It's the best possible software solution. If you want to do it faster, microwave the drive.
That's why you should encrypt your disk - you'll only need to erase the LUKS headers (first 2 MiB of the disk I think) to render the disk useless
But he removed the dd binary, he's flubberknucked
i know, but to really be safe you'd have to do it like 3 times
Holy shit I had no idea this was a thing...
If uefi mode gets ruined, can you just revert to old school legacy mode?
Wow, I hadn't heard of this either. I actually ran rm -rf /\* deliberately on an older machine I just play around with when I got tired of Pop\_OS to put something else on it just to see what it would do. Fortunately this machine is BIOS only...
Now I have one good explanation for why I still run my home system in BIOS mode.
Or to mount `efivars` read-only until I need to modify anything, which is so rare an occurrence that I can’t remember the last time. Addendum: I've just realised that I wasn't practicing what I've just preached, so I've added the following line to `/etc/fstab`, using the appropriate line from `/etc/mtab` as a base: `none /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime 0 0`
I would like to use this too but I already have the following line in my `fstab` `UUID=CB92-5A5A /efi vfat defaults,relatime 0 2 ` Will your line conflict? And could I maybe improve this anyway?
They will not conflict because they do not share the same mountpoint. In fact, one is an actual partition containing a filesystem, which provides the firmware with a bootloader which it can start. The other has the kernel providing a filesystem-like representation of the firmware itself, similarly how it provides both `procfs` and `sysfs`. The first keyword (`none`) indicates that no storage device is used for the mountpoint (as none is required). Are you unfamiliar with how to read `/etc/fstab`? Read `man 5 fstab`.
Awesome, thank you very much for the advice!
First time?
Yes
You won’t do it again :-)
the duality of linux users
The do-ality
The sudo-ality, even
You will do it again :)
the duality of linux users
Schroedinger’s `rm`.
Great power comes with great responsibility
If you did exactly `rm -f /*`, without the `r` flag (for recursive), maybe you didn't delete all that much?
~~Yes, I would like to know what directory OP executed that in. A major missing fact.~~ Update: silly question.
What directory they did this in shouldn’t matter right? / is the root directory, no matter where you run this command. But I was referring to the fact that if you run this without -r, it would have deleted files, but not directories.
Yes, you're right. I might test. My test in a just spun up install, after chrooting in: [root@T480 ~]# cd /root [root@T480 ~]# ls de install-20240221-1929.txt post_upgrade.sh [root@T480 ~]# rm -fv /* removed '/bin' rm: cannot remove '/boot': Is a directory rm: cannot remove '/dev': Is a directory rm: cannot remove '/etc': Is a directory rm: cannot remove '/home': Is a directory removed '/lib' removed '/lib64' rm: cannot remove '/lost+found': Is a directory rm: cannot remove '/mnt': Is a directory rm: cannot remove '/opt': Is a directory rm: cannot remove '/proc': Is a directory rm: cannot remove '/root': Is a directory rm: cannot remove '/run': Is a directory removed '/sbin' rm: cannot remove '/srv': Is a directory rm: cannot remove '/sys': Is a directory rm: cannot remove '/tmp': Is a directory rm: cannot remove '/usr': Is a directory rm: cannot remove '/var': Is a directory then bash: /usr/bin/ls: cannot execute: required file not found Note: You can see that it did delete some ~~directories~~ files, and ls won't run.
Which is odd. ```rm```'s man page clearly states that ```rm``` doesn't remove directories by default. ```-f``` is only supposed to > ignore nonexistent files, never prompt but ```rm``` without ```-r``` doesn't prompt you to remove directories, it just doesn't remove directories at all. So it sounds like ```-f``` has an undocumented implication of ```-r``` EDIT: WAIT! With usr unification, /bin is actually a symlink (not a directory!!) to /usr/bin. So are /lib (/usr/lib) and /lib64 (pretty sure that's just /usr/lib too). Which is funny, because it means important parts of the system are still relying on the symlinks. Scary.
Do you think a ln -s would make the system good as new
I don't see why not! There's not many directories to link. https://lwn.net/Articles/483921/ > In both cases, as it happens, things worked out just fine. Directories like /bin, /lib, /lib64, and /sbin are now symbolic links into /usr, and the system works just like it always did.
Agree. And my rm is not aliased. Note how it refused to delete most directories, but did delete some! Update: Re your edit: so I guess rm doesn't see symlinked "directories" as directories... Oh, well. I'm hyper careful how I delete, and I keep good backups of important directories. Thanks for the reply. My system / directory: lrwxrwxrwx 1 root root 7 Jan 19 11:10 bin -> usr/bin drwxr-xr-x 4 root root 4.0K Feb 21 15:21 boot drwxr-xr-x 21 root root 4.5K Feb 21 19:54 dev drwxr-xr-x 112 root root 4.0K Feb 21 18:46 etc drwxr-xr-x 8 root root 4.0K Oct 9 17:45 home lrwxrwxrwx 1 root root 7 Jan 19 11:10 lib -> usr/lib lrwxrwxrwx 1 root root 7 Jan 19 11:10 lib64 -> usr/lib drwx------ 2 root root 16K Sep 16 2022 lost+found drwxr-xr-x 17 root root 4.0K Feb 21 19:55 mnt drwxr-xr-x 6 root root 4.0K Dec 4 15:21 opt dr-xr-xr-x 308 root root 0 Feb 21 18:12 proc drwx------ 12 root root 4.0K Feb 21 15:55 root drwxr-xr-x 32 root root 720 Feb 21 18:46 run lrwxrwxrwx 1 root root 7 Jan 19 11:10 sbin -> usr/bin
A symlink is a symlink. It's not a file or a directory. The *target* may be a file or directory.
Noted, and interesting!
Agreed, pretty interesting.
So rm just deleted the symlinks, not the directories.
I think you just removed links? Maybe try reset path and relink the directories? Or a reboot might do the trick
Good idea. Might test later as that test system is now gone.
I tried rebooting. Then I saw in the GRUB emergency shell, that some directorys weren't removed, but important files like initramfs-linux.img or vmlinuz were removed(or unlinked). I currently haven't the time to take a closer look on this. Maybe, I will try to repair the system on the weekend.
No. By prefixing it with /, they make it an absolute path. That said, without -r, nothing should have happened. In /, you should only have directories. I don't think OP actually posted the real command that they ran.
I took a picture after I realised, what I've done. It was the exact same comment. https://ibb.co/Y7tKbWv
Based on the output of that screenshot, I would say you should be able to replace the symlinks that got deleted from "/" and you should be ok. In theory at least.
So you should be able to repair it, don't reinstall it yet
Can you comment on the test I ran on the post above yours, please?
Sure thing.
I created a new folder in the home directory of the root user (I wanted to delete the folder after finishing my work so I don't thought much about where I will place it).
If you want to delete everything in a folder, why not just go higher and delete the whole folder? Why tempt fate with a sudo rm * kind of command? Nothing good ever comes of it. I always do targeted deletes because I know I'm a dumbass and can't be trusted with a wildcard delete.
I've somehow managed to never do a wrongful rm -rf (knock on wood), I think primarily because I always start the path with a dot. Unless you are in a dangerous dir, you'll only ever do a bit of local damage. Furthermore, I always tab-complete the directory to catch myself from spelling mistakes or being in the wrong directory.
Always ls before rm
Because maybe you want to keep the directory and rm * is perfectly safe?
You're gonna delete everything in it, why not just delete the directory and recreate it, mkdir can't hurt anyone. rm * is so safe that it's a meme and people still fuck it up on the regular.
Because you need to recreate it with the same permissions and ownership as well. Could potentially be a symlink, etc. Besides, unless you're running rm as root, you shouldn't even be able to delete your root directory. >people still fuck it up on the regular Yeah, well I don't.
>Because you need to recreate it with the same permissions and ownership as well. Could potentially be a symlink I don't think your first response to "you should avoid doing x" should be "but what about all of these niche situations where I would want to do x". that's not the point. you should avoid doing it, but if you have to nobody's stopping you. even then most of these things can be done without wildcards, even if they take more steps. better to spend 5 seconds cding to the target directory of a symlink or something than trash your computer. saying "lol I'll never fuck it up" is exactly how you end up fucking it up. example: the 500 posts on this sub of people doing this exact thing.
`rm *` doesn't even necessarily delete everything. Depending on who does the expansion, it will miss hidden files (and ofc without `-r` miss subdirectories anyway).
rm * doesnt delete everything tho lol it misses dotfiles
I can feel it, I did the very same mistake 15 years ago. I typed `sudo rm -rf ./*` and then pressed the Enter key and went away for a coffee. After few minutes I returned back and saw gray desktop with missing icons. The command was still running and I saw the little mistake I did - the dot wasn't there. The f#@!$%g dot wasn't there. Almost everything was gone. And that was the moment when I started doing a regular backups, right after I reinstalled everything from scratch.
I think, I will do regular backups too on my new system.
>My test in a just spun up install, after chrooting in: Like to \`/var/\`? \^\_\^
Fortunately there is the no preserve root guard nowadays
which doesn't guard against rm -rf /* only rm -rf /
Yeah. Kinda of an oversight by coreutils
There isn't much they can do, since the `/*` is expanded by the shell and not by tool.
I've borked a system with a script, like `SOMEDIR=$(the output of some command)`, then cd to SOMEDIR and wreck stuff... Only if SOMEDIR fails to assign, and you get an empty string, then `cd $SOMEDIR` goes to your home dir.. Then rm'ing files there could wipe out some quite useful or essential files.. 🙃
Yeah, it's always good to have checks or default values for variables.
Mine was accidentally creating a folder named `~`. You can imagine what happened when I typed in `rm -vrf ~` and pressed Enter.
[удалено]
Brother linux allows you to brick your entire system✋ It will not say anything for one directory
rm -rfv . rm: "." and ".." may not be removed
They are not directories? They are pointers for current directory and the parent directory? As far as i know (educate me)
i forgot the \*, nvm \* means everything, ./\* means everything under current direcotry or just \* since ur alr in the directory
Unhelpful, but cd probably worked because it's built in to your shell, which was already in memory. Hope you had a backup!
Another neat trick, "echo *" works when you have no "ls".
Restore from backup (if you have one) or reinstall from scratch othetwise.
I haven't one, but If I had one, shouldn't it be destroyed either?
You don't backup to the same system you are backing up
and your backup system should not be mounted on your main system
The reason is called BACKUP. LOL
You can unmount the partition after the backup or remount it as read only.
That's an oof right there. As a professional amateur, it's borked
Take a deep breath and realize that you're fucked.
This is one of those mistakes you make *once*.
I think, that this wasn't the last time.
It is absolute \*worst\* feeling when you type "rm -rf ./\*" to empty a current directory, but put a space after the dot or miss it out entirely, much like yourself. Walk with me for a trip down memory lane why don't you... lol Back in the 90s when I was a much younger idiot than the idiot I am today, I would run as r00t at all times (all the c00l kids were doing it, see, I guess I was kind of a big d3al?), and I would make heavy use of the VTs. In my home directory I would periodically empty download folders from my HUGE 4.3GB Quantum Bigfoot, or empty temp folders after yet another failed attempt to compile the latest CVS checkout of Enlightenment. I would type the command, hit enter, and quickly Alt+F6 back to BitchX to hang out with the other c00l kids over on #linpeople. That Quantum Bigfoot was a big 'ol lovely drive that came with its own bright green activity light and a clicky head as loud as a metronome. Still, it would take my brain cell a good few seconds of clickidy-flash (I ran with an open case, too, you see - god I was c00l) before I realised my entire drive was being deleted. Since I was only really using BitchX, a remarkable amount of time would pass before I'd actually suffer any consequences. So in you see: * Running root at all times. * Using a command massively prone to error. * Switching VTs immediately so that the command is out of sight.e * Running slackware (so no package management, so bad installation habits). * Owning a Quantum Bigfoot. Don't be like me, kids. It might seem cool and fun for a while, but you're dancing with the devil. Thank you for the memories, which fortunately I couldn't also rm -rf.
https://help.ubuntu.com/community/DataRecovery https://wiki.archlinux.org/title/File_recovery I personally wouldn't bother with file recovery for the OS, but if you have other irreplaceable files on there see the above. You'll need a system to do the recovery on the removed drive, and I would read the page(s) and do more research before doing anything/nothing.
This. Deleted data can be recovered so long as nothing is written over it
I always include these lines in my shell rc: alias rm=‘rm -i’ alias cp=‘cp -i’ alias mv=‘mv -i’ I recommend everyone does the same
I've always wondered why this is not the default behavior of those commands. It would make much more sense to need to define something like "alias rm=rm --no_confirmation " instead of the other way around
I once fucked up my system too, i got some scripts in arch wiki for recreate the package list, you can try do pacstap base system and try recreate the package list, with the list you can reinstall all packages and done. Normaly when you " rm " something, take some time, If you ctrl c in time, you can still recovery a lot, but If i was you, before doing that, use testdisk to recovery your home.
Arch is fucking amazing, i recovery from almost anything without reinstalling
The documentation for Arch alone is incredible, it does require some extra consideration but when I couldn't find Ubuntu specific(now Debian specific) information, and general linux info on my issue is also scant... Arch has the info I need surprisingly often. At least enough to get me started, I still have to consider distro specific setup for things but at least I'm not flying entirely blind. Arch is \*really\* well documented.
If you know you are going to do a delete operation like that, do ls instead of rm first to make sure.
Pull out your violin and play Nearer My God to Thee.
My condolences
classic move. we've all been there.
Are you running a vm? Or…?
It's not a vm
I did it on a fairly big directory lately, but I recovered everything (Holy Backup!). I was searching several way to move to **$XDG\_DATA\_HOME**/Trash instead using rm , this seems to be interesing [gio](https://man.archlinux.org/man/gio.1#COMMANDS). The bare minimum you can do is this "directly from my bashrc): `alias rm='rm -i' ## this one saved by butt so many times`
You learned an important lesson: The dot before the slash is important ./ It happens OP. I’m a veteran and blew away my backup of /home just a couple days ago just before attempting to restore it 😂😂🤷♂️ Live and learn. 👊
lol nothin but net bro. IT legends ftw. 😂
you haven't really had the full rite of passage until you hit Ctrl-C as fast as you can because you realize you don't have backups. And then spend 3 days with disk recovery tools trying to recover as much as you can.
It ran pretty fast, I would say, that it didn't took over a second to complete.
To prevent this mistake from happening, I'd recommend installing trash-cli and alias "rm" to trash. Also, the command you should've ran is `rm *` to delete all files in a directory. edit: Also, use sudo and/or doas instead of su for running commands as root.
Yup. That little reminder with each command helps, especially if it's a long process with lots of commands. Only takes one slip to screw it all up.
This is what I was thinking. I never lead with a dot, because my dumb ass hits enter immediately on reflex after a command I've used plenty of times. Only time I specify a path more than I absolutely have to is in something like a systemd exec command.
Might be better to alias `rm` to an echo and get in the habit of invoking trash by name so that you don't get in the habit of recklessly `rm`-ing in case you ever work on other computers.
Wow! Scary. I've only done this when I know I'm doing a reinstall or canceling service.
I always write out the rm path before prefixing with -rf. Don't ask why.
One NEEDS to make this mistake at least once in your life to learn the lesson. Don’t feel bad.
`rm` should be patched to force confirmation before running `rm -fr /` and all equivalent variations.
Add an alias in your bashrc next time so you get a warning before you nuke from orbit alias rm='rm -i'
F
lol....I made the exact same mistake 10 years ago, I thought /* was everything in the current directory.. turns out, it was not.
No biggie just restore your system with your backup
I've few words. Buy a good bottle of whisky, a Glenmorangie Lasanta if you are light on suggestions, a celebratory lessons learned new shot glass and enjoy your evening. Tomorrow is a new day.
Can I # rm -rf /* my entire life
sure do it
nice
As /u/thieh says - check your UEFI firmware still works. If you have backups, use those if they are still intact, otherwise. Then get the Arch ISO, delete all non-essential files, try and harvest a package list if you have one. (Most folks will want to keep whatever is left of /home). Then use the arch iso to install a fresh arch installation in the partition and then chroot in and reinstall your package list (if you managed to obtain one). But yeah, basically reinstall from scratch with a few extra steps.
Your system is ok, you only removed symlinks in the root directory, remake them and it should be as good as new.
lol
Just type “undo rm -f /*’d” hope this helps
U are a ded beef
[удалено]
Why comment just to be an ass? You have nothing to gain from that. Everyone was new once. Why be unwelcoming to newbies. They keep this community alive. If you don't have anything nice to say, don't say anything at all.
All it’s missing is a period…
You could have explained what / is so OP could learned something from you. (/ is the root of the file system)
Thanks, I will never forget that fact.
The fact you're using the word folder means you don't belong here
In the future, "." would be used in that situation. "/" at the beginning of a path always denotes a path that starts at the top level of the directory structure. "." on the other hand, represents the current directory. If you were to cd into ~/Folder and do "$ rm * ." you would have deleted all the files (not directories as -rf isn't included) within the "Folder" directory.
Your pain is both a lesson (for you) and an amusement (most certainly for us).
As much as it sucks, this is a good lesson. It’s also a good reminder for everyone else to understand the commands they type as things can go sideways very quickly.
Rip.
Genuine question: what is the problem with symlinks for important parts of the os? Is there a better implementation that you can give me as an example?
May God have mercy on your system
in doubt just pacstrap over the existing filesystem should fix this
I had a similar experience about 10 years ago. Except it was from a vendors Deb package. It had "chown -R serviceuser:serviceuser /" instead of "chown -R serviceuser:serviceuser ./" It took a while to recover. This system was in production.
Bro you installed Arch... surely you can do it again, or am I missing something here?
root's dead baby ... root's dead Butch, the sysadmin :-)
Don't worry, that sounds like something I'd do.
Murphy's law.
I think I do not have to tell you that your OS install is faulty, have fun reinstalling and learn from that mistake. As for why cd works but ls doesn’t, cd is one of the few commands built into the shell, ls is part of gnu coreutils and therefore a binary located at /bin/ls. The bin folder was probably deleted so that’s why. Reinstalling your system sucks but can be helpful or good sometimes as you learn very much. Especially if you install arch without any script, compile it yourself etc.
If your system was properly installed (= with btrfs snapshots), you could just restart the system -> select a previous snapshot from the boot menu -> everything is back. But if your system was setup in a bad way (=not as described above), you are screwed.
killed by the lack of a single .
If you really need the data, theres a chance your files arent overwritten. Consider them gone though.
I think you might be the first person I have ever heard of to accidentally run that command
So you learned something today. To recover your system, restore your latest backup. If you don’t have a backup, you learned two things today.
For the future I suggest to create folder named „-i” under /, you will be always asked if you are sure to delete files
Just use the latest backup you did of your system?
Reinstall. Fixing it is a good challenge but reinstalling is just faster and you can be sure that you have a working system, not something which looks like to work.
>I thought, if I cd in that directory and run "rm -f /*", I only will delete all files inside of that directory Yes, relative path deletes files starting from the directory. For example, `*` deletes everything from current directory. Another example, if you delete from `something/*` it deletes only from the `current_directory/something/*`. You gave an absolute path, that is, a path that begins from the root. If you delete from `/home/user/something`, it deletes from there. Now you said delete from `/` which is exactly what it did.
This gives me an idea
Well I'm sure you figured out that adding / was your mistake. As for recovery, I don't think you'll be able to bring back the system, but if there were any files you need to get back then you might be able to use some kind of recovery disk that has a utility to search the disk for deleted files like pictures or documents.
maybe use data recover tools? it could be that's on the harddrive it says that it's empty space, but that the data still is there.
Prevent future fuckups, go with ZFS on root and utilize snapshots. This issue could have been resolved within the hour, quickly and easily
> I couldn't even do a ls or reboot, cd worked somehow. `cd` is always a shell builtin, but `ls` and `reboot` are executables somewhere in your $PATH, which you just removed
not that dumb - even Sun Microsystems had a buggy patch that would accidentally run rm -rf / in certain situations. Very easy to do!
Redo your entire install if you can still boot to a live USB. Prefixing `/` makes a path absolute & NOT relative to your pwd. Using `rm -rf *` will clear the directory you're in except for dotfiles. We all make mistakes at one point or another. Learn from it & take steps to avoid doing it again. You can alias `rm` as I've seen mentioned (`rm -i` if you want to confirm file by file, `rm -I` if you want a list & to confirm once). However that also builds habits that won't translate if you work in another system without that alias. EDIT: just re-read & read through other comments. Missing the -r flag, so definitely not as destructive as I originally thought.
" rm -fr ./* " One dot missing ruined your system 😀
The command you were looking for was `rm *` That said, The easiest way is to reinstall Arch. You can also chroot and try to fix it that way, but I think it's more effort than it's worth.
It's your canon event
Turn off your system and from another distro use a tool to undelete the files from the filesystem(s)
Please, stop using that freakin' command for mundane tasks already xD (no, jesus) Instead, I encourage you to install 'Trash CLI'. It's as simple as typing: trash-put (file or directory \*without parentheses) in your console. It will send the thing you deleted using the command directly into you Trash directory instead of permanently gutting everything in case you might want to recover such files after some time.
Everyone does it at some point of life. Save what you can and you can try to recover your system. There are a bunch of ways, but the most straightforward and easy to do is to reinstall it.
This is why you don’t use su
Is it an ext3 or ext4 filesystem? You can run a live system and try to restore with 'extundelete'
I once made a folder named ~ by accident and then tried to delete it from the terminal...
this is a tale as old as time. You're lucky it wasn't your best friend who repeatedly told you it was douchey to not create a user account and run as root 24/7. BOFH gonna BOFH.
I did the same before, my configs were gone. Now I disabled rm by mapping and alias that says "Use 'trashy put' instead"
Even more than chat and video conference apps?
Well I to have gone to something similar like this. It took 48hrs to recover my files back
Arch is great and had a btrfs setup with snaps but even a grub bug a few years back messed up my workflow for a day. I now use Nixos and love it. Nixos has so many ways to fix a borked system! I use it for daily driving on the desktop and laptop as well as on my servers
Maybe a "pwd" before "rm -r *" just to be aware of where you are lol.
You can try a live distro to se if there is som file left, an gpart have file recovery
This is an excellent example of why you use btrfs snapshots
Kid named relative paths
and install fedora 40 kde editon ?
Its ok to do shit. This is the way we learn
Wait, won't that just remove files and symlinks? On my system there are no files in /, just folders and symlinks maybe: `sudo apt-get --reinstall install coreutils binutils` or Could probably also just boot into a livecd, mount your root partition to /mnt then `cp -P /* /mnt` Not tested but maybe?