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/2402
But Windows 95/XP does not run on EFI systems, so they aren’t used in the BRD. We’re save!
Plus no ads, and MUCH more efficiently written code to boot - win-win!
Just don’t hook it up to the Internet…
Why 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.
Bro, BIOS is located on motherboard and EFI variables only needed to boot an OS.
Just install bootloader and OS in drive
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.
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.
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 to rm, so it just sees a list of directories like /bin /usr /dev /sbin /home and so on.
You could implement logic to detect that case, but at that point you’re just playing whackamole.
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 same find query again and add --delete at the end)
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?
Obligatory trash-cli alias.
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)
