Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an unusual case. I'm not trying to partition drives or anything, I have separate physical drives for Windows and Linux. Being a new machine and all, I have UEFI.

Last time I attempted to install Ubuntu 12.04, it worked fine but it destroyed my windows install. Changed the format of the drive or something and messed up the MBR. This was 6 months ago, so sorry for the lack of technical insight -- my memory is a bit off. Wasted a lot of time reinstalling Windows, and I gave up for awhile.

Now I'm trying it again (after 12.10 was a technical disaster, repeated unity crashes and whatnot) but I currently have my Windows drives disconnected so my Ubuntu install can't mess it up.

I figure my future bootloading will involve selecting which drive to boot from, but I'm worried that GRUB might take it upon itself to mess around with my Windows drives the moment I boot from it. Is there any way I can be certain that I won't have my Windows partitions corrupted again? Last time it took over a day to reinstall everything, this time I suspect it'll be much longer.

On the other hand, I really don't want to be physically unplugging and replugging drives whenever I want to switch operating systems. Selecting drives is weird, but I can at least live with that...

share|improve this question
See here - . Read the bugs first. Good luck – Web-E Feb 2 '13 at 20:14

The only way to guarantee that one OS won't damage another one in a dual-boot configuration is to put the OSes on physically separate drives and disconnect/reconnect them to keep them from ever co-existing. I expect the risk of damage from an electrostatic discharge or physical trauma in this configuration would far outweigh the risk of software damage, though.

You can achieve an intermediate level of safety by installing one OS in a virtual machine (VirtualBox, QEMU, VMWare, etc.) within another one. The guest OS is then unlikely to be able to do serious damage to the host OS unless you give it low-level disk access. You could trash the whole guest OS just by deleting one file, though.

Your description of your original problem is far too vague to offer an opinion about what happened. As a general rule, though, Linux distributions, including Ubuntu, are fairly good about co-existing with another OS. Accidents can happen, of course, but they're usually the result of user error rather than the OS going berserk.

Note that an EFI-based installation uses different rules for boot loader location and use than does a BIOS-based installation. There are currently a lot of problems related to EFI on Linux, owing to both firmware bugs and the immaturity of Linux distribution support for EFI. These issues are more likely to result in boot problems than in trashed data, though.

share|improve this answer
Those EFI problems are about UEFI secure boot. Plain UEFI booting has been working for a few releases, with the exception of Samsung where a driver accidentally operated in a space that was never meant to be used by UEFI and therefore safe. Unity requires 3D acceleration and is very slow without in virtual machines. Also if you are not touching a file system and are not modifying the partition table the data on the file system is safe from the operating systems point of view. – LiveWireBT Feb 3 '13 at 16:20
No, there are loads of EFI problems that are not related to Secure Boot. Mostly these are caused by buggy EFI implementations. For instance, some computers refuse to use anything but Windows' boot loader (based on its description); and others "forget" EFI boot loader entries as set by efibootmgr. Some problems are caused by distribution bugs, too, although Ubuntu's fixed the worst of its EFI-specific bugs. – Rod Smith Feb 5 '13 at 0:31

It is not clear to me what you currently have and what you want to achieve. You have a UEFI capable machine and 2 hard drives. So far so good. But what is the maker and model name of the machine (some manufacturers have weird kludges)? What version of Windows do you have installed? Is it really booting in UEFI mode? Does you Windows hard drive have a proper GPT UEFI partition table? If you have Windows 8 you should disable fast startup and probably do not write to the file system from within Linux if you want to be sure.

If your Windows partition does have the legacy MBR layout and is not booting in UEFI mode then you could either install Linux in traditional MBR mode too and choose at boot which drive to boot or you could install in UEFI mode (you have to boot the install medium in UEFI mode) and choose to put a complete UEFI setup (EFI system partition, EFI loader for grub and registering the grub loader in the firmware) on the drive you choose.

All in all dual-booting traditional MBR setups hasn't changed just because a UEFI firmware is working in the device. Installing to separate drives is even less dangerous while staying in legacy mode.

I'd like to add that I bought a new UEFI capable laptop back in June last year that also came with the traditional layout installed. One can also boot a traditional Windows installation in UEFI mode from Ubuntu's GRUB bootloader if done right, thus removing the need to remove drives or bring up the BIOS/firmware boot menu.

The UEFI article from the Community Documentation in the comment above seems to be a good starting point.


  • You should check your machine for known UEFI issues first before attempting to install Linux in UEFI mode.
  • It would be interesting to know what went wrong las time you tried to install Ubuntu.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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