WARNING:
Don’t ever do this on a current bare metal system!
Even if you have everything backed up, plan on re-installing anyway, and just want to see what happens.On a modern EFI system, recursively deleting everything (including the EFI path) has a chance of permanently hard-bricking your computer!
https://github.com/systemd/systemd/issues/2402Why would it be a permanent brick? Shouldn’t a flashdrive and access to BIOS be enough to get your PC working again?
In a properly implemented EFI, this should be possible. But there have been cases with improperly implemented EFI in some laptops/motherboards where the computer won’t POST after /sys/firmware/efi/efivars/ was nuked. In that case, accessing BIOS or booting from a flashdrive isn’t possible anymore.
I have a little flash chip reader and backed up my bios and can flash it on the laptop. Even modified it to unlock the advanced menus Lol
But th rm rf thing didn’t nuke it so I guess I’m safe either way
Bro, BIOS is located on motherboard and EFI variables only needed to boot an OS.
Just install bootloader and OS in drive
Bro, several people bricked their pc that way. I’m no expert, just throwing out a warning not to do dumb shit.
In Linux, everything is a file.
So if you have a problem, it will be in a file somewhere.
So logically every problem can be equalled to one or more files.
Therefore it follows: no files = no problems. And no problems = no headache.
Everything that does something is a file. No files, no existence ;)
Once upon a time, I accidentally created a folder named “~” in my home folder (the company provided scripting framework would inconsistently expand variables, so the folder had a ton of stuff inside it).
I ran “rm -rf ~” and only panicked when I started to wonder why it wasn’t taking too long.
Good news is that it only managed to get halfway through my local checkout of aosp before I stopped it. Bad news was that it nuked most of my dotfiles.
You forgot the
-rjust like always.
Why doesn’t rm -rf /* also require —no-preserve-root? That seems just as easy to type accidentally and will just nuke your system without asking
It’s actually harder to detect that. The
*is expanded before the arguments are sent torm, so it just sees a list of directories like/bin /usr /dev /sbin /homeand so on.You could implement logic to detect that case, but at that point you’re just playing whackamole.
I believe zsh catches this and makes you confirm.
Well, that or one of my plugins, I’m not sure.
If you try to put in safeguards for every possible system-nuking command someone with root rights might type, you’ll never get done.
When you’re typing “rm -rf” as root, you should immediately stop and triple-check what you’re doing.
Cause either there’s a safer way to do what you want to do, or what you’re trying isn’t a good idea in the first place.(Even when you want to delete lots of stuff in root space, a better way is to use
find. You can use it to look for and list the files you want to delete. After you’ve checked its output and verified that those are the correct files, just cursor-up to get the samefindquery again and add --delete at the end)Can confirm. Accidentally did that a few weeks ago.
I am curious how. If you were deleting everything in the local directory you wouldn’t need the ./ before the asterisk, so was it some sort of piping that messed it up?
I was cleaning a usb and didn’t want to reformat it.
Obligatory
trash-clialias.Tf is that
rm is like “delete permanently”, trash-cli is like regular delete - it moves to the trash bin. Many people like making an alias so rm runs trash-cli to prevent accidentally permanently deleting data
rm deletes files the normal way everyone who actually knows unix expects it
trash-cli tries to bring the comfort of windows to linux for the crybabies who like to delete files so recklessly that they end up screwing themselves later. (the same people who don’t ever take backups or snapshots)
