I'm going to install Elementary OS on my desktop computer( i3 550, 4GB RAM), is there anything that I should note before I go for installation? I've heard that Linux distros are not as compatible to computer hardware as Windows OS-es ,so is there going to be a problem?

  • 3
    "I've heard that Linux distros are not as compatible to computer hardware as Windows OS-es" Where did you hear that? Dec 11, 2016 at 20:42
  • Can Windows damage computer hardware? Dec 11, 2016 at 22:01
  • +1 where did you hear this claim. It might not be notable enough to consider.
    – user394804
    Dec 11, 2016 at 22:04
  • Technically, and operating system can damage hardware if the hardware controllers allow it to.
    – user394804
    Dec 11, 2016 at 22:04
  • 2
    A can of soda has a better chance of damaging hardware than an OS does. Dec 12, 2016 at 0:21

5 Answers 5


In theory: can any software (including Windows) damage hardware: Yes.
In practice: no.

Linux is no different from this than any other OS. Same (lack of) risks as windows, OSX, MacOS (classic), FreeBSD, netBSD, OpenBSD, QNX, ...

not as compatible

Uh, I would say precisely even compatible. No less, no more.
But I suspect that you mean "has fewer drivers or gets them later". In which case it will simply not fully recognise part of the hardware. It will happily work. You can boot, edit files, run Firefox, etc etc. But do check if there is a driver for any exotic hardware.

This is no different from Windows. Especially when upgrading with older devices for which the manufacturer does not write updated drivers.

  • I just installed Ubuntu and it totally bricked my GPU and my Audio. Never touched the windows partition and now Windows can't detect gpu or speakers in its device manager, and lspci in Ubuntu shows neither. Since in the three laptops I tried putting Ubuntu on, all from three different companies all have caused me to spend 200 hrs+ installed and uninstalling drivers and reinstalling ubuntu over and over again, I thought it was bad but usable. But now Ubuntu has successfully bricked a $2000 new laptop with a gtx1060, so I think it's over. Linux on desktop sure, but never laptops. Oct 20, 2019 at 2:26

Ideally, no, Linux (or any other software) should not be able to physically harm hardware. Not having drivers might mean that you can't use certain pieces of hardware, but you certainly shouldn't be able to damage them, either.

Unfortunately, there have been cases where cheap or poorly-made hardware is brickable by software. For example, a lot of early UEFI firmware didn't properly write-protect certain things, leading to the ability to overwrite vital data and destroy your motherboard [1] [2].

Linux won't hurt your hardware any more than any other OS would, but there are certain things that it can't protect you from.


Only faulty hardware.

  • Scandals happen. The UEFI brickage (mentioned by muskox) is a nice, but rare, example.

  • Hardware that misreports its features is actually not that uncommon. For example, SSDs that claim to support qued trim but don't, and SATA controllers that claim to not support SATA link power management but do. The consequences are data loss and poorer battery life respectively, but hasn't resulted in physical damage, AFAIK. These devices end up in shameful blacklists and whitelists in the drivers, and the world moves on, but means that a too old kernel for your hardware is risky.

  • For some unfortunate hardware, missing drivers means missing power management. For newer GPUs, that means you'll be stuck at a low performance setting, which is safe. But if you're stuck at high performance, and there is not enough cooling for this amount of power, and the component doesn't turn itself off when it gets too hot, it will overheat. That would be a design flaw, as the same could happen if the OS hangs, which can also happen to Windows. I've heard of laptops getting hot because both GPUs stay active, but I think they shut themselves off before it gets dangerous.


tl;dr... Yes, technically, but it's not really the OS's fault.

Certain storage media types (Solid State Disks, SDCards, various other flash based media) have a limited number of write cycles that may elapse before physical degradation of the storage substrate materials begins to occur.

This kind of damage is usually mitigated by wear-levelling algorithms built into the media device itself. But once the rot has begun it tends to accelerate because there are fewer and fewer remaining places to put the wear-levelled data!

You could easily write a script that forcibly writes several terabytes of data to a cheap SD Card and you'd find that it would be damaged quite severely (if not fatally) by the end, which would take several weeks (I know this because I've done it :)).

This is not OS specific, and so while Linux can do this, so can any other OS as well.


Here is an article from SlashDot talking about how rm -rf --no-preserve-root / has bricked UEFI motherboards due to the removal of EFI variables:

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.

Here is a post from a user on AskUbuntu detailing their experience with rm -rf --no-preserve-root / bricking their motherboard:

However, upon restart, the monitor was not receiving any input at all. Also, the HDD indicator (or whatever the red light was) wasn't doing one thing. (It was off, in fact.) The fans were working and the DVD drive was, though. (I don't think that there is a PC speaker in there, so if you need some beep error codes, sorry.)

With the answer:

Point 1: Deleting /sys/firmware/efi/efivars/ should thrash your EFI configuration, but in a properly implemented EFI this should be recoverable.

Point 2: There is some pieces hardware out there with broken/poorly implemented EFI, which will can be permanently bricked by doing standard conform stuff to them. See for example the case where Ubuntu bricked some Samsung laptops by storing additional data in some EFI memory. This behaviour was fine by standard but broke this particular implementation.

Point 3: Running anything as root that writes to /dev/sda will destroy your partition table and/or filesystems. That's bad especially if you have no backup, but after partitioning, creating new filesystems and reinstalling your OS your machine will work again. So you can recover from it by booting some other media and redo your installation.

Point 4: Thrashing your EFI is a whole different kind of problem. In the worst case you won't be able to do anything with the machine as it will not get to POST. No booting from an other media, no entering some EFI utility to fix missing stuff. A that point your computer is a really expensive paperweight.

The problem occurs in distributions that run systemd and mount efivarfs writeable (at /sys/firmware/efi/efivars). Systemd needs to write there, so distributions using systemd are affected. However, there seems to be no indication that Upstart systems are affected.

Not the answer you're looking for? Browse other questions tagged or ask your own question.