Slashdot Mirror
Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com)
An anonymous reader writes: For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
Seems like the kernel is the wrong place to solve this problem.
"Systemd developers have rejected ..."
No surprise there.
Hey, systemd developers know better than you how your server should be configured.
So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?
Because this sounds so horribly broken it isn't funny.
Actually, no, it's actually quite funny in a big giant "WTF" kind of way.
Lost at C:>. Found at C.
In other news, Poettering remains the best advocate Apple has for switching geeks to their platform... they should pay him, really.
It's just now bricking systems? Wow, all this time I could have been running "rm -rf /" with reckless abandon ...
Isn't "not running systemd" a good solution?
Yeah but viruses and spelling mistakes do actually happen.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Stuff like that makes me long for a write protect jumper on the motherboard again.
What are the valid use cases? Can't writing anything to UEFI be done through some other way than the filesystem?
And also UEFI itself is flawed if everything is exposed in a "flat" way like this.
Of all the things you could run that you might expect to 'brick' your system surely 'rm -rf' as root would be the one.
Consequences arise from actions. I hate UEFI as much as the next guy, and don't get me started about SystemD but this looks like click bait.
Damn, got me.
Have you tried not running rm -rf /?
Just an idea, but perhaps someone should set up a database that accepts failure reports and, consequently, shames all the hardware devs into fixing their (U)EFI implementations.
While I don't agree with mounting efivars rw by default, accidental deletion shouldn't permanently render one's computer an expensive piece of Lego.
I always run sudo \rm -rf That is the way to do it, you whippersnappers.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
...Systemd developers have rejected mounting the EFI variables as read-only...
So the sane solution is rejected because the underlying design is bad?
What happened to booting from CD/usb? How about bringing up a system where all batteries are dead, so there were no power for bios stuff? The latter was a hassle, but you could always get those things going before.
I have full backups... it would be nice to know that I could use them to restore the system and keep going if I ever ran that command by mistake.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Deleting your entire hard drive is not the same as bricking your device, Captain. Or at least it should not be.
I had to read the article just to see if there was something more to the article than "Dur, dont be stupid".
Nope, nothing to see here. Do not run as root user. Anyone stupid enough to run as root user is going to hose their system by typing a wrong command sooner or later anyways. This article will not help.
You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.
Incidentally, while systemd was being blamed for this, the underlying /sysfs structures have zippo to do with systemd, so put down the pitchforks.
* Which has never actually been completely true but is a popular catch phrase.
AntiFA: An abbreviation for Anti First Amendment.
It always fried your OS. But now it apparently also destroys your motherboard if you can't reset the UEFI somehow.
Try running fuk /u
This seems irrational:
"Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, "
Can't you just mount read only anyway? Fuck the broken apps. Does every system have them? It should be my choice but systemd devs are arrogant assholes. Are these "valid use cases" universal?
If Gentoo is ever systemd only I'll be done with Linux.
The
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
...so for now there is no good solution to avoid potentially bricking your system...
That's why most versions of rm feature a --no-preserve-root option that is required if you issue that specific command. If you really want to remove all files on a the root partition, use the --one-file-system argument, or just don't do that.. ever... formatting the partitions is a much simpler solution.
Most motherboards now offer some type of "BIOS recovery" (their words, not mine.) This allows the board to be brought back to factory state regardless of the contents of flash,nvRAM. Typically the restore software is in mask rom, and can't be written to.
Code the "rm" command to block "rm -rf /", there is no valid use case for running that command, if someone wanted to wipe a drive they should just use a partitioning utility from a separate boot device.
At what time would I ever use 'rm -rf /'
Why wouldn't I reformat the partition?
Maybe Linux isn't for you.
Depends on the level of disaster you're expecting. You'd expect it to wipe the filesystem, however you'd expect to be able to reinstall afterwards. This story seems to be saying you can trash your UEFI BIOS in a non-recoverable way, and I certainly wouldn't have expected that (probably because I have no clue about UEFI).
Back in college, I ran the command for shits and giggles on a system that we were redoing anyway. I would have been immensely pissed if I found out it bricked the system because some firmware was mounted as writable space.
The kernel dev who wrote the efi code says it's not a systemd problem and following the bug report's suggestion would be the wrong way to solve the problem.
But don't let that stop you from jumping on your favorite whipping boys.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Having come up during the advent of computers, this is PRECISELY why we separated hardware bootstrap firmware from user-accessible code in the first place, and did not make provisions for user-space access to change it. The hardware had to continue to operate and boot regardless of the stupid things users and developers did.
That all went out the window the moment we started with this "update your BIOS from the O/S" bullshit. And now, apparently, "let's give userspace read/write access to the bootstrap firmware willy nilly," which is complete and utter stupidity.
You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.
A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.
It's a shitty design.
I have always used legacy mode in bios for Linux installs. I guess this must help, I have not experienced any problems? UEFI is perfectly fine, I think it was a big positive for PC's. I suppose those dual booting Linux with Windows in UEFI have the potential for experiencing this more.
I'm a little surprised that motherboards don't keep a tiny read-only repository of code to restore from in case you FUBAR the writeable parts. Isn't BIOS code measured in KB? That's trivial space to devote to brick prevention.
There are too many imbeciles that will brick their system by typing in random terminal commands they found on the Internet, like fork bombs or using wget to download a trojan. rm -rf / is only the most famous of this kind of command. Then they will complain that Linux is too fragile and dangerous to use for new users, blah blah blah.
I was thinking of a possible solution to this. Perhaps the distros meant for newbies (Ubuntu, Mint, elementary, Zorin, etc.) could lock by default the most well known terminal commands that fuck your system up. When trying to execute them (even with root privileges), they will get something like "ERROR: This command is extremely dangerous. To execute, go to [distro's website].org/foobar." This page will have the password in order to bypass the lock, but only at the bottom of some text that explains exactly what will happen, and if you do anyway, that the distro has absolutely 0% liability to what will happen to your system.
How come we haven't heard of massive bricking on Windows systems by malware that bricks system boards? Could it be that bricking is not possible by bricking malware on windows where bricking malware could actually brick a system board on a brickable linux box?
You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.
A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.
It's a shitty design.
A newbie user shouldn't be fiddling with their packages from the terminal either. Ubuntu comes with a software center that allows one to easily add and remove software without this happening to you.
So, where is your holy grail called UEFI variables stored? If its not on the hard disk then its possibly in the NVRAM of your system. So, yes you can erase them or modify them, but shouldn't have the System a "factory reset" function that cleans the mess after an accident?
How about you can the fucking idiots who modded this shite 'insightful' read the summary and TFA - or is that too much to ask? Silly me. It's Slashdot.
The FA doesn't say.
And you're more of a fucking idiot.
There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).
No sane package management system would do things this way.
This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.
Same shit different lifetime.
Time for another Extinction Event to maximize the available Entropy.
No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI. Linux package managers are well overdue for redesign. Making hardware brick able by software is also bad design. Mounting firmware as ordinary rw files, ditto.
This command does NOTHING on my superior Windows machines. We do not allow such viral commands here in the grown up world of computing.
Just create rm() function where you assign something else for rm -rf /
Source it from .bashrc
Problem solved.
And its by ignorant design mostly
for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt
say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire
I'm not a fan of the Debian packaging system but it's not that bad. You must ether have done something really wrong or you are just really bad at trolling. For one thing apt-get tells you what it is going to remove so if you blindly accepted you have only yourself to blame. Secondly I'm having a hard time believing that apt-get would actually uninstall that many packages for such a trivial program.
See the subject line.
Obviously this poster has no idea
1. of what he is doing
2. that XFCE in Debian is not "Linux"
C'mon folks, nobody forces you to use systemd. I run a Debian "testing" system with systemd-provided init disabled and everything works fine for me so far.
But Linux was working, right? So it didn't fuck up Linux, nor the base Debian/Ubuntu install. It fucked up XFCE, which is something that is an unfortunate side effect of having the user interface as an uninstallable add-on. The fact you use XFCE on Ubuntu means you chose that desktop environment by choice. Would you rather Linux make it easier for you by forcing you to use KDE 4.0 (or Gnome 3), say, so that it can't be uninstalled by accident?
Those who do not learn from commit history are doomed to regress it.
No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI. Linux package managers are well overdue for redesign. Making hardware brick able by software is also bad design. Mounting firmware as ordinary rw files, ditto.
Well, there's two problems with that. One is that he explicitly stated he was using Ubuntu, which comes with a GUI software center. However, he decided to use the terminal anyway, which leads to our second problem: apt will explicitly tell you what you're going to remove whenever you run sudo apt-get remove foobar, and he ignored it and ran it anyway. Which is his right, but one should be aware that anybody can do the same thing in OS X and Windows, so this isn't a problem with Linux so much as stupidity.
Spell it SystemD.
That way it looks like an ASCII penis.
Yes, malware is probably the biggest real danger here.
That said, over the years I've also seen my share of very sheepish-looking engineers whose scripts didn't guard against an empty environment variable...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
And you're more of a fucking idiot.
There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).
No sane package management system would do things this way.
This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.
The very first distro I used was Xubuntu. And like our GP, I wanted to remove some of the unnecessary games that came with the distro, so I too used sudo apt-get remove in order to do so. And I have absolutely no recollection of the entire DE being dependent upon sudoku. So it sounds like the GP is just making shit up. Even if he wasn't, he was still a numbskull, but he probably did make it up.
What is all this? I thought rm -rf / was the official procedure for upgrading from RHEL6 to RHEL7?
Linux is anything but fragile. Stop blaming the OS for a shitty design in UEFI! Linux is so stable and solid that it lets you run "rm -rf /" and it will actually do what you asked it to until it can no longer figure out the machine it's on and commands needed to talk to a disk. This is a more than 45 year old design. Yes, that's right. In AT&T's original Unix you could also kill a system with "rm -rf /".
'but', 'but', 'but', oh shut up and stop spreading FUD! "rm" is the remove command, "-r" is recursive, and "-f" is force. You need to be root to run this with any success, so it's not like any old user can remove everything.
The problem is that UEFI allows an OS to write to areas which it should not be able to write to. If you open all the PROM in a system it's not just the OS that can brick a system. A malicious person can do so just as easy, and without being so obvious as running "rm -rf /"
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I assume this problem occurs only in you are running with root priv. .*
It should be noted that running:
rm -rf
Will also have a similar effect because the rm will work its way up the directory tree to "/"
A work around to avoid this kind of disaster is to use the following to remove everything below the CWD: .??*
rm -rf
and yet every single "how to do X in linux" tutorial starts by telling you to open a terminal and type sudo XYZ
You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.
A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.
It's a shitty design.
The system IS smart enough. Even if the only reason XFCE was installed for was sudoku it won't be uninstalled until you say yes to 'delete no longer used dependencies'.
Using sudoku to install the desktop environment of your choice is also kind of baffling. The dektop environment is usually flagged 'manually installed' and a short search in the package tree shows that no suduko in the repository depends on a window manager or desktop. Either there is a totally broken debian based distro out there or the story is made up.
No, you're the idiot, because
1. you can't see WHY a newbie user shouldn't be subjected to the nonsense of losing half of the desktop due to uninstalling a game.
2. you demonstrated your ignorance and stupidity by abusing him for a perfectly reasonable point.
Kindly crawl away and die. We don't need your sort in the Linux community.
It's not a shitty design of Linux. It has nothing to do with design of Linux. It's the fault of the packaking of the software. If what you say really is the case then someone fucked up by packaging the solitaire as a requirement for XFCE. So a fault in execution, not in design.
+2 Insightful? WTF? This simply cannot be true, unless xfce was only installed because you requested solitaire be installed. You must have done something truly awful to delete your whole GUI environment by removing solitaire.
The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
XML is like violence. If it doesn't solve the problem, use more.
This is another case of stupid design. The UEFI section should be mounted RO by default and remounted RW just long enough to make required changes when required. The tinkerers can be satisfied as well while still providing additional stability.
*sigh*
Read the fucking article before you make an ass out of yourself. Hell, in this case, the difference between "OS doesn't load" and "computer is bricked" is clearly explained.
This doesn't apply to VMs I hope
Linux package managers are well overdue for redesign.
I'm sure Pottering will oblige in due course.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Oh yeah, heaven forbid you want to uninstall the built-in crappy calendar orage. It's a required of the xfce desktop. You kill it, your desktop is GONE.
It makes perfect sense for a format of my drive to brick my entire system, that makes perfect sense, in 1968. My bad, I thought this was 2016.
The concept of dependencies – especially when functionally entirely independent – is nonsense and needs to be changed. It is also an opportunity for bad apps to achieve immutability, that is, if newbs won't remove them for fear of losing their GUI as a consequence.
Mr. Shuttleworth: So you say you don't want Amazon Search on your system? Ha ha ha!
Linux Newb: But Mr. Shuttleworth, I thought Linux was about freedom and such, configurable to my liking! Pleeeease!
Mr. Shuttleworth: Ha ha ha... Lets see you configure things at the command line.... Ha ha ha.
Linux Newb: Gee, all this Linux stuff reminds me of Windows. Maybe I'll just try BSD.
Poettering: Noooooooooooooooooo!
It is theoretically possible that this happened.
Say the game was installed through some meta package that depends on lots of stuff but contains nothing. Lets call it "xfce-desktop" or something.
Uninstalling the game will then take the meta package with it because it's dependencies will no longer be fulfilled.
Now that meta package was the only thing that depended on a lot of other packages. So they can be and will removed if you do not tell apt not to.
In order for the OS (Windows/Linux/Unix) to use the Secure Boot mode, they have to be able to add their keys to the Secure Boot - EFIVARS table.
What this sounds like is a poor implementation of that feature since it's allowing all of the UEFI Firmware to be wiped instead of the Secure Boot area.
This makes my Asus Board far more valuable due to their Crash Free implementation that can load a firmware replacement/upgrade w/o a CPU or RAM installed by using a hardware button and dedicated USB port to do so so I'm quite a bit happier as it's a damn good use for an old 128-512M flash drive
Which distro was it? Ubuntu, Debian, Mint, another? It could be integrated as a gnome dependency but that seems strange. There are many flavors and it's possible not all of of them do this (I may try on virtual OS's just to confirm). Yes, it is illogical, but being open source + community driven, we have the ability to change it, either in code for submissions, or in bug reports. The thing about MS (Especially Windows 10 which sends data about you which is hard-impossible for a non-techie especially in Home edition to block/shut off and even Windows 7/8 may have their systems hijacked if they don't disable Windows updates in the "Services" and now there is no description in new updates so you have no clue what they are doing until it's too late..), is if the community says something is bad/irritating, MS says politely "f** you". With Linux distros, you have a chance of being heard. The only way MS hears anything, is if given an "offer you can't refuse" by the US government, or if everyone stops using MS Windows. (which while there is chance is happening with more Android/iOS/MacOS/Linux users leaving MS in disgust as they realize there ARE choices), is happening at a snail's pace. So it's your choice: Go with an OS where your opinion might matter, or with an OS that couldn't care less because they still think you are beholden to them.
"Imagination is more important than knowledge" - Einstein
I've managed to mess up systems real badly by using aptitude and blindly accept conflict resolutions that involved removing and downgrading packages (or leaving dependencies unresolved). But that only happened because I thought I was smarter than apt-get (package xxx could not be installed? Bah! aptitude will fix that)...I had backups anyway.
I've never seen systems get messed up because of trivial apt-get operations otherwise (dist-upgrade between different versions is always hit-or-miss, though).
I have, however, seems windows systems become stuck in a reboot loop after a routine windows (critical) update, which is no fun to solve because you don't even get a console, or logs or anything. Not even live CD with some basic rescue utilities. Knoppix has saved my arse countless times in those situations.
That didn't happen, unless you had installed your desktop environment by pulling it in automatically when you installed the game. Even then it would have taken an explicit instruction to the package manager to remove packages that are no longer required by other packages. There are lots of problems with package management, but what you describe is not among them.
Back on topic, the UEFI debacle is obviously due to the firmware relying on externally modifiable data in a way which causes unrecoverable problems if that data is deleted or mangled. Even root should not be able to shoot themselves fatally in the foot by deleting every piece of configuration data that root can access. The worst that should happen is that the system comes up with a factory default configuration. UEFI is horribly designed and implemented worse.
/ is the root directory, which includes BIOS equivalent variables under Linux. It has never been "the hard drive" in Unices, not like C:\ is a device specifier in Windoze.
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
and yet every single "how to do X in linux" tutorial starts by telling you to open a terminal and type sudo XYZ
Are you sure you want to say every single? Because that leaves you open to a lot of counter-examples wrecking your case.
I'm not saying it was aliens, because it was actually systemd.
The only thing necessary for evil to triumph is for it to be pitted against a slightly greater evil
Oh yeah, heaven forbid you want to uninstall the built-in crappy calendar orage. It's a required of the xfce desktop. You kill it, your desktop is GONE.
I'm just curious what OS you think *isn't* guilty of this. Guess what happens if I try to uninstall the taskbar from Windows or the Apple menu from OS X? Oops, my whole GUI is wiped out; the OS probably wouldn't even boot at that point.
I think what he did was remove the games package, which probably marked the xubuntu-desktop metapackage for removal too (games being a dependency of the metapackage which, by design, has dependencies on ALL of the xubuntu/xfce packages). Removing the metapackage made all packages it depended on i.e. most of the xfce into "automatically installed and no longer needed packages" which the OP probably removed by naively issuing an && sudo apt-get -y autoremove to clean up the dependencies of the sudoku, but ended up getting way more.
OP should have
*known what the fuck they were doing on the command line before doing it
*know how the package management works
*how dependencies and metapackages work
*don't use the -y option for anything auto
*pay some fucking attention when you see more packages marked as remove than you bargained for and use ctrl+c to kill the apt-get command before it completes
*just left sudoku installed. It probably took a few KB of hard drive space for the executable and *maybe* some sort of libsudoku or something like that.
When I hear Bricking it means I have to toss the hardware or whip out a JTAG or EEPROM programmer.
Is this "bricking" real or just someone not understand what the word actually means and a initialize and reinstall of the OS will fix everything.
Do not look at laser with remaining good eye.
Yepp, Some package managers are on crack too often.
Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.
We suffer more in our imagination than in reality. - Seneca
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
A particular example of this is some nasty rootkit that comes (came? Not sure if they still do this) with Adobe Acrobat for Windows. The purpose of the rootkit is (was) to prevent people from pirating the software, but if it was tampered with or improperly deactivated, it had a tendency to throw a wrench into the entire booting process.
I wouldn't say it's as obvious as you make it seem. There is a difference between erasing the entire file system (obvious) and bricking the hardware by destroying the firmware.
I never run rm -rf /. But when I do, I
[Connection lost]
I've seen this over and over, but no real concrete reason for it.
Why IS systemd hated so much?
Don't give me your silly "chaaange!" arguments either. An actual reason.
Does it make Linux more vulnerable?
The only thing I have heard is it changes the way scripts are parsed, or something.
Not 100% sure, I've not used Linux in-depth and the last time I used it was 2004 on a laptop when I quickly threw a Slax Live distro on a disc because my HDD died.
Is it worth avoiding? Or, for a newer system (the one I am making), is it perfectly fine to get in to?
You also need the "--no-preserve-root" and to have a buggy motherboard UEFI implementation. The problem is that deleting stuff in /sys/firmware/efi/efivars resets some variables in the UEFI. If the implementation follows the spec then that is like doing a factory reset on your motherboard. For some poor hardware they fail to boot after this. The kernel already has some protection for some bad hardware, more will be added shortly ( https://gist.github.com/mjg59/... ).
I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed. I couldn't believe it. RMSes worst nightmares come true, today. Un-fucking-believable.
UEFI is just another machiavellian attempt at controlling our hardware from start to finish. It's basically the old TCPA bullshit repackaged. How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me. I honestly am of the opinion that those who designed this freakin' insane UEFI BIOS crap and peddle it should be brought before court for malicious malpractice and willfully undermining computer security.
UEFI in my book is definitely a reason not to buy the hardware using it.
BTW: How come no one get's worked up about that? Everyone is pissing their pants about systemd, but UEFI doesn't get half as much bad press. I remember the TCPA uproar - that was a good one. How about now?
We suffer more in our imagination than in reality. - Seneca
> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
Jesus I thought we'd gotten rid of that stupid "brick" term for simple issues. If it's a COMPUTER - you can't "brick" the damned thing if you take the hard drive out and throw it in a river.
"Bricked" indicates that the firmware is bad. A bad BIOS flash will brick a system. Something of that level. Anything that can be fixed via an OS reinstall ain't "Bricked".
"People who think they know everything are very annoying to those of us who do."-Mark Twain
The replies to this comment are why a lot of level headed people who don't use Linux, never will and those who do, won't use Internet forums.
Sig missing. Reward.
Sorry, but the package manager's behavior in this instance is indefensible. It absolutely positively shouldn't fuck with XFCE just to remove an app.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt
Which distro, and what system did you use to tell it to uninstall the package? And did you file a bug report?
say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire
Neither does Linux. I've never had such a thing happen. I've had plenty of fucked windows installs on the other hand...
SJW n. One who posts facts.
... hitting yourself in the head with a hammer may cause headaches, or unconsciousness.
Why don't we just set the contents to these to immutable (by default) and if there are legit reasons to change values through software, just add the subroutines to flip the bit back and forward and verify, etc. Done.
chattr +i for those who are not aware.
Sig missing. Reward.
I know you fanboys love Linux, but calling someone a liar for sharing their negative experience really is taking that to douchebag extremes. I mean, way to prove that Linux fanboys are all wankers.
Since I don't love Linux, I only have to use it, I can confirm that this sort of thing is exactly the kind of shit that Linux pulls on you all the fucking time, and if you're some kind of Linux genius you can probably figure out why it happens and fix it, but short of the requisite 10,000 hours you're fucked, which is why Linux on the desktop is still a complete joke.
Why in the world are you installing the desktop in a server install in the first place? You have to manually select to install it using the text based installed...
Windows and OS X on the desktop are also jokes because when I accidentally (read: recklessly type shit into the command line) remove software, I get all sorts of problems.
Also, trucks aren't ready for the road because when I tear out pieces of the engine nondiscriminately, sometimes it doesn't turn on anymore.
Sorry, but the package manager's behavior in this instance is indefensible. It absolutely positively shouldn't fuck with XFCE just to remove an app.
Rest assured that the GP is probably full of shit.
There are two reasons for that. Firstly, it's a choice between text and screenshots, and GUI interfaces have a tendency to change. Second, the text commands tend to be more broadly useful -- there are a dozen or more desktop environments and god knows how many distros, but there are far fewer differences from the command line perspective.
$ sudo test
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
There isn't really a way to idiot-proof a command line, especially with effective root permissions. Should sudo warn you on each use? Should every tutorial have the disclaimer that "FYI an errant keystroke will hose your system" ? And out of curiosity, is it possible to do more or less the same thing with cmd.exe/PowerShell?
Yepp, Some package managers are on crack too often.
Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.
That's because the network stack is built into GNOME, considering it's meant to be manipulated through its GUI. You could've prevented this by (1) checking what you were removing before you went through with it [as apt will clearly warn you of], (2) keep a secondary network stack installed in fact the first malfunctions, and (3) using system snapshots as something to rollback to if you're displeased with some changes you make.
Not so easy to remove the hard drive or re-install the OS from scratch remotely. The problem people are encountering is that they are physically thousands of miles from the hardware.
I mean, for the last 10 years, I have worked on a computer I've never seen. The Mainframe is in Delaware, and I am in New Jersey.
But I can easily imagine a situation where I'm in Manhattan, but the Linux machine is located in a data center in New Mexico, or even worse, Mumbai. Effectively, I have zero access to the hardware, so yes, in such a situation the machine is effectively "bricked".
If telephones are outlawed, then only outlaws will have telephones.
Why is SysFS deleting/erasing variables/files on RM? /dev/null by accident right?
Can't these be handled like special device INodes?
It is not like you can delete
Léa Gris
nuff said
Boy, Windows is so advanced that it fucks itself in the background, while you use it - no need to uninstall solitaire.
say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire
They do that with updates.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
To AmiMoJo: Sorry for the wrong mod.
A while back I installed Debian on an experimental system for learning more about Linux, and came away feeling a bit lost, because (compared to some other distros) there seemed to be oodles of new config files, scattered everywhere. Trying to keep track of them all was, for me, nightmarish. I wished all the config files were located in a single root-level directory (like "home"), perhaps named "cfg".
Well, if such a thing existed, that directory might be considered too valuable to be allowed to get included in any generic remove-all system command, and could thus be a safer place for the UEFI variables. One could go inside that directory and deliberately erase everything, but the specter of knowing that all the system's config files would be destroyed might give one pause,before daring to actually specify that command.
I've managed to mess up systems real badly by using aptitude and blindly accept conflict resolutions that involved removing and downgrading packages (or leaving dependencies unresolved). But that only happened because I thought I was smarter than apt-get (package xxx could not be installed? Bah! aptitude will fix that)...I had backups anyway.
I've never seen systems get messed up because of trivial apt-get operations otherwise (dist-upgrade between different versions is always hit-or-miss, though).
I have, however, seems windows systems become stuck in a reboot loop after a routine windows (critical) update, which is no fun to solve because you don't even get a console, or logs or anything. Not even live CD with some basic rescue utilities. Knoppix has saved my arse countless times in those situations.
I've also seen Windows get 'bricked' after an update as well as 'OS X'. That's 'bricked' from a normal user's point of view, I could usually fix the problem but then I have a CS degree. The same has happened with Linux boxes (i.e. 'bricking' that was fixable with a high degree of computer knowledge) but it's quite rare that it's so bad I can't even boot to command line. These days the most irritation I get from Linux is annoying glitches and bugs that are mostly due to poor quality control but that also depends on the distribution. Some distributions are way better at quality control than others.
guess what, I used the little ubuntu software center to uninstall it
xbubtu and the ubuntu software center
So the advice is: don't delete your all you files if you want your computer to work? Huh, whoda thunk it?
first
rm -rf /first/*.*
By the by, the above 'code' snippet may well brick a *nix box - use at your own risk. I saw first-hand that doing an rm -rf *.* was perfectly capable of blowing away an entire install (including all mounted devices), no sweat - at least as late as 2006 when a junior admin I once worked with made that rather horrendous typo in his regex...
But overall, why the hell is this news? I mean, every OS has this problem (see also the ancient deltree, or the newer rd /s, or getting stupid with the GUI Disk Utility in Windows or OSX, etc.)
Boys and girls, this is why you don't give ordinary folks admin/root/wheel/whatever privileges, eh?
Quo usque tandem abutere, Nimbus, patientia nostra?
Oh... now I get it - wipes the UEFI too... neat-o!
Quo usque tandem abutere, Nimbus, patientia nostra?
guess what, I used the little ubuntu software center to uninstall it
And what version of Xubuntu was this?
I've had that happen before, many years ago, with some other bit of software. You have to have the package manager remove old dependencies that it thinks are no longer required. Here's someone on the Ubuntu forum with a similar issue: http://askubuntu.com/questions...
I imagine the GP was trying to free up some space so asked for old packages that were no longer needed to be removed, and the package manager just decided to delete everything it had previously marked as no longer required. The correct behaviour would be to re-check all dependencies first, which I'm sure you can manually force somehow but that doesn't excuse this.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I think the transition of malware from mischief to profit puts a stop to that. I can change voltages on my motherboard with a software utility, if someone wanted to cause hardware damage they could easily do so in malware.
Xubuntu 14.04.3 LTS
*pay some fucking attention when you see more packages marked as remove than you bargained for and use ctrl+c to kill the apt-get command before it completes
I tried that once and it was pretty much the equivalent of shooting my package manager in the head. I ended up with a number of packages with conflicting versions that it couldn't figure out how to resolve, and I didn't know how to fix.
Don't do that unless your beard is sufficiently long.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Agreed.
``sudo apt-get remove blah'' should remove blah, and if nothing else is using them, dependencies associated with blah. It's crazy to nuke dependencies which are still in use by other parts of the system. I shouldn't need to use a flag to make that behaviour happen. That should be default.
So, be it under linux or windows ... (I guess BSD too with hard enough efforts) ....ill intentioned persons can brick computers running UEFI.
Now computers could potentially be bricked remotely... progress is an amazing thing.
And adding the "rm /" in the surface of exposure is kind of adding well intentioned clumsy persons to the equation.
And everybody knows that clumsy persons are more frequent than ill intentioned persons.
This makes systemd choices almost criminal in terms of risk management.
This is so boneheaded it beggars belief. The straightforward solution is to require the UEFI variable filesystem (or whatever it is called these days) to be mounted read-only, and require (UNIX anyway, but something analogous ought to work for Windows too) an application to do a "mount -o remount,rw" to do whatever it needs to do, then do a "mount -o remount,ro" when it's finished. Not as nice as having UEFI not be seriously broken, but workable, and there's not much of an excuse for things like systemd, openrc, etc. implementing this where appropriate (and for any UEFI crap that can brick a system, this is appropriate).
Applications don't like it? Tough, patch the damn things. Requireing firmware to be exposed to harm like this on any operating system is unacceptable.
The Future of Human Evolution: Autonomy
On at least Windows 7, you can get rid of the shell and it will still boot. You can open task manager with CTRL+ALT+DEL and launch programs. When you minimize a program, it goes down in the corner as a little bar just like it did in Windows 3.1
As late as XP, you could set progman.exe as your shell...which was weird.
Boot partition? You have no idea what you're talking about.
an rm -rf / will wipe EFI vars as well. The motherboard will not boot anything, regardless of what is on your drives.
Xubuntu 14.04.3 LTS
OK, now I know you're full of shit. There's no dependencies on sudoku in Xubuntu 14.04.
Tried it in the software center, too. There's no dependencies.
without systemd!
Why can't it be mounted as read-only, and remounted as read-write when necessary? Something like "mount -o rw [mount_point]" does that job.
On at least Windows 7, you can get rid of the shell and it will still boot. You can open task manager with CTRL+ALT+DEL and launch programs. When you minimize a program, it goes down in the corner as a little bar just like it did in Windows 3.1
As late as XP, you could set progman.exe as your shell...which was weird.
I didn't say crash explorer and dwm, I said uninstall it.
If the BIOS isn't even robust enough to use defaults for critical variables that can be deleted, then I'm gonna say this is OBVIOUSLY a problem with crappy BIOS code, not with the OS that ran the app that actually did exactly what it was told to do.
Snappy should fix this no?
> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
I can confirm this is the case: http://s23.postimg.org/yxo666n...
I didn't say crash explorer and dwm, I said uninstall it.
You said uninstall the taskbar. The only way to uninstall explorer.exe is to delete it and set the shell to something else (or blank). Windows will still boot. DWM isn't responsible for the task bar and has nothing to do with the discussion.
all I can tell you is that was the only thing I uninstalled, rebooted and im at a command prompt
Its gonna happen sooner or later anyway.
The difference is between an app and a (GUI) system component removal - the former should not have the impact that the latter does. I have seen this on several Ubuntu versions over the years when I wanted to get rid non-English fonts and other such language-related items I would not ever use to reduce update volume/frequency/directory clutter, and so forth. I was greatly annoyed to see the proposed list of components to remove did indeed include important pieces of the DE that I realized would break it badly if removed, so I had to quit that notion in those situations, and leave all those useless language bits littered all over my system directories.
Now if it was one particular app having that impact, I would just rename it, and/or turn off its execute bits.
One definitely needs to look before leaping with such actions (i.e. check the list of components to be removed before proceeding)!
YMMV
all I can tell you is that was the only thing I uninstalled, rebooted and im at a command prompt
Show me your syslog and I can tell you what happened. But your anecdote, as reported, is inaccurate: uninstalling sudoku had nothing to do with your DE getting fudged.
Why would you run rm -rf / in the first place?
Linux gives you disk damage anyway (Try dd if=/dev/zero of=/dev/sdXXX bs=1M)
I always tell new admins to type the path being deleted first, then type /bin/rm -r at the beginning of the line. Those pesky / and \ are too close to the enter key. Especially a problem for Windows.
Assuming you mean Ubuntu Snappy, kinda. The transactional updates will let you roll back changes (which is awesome) but it doesn't really fix the fact that package managers shouldn't be doing stupid stuff like that in the first place. The new package managers coming out of the major distros should hopefully fix a lot of the problems with the old ones.
It's a little worse than that. At least on Ubuntu, the package manger is pretty aggressive about removing old stuff. When you install or uninstall a package it mentions that it found all this old cruft, and would you like to remove it (Y/n)? A regular user is pretty likely to just say yes. You don't need to specifically be trying to free up space.
It used to be done on purpose on sacrificial systems to show how processes stay resident in memory. Now they have to be really sacrificial.
and have "pre-released updates" box checked in software updates, you will bork networking if you do an update. The only way to fix it is to download the stable libnl packages from another computer and transfer them with a flashdrive and reinstall them. I'm a Linux fanatic, but this was a major boo boo on the developers part. And what idiot would run rm -rf on any Linux system? That's just clickbait for Windoze idiots.
The most common implementation of rm on Linux (GNU coreutils) does exactly what you're asking.
That would be violating POSIX by allowing it at all:
If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands.
* http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html
Solaris and FreeBSD rm(1) do the right thing as well:
* https://svnweb.freebsd.org/base/head/bin/rm/rm.c
* https://web.archive.org/web/20061101213104/http://blogs.sun.com/jbeck/date/20041001
I'm sure selinux could be configured to allow systemd to access the uefi variables file system, while silently blocking everything else.
That said, I tend to disable selinux as it never causes anything but pain when silently stopping things from working with little to show for it.
It might be for the benefit of non-technical users who don't understand that the chat or forum user recommending sudo rm -rf / is up to no good. At least if the system is bootable from install media, the user can restore /home from backup.
I doubt very much he told apt to remove his window manager. The apt system (either apt itself or some Ubuntu package(s)) has some buggy bits that don't do so well keeping track of dependencies. As someone else pointed out, this is probably the code that looks for unneeded libraries. The OP wanted to remove his game, but apt said "by the way, here's some other stuff I found that you don't need anymore, want me to remove it?" and the OP hit yes (sounds like a good idea, no?).
You can't do the same thing in OS X. I don't know about Windows. The app store can't remove or modify system files unless you're explicitly installing an OS upgrade.
In general, programs on the Mac are much more self-contained, at the expense of a bit of replication of libraries. The OS X bundle/framework paradigm is excellent, and well worth copying. I'm not sure what app store Windows does, but in the past this kind of problem in that OS was known as "dll hell." Linux has much of the same problem, and the currently implemented fixes are pretty clunky.
Linux package managers are well overdue for redesign.
I'm sure Pottering will oblige in due course.
Why is this being modded "Funny"? They're actually working on it:
* http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
I use dd if=/dev/zero of=/dev/sda instead.
Would it be possible to hide the real files, make some FIFO buffer files which are read by a gateway program, which then queues writes to the real files?
* Remove immutable bit.
* Write to file.
* Set immutable bit.
You'd have to get seriously unlucky to wipe those files out after that.
rm -rf /first* is sufficient. Why the *.*? There is no need to remove only those with dot and in the first subdirectory. If you believe you need to match the dot otherwise the * will match only everything before the dot, one day you will be in deep trouble.
Achille Talon
Hop!
MS Windows teaches children to use that junk because of its way of handling file extensions. =/
In most cases, electronic devices should be able to be reset back to a factory state by their owners, preferably with a hardware switch that cannot be disabled by any software.
Exceptions would be for things like car-odometers/disk-drive-power-on-hours logs that need to be kept for fraud-prevention or things that the customer himself doesn't want to be re-settable, like anti-theft protection.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Anyone?
Millions of european Facebook users, journalists, NGOs complained for years about siphooning of private data over to US, achieving nothing. But in reality, it took only ONE determined student of law to actually TAKE LEGAL STEPS and KICK ZUCKERBERGS BALLS at the European court of justice.
If you really care, take action.
No. rm -rf / means reinstall or restore from backup. The non-obvious part is that your motherboard may never boot again.
Except he is in fact a liar. As others have confirmed in this thread, removing sudoku via apt-get does not remove xfce. In fact it doesn't remove anything but the actual sudoku app.
So I'm sure he issued a bunch of other apt-get commands he has conveniently forgotten to mention here because he had no idea what the hell he was doing, and then he goes on to blame Linux and apt-get for his own willful ignorance.
The *.* catches the '..' , causing the rm command to jump up a directory (eventually to / ).
Quo usque tandem abutere, Nimbus, patientia nostra?
Running your car straight into a wall at 90mphrenders it useless.
I can see this happening, MAYBE. But only because he installed all the dependencies when he also installed the game. When he tried to uninstall the game, it took all the dependencies that were installed when the game itself was installed. MAYBE.
That would be the ONLY case where I could see something like that happening. Again, MAYBE.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
The mental model of a file system - the expected behavior - is for it to be hierarchical. We silently expect anything below a certain path to be subordinate. Already this model is broken because devices can be mounted, files symlinked/hardlinked etc. That something much more fundamental to a system than a file system directory can be found deep in the hierarchy is a violation of the hierarchy.
That's why it is surprising that removing everything from the file system may cause higher order information to be deleted as well. You do not expect that. The impulse to map everything to a file deep in the filesystem is dangerous.
Sure, you can probably write/destroy UEFI variables from windows, but not as unintentional collateral damage from deleting a directory.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
The standard test case for UEFI seems to be, "Does it boot Windows?" Those drivers tend to be really buggy.
"First they came for the slanderers and i said nothing."
Death to the UEFI menace.
BIOS+MBR forever!
Since a "few years", on "most distros", you need to pass --no-preserve-root to rm rf slash to actually do something.
Just out off office; too tired to look up exactly :
But a "few years" is about 3-5 years
"Most distros" means maybe >90% of the linux userbase
Some other unices got that new default, but as other unices are often older systems, i wouldn t bet on the userbase percentage
Anyone who's been reading the linux kernel mailing list since the 90s knows that most PC vendors ship BIOS/firmware/whatever that is often half or mostly broken.
Power management, in particular, is pretty bad. It's so bad that Microsoft ignores the system firmware and implements their own power management scheme, complete with a white list of known hardware and workarounds.
Why did anyone think UEFI would be different?
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
On Windows, uninstallers cannot delete system files. Since Vista, Windows Resource Protection has prevented even processes running as administrator or SYSTEM from changing/deleting system resources (files, registry keys etc). Only the "trusted installer" account can write those files, and only the WindowsUpdate process runs as trusted installer. It will not install 3rd party applications.
Not saying that an uninstaller cannot do other harm which could toast the boot process, but it cannot delete system files. Safe mode will trust *only* system files, and should always be able to load - bar hardware failures.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
He's already talked about doing so and I wouldn't be surprised if he's started. He wants to standardize pieces of linux that have been a nightmare of aging incompatible code. A natural stop on that path would be Linux package managers. As much as I love Apt-get, and I like emerge they all ultimately suck. They call it dependency hell for a reason.
Ultimately we'd all be better off if someone could figure out a better, more robust and more modern solution to Linux Package managers.
You make a good point, though it probably requires some degree of actual knowledge and skill, or at least a suitable malware toolkit, to cause damage by playing with electrical levels. Any script kiddie can do 'rm -rf /' and surely it's practically the first thing any mischief-makers will try.
It's still crazily easy to do this by mistake as well, though.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You can't do the same thing in OS X. I don't know about Windows.
Windows has had Resource Protection since Vista. Even before that, Windows File Protection going back to Windows 2000.
Only Windows Update can run as "Trusted Installer" - and only trusted installer is allowed to replace or change system files.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I'm not going to change out my engine because tyres keep blowing, I'm going to stop driving over glass.
If there is a way to stop rm~ from killing a machine, if it's a situation I ever come across (I haven't had to think about it, to be honest, beyond noticing a system partition of 300MB on my notebook and thinking to myself "You know, that looks important, better make sure I've got a backup"), then I say thank fuck for Replay and shadow copies.
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
My Grandpa was very fond of one particular expression. From time to time, I would ask him what would happen if you did X, Y and Z, where such a combination was likely to result in a Bad Thing happening.
His response was usually, "Well, you just don't do that."
www.wavefront-av.com
Then have those EFI variables mounted read-write when it's necessary to write to one of them. It's not like mounting something readonly sets it in stone until the end of days, and it is probably just as easy to handl
If those other applications can't handle a simple error state that they can trivially recover from, then they're likely to already be broken. Either that or they're weak command line programs trying to infiltrate the strong command line program paradigm.
TL;DR: Colonel Lazyness gets promoted to General.
+1 to you for circling back once you got that it bricks the system (and not just the install).
Next up, instead of encrypting your files, they'll just demand a bitcoin or permanently ruin your hardware...
Peter predicted that you would "deliberately forget" creation 2000 years ago...
If you can brick your motherboard from userland, then so can malware.
Isn't this the kind of thing that the immutable attribute was designed for?
What is this newspeak "network stack" that you are referring to?
Last I checked, the "network stack" consists of things like TCP, IP, the physical layer, and other such mumbo-jumbo that is entirely done in the kernel and has fuck-all to do with userland.
Kid-proof tablet..
They call it dependency hell for a reason.
or DLL hell.
That's only fixable if we abandon the .dll or .so or whatever and have everything statically linked for every program.
Not gonna happen.
--
BMO
$ grep EFI .config
# CONFIG_EFI_PARTITION is not set
# CONFIG_EFI is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
A bad rm -rf /. would nuke a system...it wouldn't BRICK a system.
Nuking a system is fixable....
boot from a floppy (or something else)
format harddrive
reinstall.
Brick - throw system away. You're done.
Just don't
Dont. Use. UEFI.
This is a massive security problem, someone could run this on 10,000 servers in parallel all at once and the business would be down for months replacing all the motherboards. Figure $500 and 1 hour per motherboard replacement and you are looking at 10,000 man hours and $5 million dollars in hardware damages alone.
The glob expansion won't do this if you start with "*" so it shouldn't search hidden files or directories.
Man, how do you still have a job? "Install from minimal base system" is the right response, not "leave massively pointless userspace attack vector installed because I don't know the difference between a TCP/IP stack and networkmanager".
You didn't simply uninstall sudoku. When your package manager said "hey, the desktop metapackage depends on sudoku, do you want me to uninstall the whole thing?" you said "Yes". Innocent mistake perhaps, but not the package manager's fault.
"...Windows and other operating systems are also prone to this issue when using UEFI"
Well, no. They have the same underlying potential problem, yes... but Windows isn't susceptible to the rm -rf / since it doesn't, by default, have the rm command. These two aren't quite the same thing. The summary makes it sound like there's parity between Linux and Windows but that's not accurate. It takes about 20 lines of code (as per the article) to do the same thing on Windows. So yeah, it's a legitimate UNDERLYING problem, but let's not make it sound like it's the same situation on both platforms 'cause it's not really.
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Not only did it erase the firmware on my motherboard, it also deleted all of my files!
1) Store EFI variables in two in 'special' partitions (flag one as current, and one as stand-by). Do not mount either of those partitions, EVER.
2) On boot, do a bit-for-bit copy of the 'current' EFI partition to a third, 'live' EFI partition. Mount *that* partition read-write.
3) On shut-down, or any time you need to save values, do sanity checks of the EFI data before doing a bit-for-bit copy of the 'live' EFI partition over the 'non-current' version, then flip the flag to mark *that* one as current, and the other as stand-by.
4) If the system can't boot from the 'current' EFI data, flip the flag, so the 'stand-by' copy is now the 'current' copy.
5) If the system can't boot from *that*, get the EFI settings from the hardware, replacing *both* the 'current' and 'stand-by' partitions' content.
Since the hardware is treated as a emergency, default-state restore cache, you never write to those via the OS.
Ideally, the hardware should prevent you from bricking it, but this will allow the OS to mitigate the risk of something wiping hardware-only EFI values.
Yes, yes. We all already knew that but don't let that stop you from posting some flamebait troll garbage! You didn't even try to disguise it as a response to someone claiming such. You just threw a new thread out there as if that's all we're talking about. Even TFS isn't blaming it. And this bullshit gets a +5 Informative! Just because he has a 4 digit UID doesn't means he's a freakin soothsayer people!
The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
Bricking a motherboard due to a bad firmware flash has been a serious concern for a long time (due to power-cut, or a bad floppy, or whatever). Support for any sort of backup firmware has always been sporadic. So I won't hold my breath.
First to actually type "rm -rf /"?
...is not subject to this ludicrously dangerous vulnerability, and systemd is?
I mean, effectively, that's the reality on the ground right now, right?
I've been neutral on systemd, more or less, but...
The last two motherboards I've bought boasted twin BIOS chips, such that if the active BIOS was corrupted a quick jumper connection would copy the read-only contents of the backup chip to the active chip, providing an easy out from a possibly bricked computer. Sounds to me like the affected motherboards didn't offer a similar feature for EFI, and were very cavalier about how they stored their system-critical data, so we should file this bug under "lazy/negligent mobo manufacturer".
That said, the kernel should be a bit more careful when applying "rm -rf" to EFI vars. When I decide to send my current setup to oblivion, I'd prefer it not take my hardware along for the ride.
Good excuse to get control over your own hardware. Bring back BIOS, /init and /var/log/messages. Systemd and UEFI can stay - just so long as they add 'emulate old ways' settings :-)
21st century CIH.
There is no need to reset the boot loader.
Most consumer machines do not even come with a replaceable operating system.
If the system gets hosed or riddled with viruses you just buy a new one. Does not happen very often. People accept that.
You hark back to days when you could have some understanding and control over your machine. Those days are long gone. Think about how a teenager interacts with a computer. That is the future.
But your anecdote, as reported, is inaccurate: uninstalling sudoku had nothing to do with your DE getting fudged.
It is not inaccurate at all. *YOU* are unable to reproduce the bug. That doesn't mean the bug does not exist or that others have not run into it. I guess logical thought must be a tough thing for Linux cheerleaders like you.
you need for the BIOS to be a read-only thing that can only be written from another computer. Yes, it can be rather inconvenient to have to have a removable BIOS stick, but it would be simple to recover from this by just removing the stick and re-writing it on another machine. http://www.pcworld.com/article... Having a read-only BIOS is great against hacking also. It also makes bios upgrades safer. You just have two sticks and always keep your old one as a backup.
"Running "rm -rf /" Is Now Bricking Linux Systems " /" Is Now Bricking UEFI Systems"
No shit that bricks a linux system. It has been for over 20 years! It is the "delete system32" equivalent of the unix world, except that it will also erase any user files as well.
Please use a better title like "Running "rm -rf
also
"Systemd developers have rejected mounting the EFI variables as read-only"
God dammit systemd. Why is it always you behind shit like this.
UEFI is the problem. Whatever 'enhancements' it brings belong as OS services.
Ever since I had the same problem, I just install the base system from ghe installer and do the rest with commands to get rid of those hiccups. I lost entire GUI after uninstalling a simple game when I wasn't experienced as I am now
or hasn't that particular command always been a case of id10t pebkac?
I actually tried this with rm -rf -i /first/*.* but it didn't work. Maybe they fixed it?
Nope, it doesn't remove "the network stack". It by default removes the now unneeded nicer GUI-centric frontend network-manager, but you can of course still get online using the standard cli tools, which you would prefer on a server anyways.
Also, wtf do you mean by "leave the GUI installed"? Why would you install it in the first place if you don't want it (it is literally one checkbox in the installer)?
Linux package managers are well overdue for redesign.
Perhaps so, but there's nothing on any other mainstream operating system that can compare in terms of software management.
And no, the OSX and Windows App Stores don't come remotely close.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
not.
Why not do a minimum netinstall and build off that?
I'm surprised you do not already have been aware that the problem is actually the simple fact that the attempt to remove an application can remove much of the system. you're really, really stupid know?
Is it the grub command prompt? If so, your drive has bad sectors (hardware fault) and the boot loader can't find your boot partition. Throw the disk in another computer and copy the data ASAP!
> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
Actually, it could. Imagine you have a virtual package, say xfce-environment, which depends on sudoku and everything else XFCE. This package is the only package that is explicitly installed, and through it you got your DE. The system is configured to automatically remove packages that are not explicitly requested (mine works that way - when I remove a package, any package that is installed solely because it's a dependency of that package is also removed). So, luser uninstalls sudoku, which forces removal of virtual packagee xfce-environment (since this virtual package has a dependency on everything, including sudoku), now every single other package that xfce-environment depended on, which has no other reasons to exist on the system, will also be uninstalled. I can see this happening, and have seen similar situations myself.
Now, I don't think the system is in the wrong here - the user should probably have paid a bit more attention, but I do not think his story is necessarily false.
May we live long and die out
Don't forget the scripts that fail to work with path names that contain blanks! This is quite common on OS X when the hard drive is usually named "Macintosh HD". (I renamed mine to "Macintosh-HD" just in case.)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Or it may simply be unable to access things like USB and SATA controllers when their configuration is erased. If it was unable to access keyboard and display, you wouldn't be able to use a "reset to defaults" option, if there even was one.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Clearly you don't know much about *NIX if you think that a file system is the same as a hard drive, and that every directory entry in the file system corresponds to a collection of sectors on a hard drive. Besides, this isn't even about deleting everything from the / root, you can also start at the root of the fake file system that represents the EFI variables, or do a recursive delete that goes backwards like "rm -rf .*".
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
You're surprised that crappy programmers that don't even think about such possibilities are employed to do BIOS work for motherboard companies?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Are people seriously advocating for systemd to be a babysitter for the root user? I would definitely be more upset if systemd posed restrictions upon what I was allowed to do (as root). But, sure, I understand the problem (which Etcetera seems to be the only one to touch upon) that systemd makes it harder to strengthen the security by generally limiting the possibilities to customize your system.
People who come from a DOS/Windows background also seem to think that "rm -rf /" should be expected to work like "format c:". But the root is not just the (first) harddrive and as a user of Unix (where "everything is a file") I would rather translate it to "delete everything there is to delete, yes really". I wouldn't find it strange if stuff on the network got deleted too, not just regular files but printer queues and whatever. Not to mention all sorts of flash memory of any sort of attached device.
If anyone is to blame here it's the BIOS developer I think. A more robust implementation would have some fallback code in ROM that lets you at least install a new flash image. But while PCs have generally been quite robust (until now), where have been other more easily bricked systems. Sometimes you can remove the flash IC and rewrite it. Sometimes you just have to toss the hardware. It's annoying but it doesn't make me blame the software for not preventing me from doing the mistakes I did (which wasn't simply running "rm -rf /" by the way).
I'm guessing it refers to NetworkManager, the GUI tool for finding available networks and configuring interfaces to connect to them. WLAN in particular is a lot more complex than ye olde ifup eth0.
I prefer rm -fr / because then in my mind I can blame it on the French.
.. of course it would be quite easy to design an in-circuit programmer, but generally they were read-only with the exception of a UV light or being left on a window sill ..
I had an XP laptop once that apparently couldn't take a certain Windows update. After that one, it would just stop and hang at random intervals, requiring a restart. I was going to use System Restore to figure out which update, but when I started the bisection process it stopped and hung in the middle of replacing a file needed for the user interface (don't remember which one), so I had to boot from floppy, figure out which file was missing, download a copy somewhere, and replace it before I could boot Windows again. At that point, I just System Restored it back to when I got it, and decided never to buy a Compaq laptop ever again. That particular decision has become a bit easier to adhere to, to be honest.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
The comments here are why a lot of level-headed people have a prejudice that anti-Linux comments are likely from haters. This is not a Linux problem. The fact that this report shows how the problem can come up while running Linux doesn't mean it can't or won't happen on any other OS.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
To preserve this capability, Windows 10 does its best to not give the user a choice about accepting updates.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Using your reasoning, all ACs are idiots who don't know what they're talking about.
After all, you're describing one specific event, which probably didn't happen quite the way you tell it (whenever I get sufficient information about such a story, there's almost always important things left out), and concluding from that that Linux is screwed up.
To quote a friend, "Everyone generalizes from one example. I know I do." However, this friend actually knows it's a joke.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I'm surprised that you've included a dot in that - it'd be more effective to run rm -rf /first/*
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
No, it also happened to me. I uninstalled one small thing, and half of Gnome got uninstalled with it.
Do you know why uninstalling minesweeper kills the OS? Because Linux sucks, and the package system is broken beyond repair, so the Gnome developers came up with a 'smart' hack to make installing Gnome easy. They release one "mock" package that depends on everything file inside the distribution, so when you install that package you also install everything. Simple!
Except if you don't want minesweeper, or in my case disability support. You uninstall it, and then you break the dependencies of the "mock" Gnome package, so it also gets uninstalled, and then aptitude or apt-get tries to be smart and destroys even more things. When you report the problem to the Devs, the answer is "do not uninstall anything, and problem solved", or "we don't want to go the MS route". So, I did the sensible thing and uninstalled Linux.
but if you are happy with your shitty OS stuck in the 70s, you can keep using it.