[kwlug-disc] Adventures in dual boot land...

[Chris Irwin]

On Tue, Feb 07, 2017 at 06:17:59PM +0000, CrankyOldBugger wrote:
>A couple of months ago I picked up an M.2 drive for my main desktop, with
>the intention of loading Ubuntu on it for a dual boot setup with Windows 10
>on the other drives.  It's part of my big plan to completely eliminate
>Windows from my systems.
>
>Last time I did a dual boot was when Microsoft first started pushing
>EFI/UEFI/Secure Boot and that sort of stuff.  The solution at the time was
>to turn these features off in the BIOS if you wanted to install Linux.  So
>I did the same thing this time around when I tried to install Ubuntu on the
>M.2.

A lot of people link UEFI and Secure Boot together, when they're really 
quite different things (although the latter depends on the former).

UEFI is great. Seriously. It *is* different than what we're used to, but 
BIOS booting was such a pain, particularly when dual booting. Most of 
that is solved with UEFI. No longer do you have to worry about windows 
"taking over", or blowing away GRUB.

It does take a bit to learn, because it's different than BIOS booting.  
Those differences are mostly good.

Regarding UEFI problems, most were due to particularly buggy 
implementations. For the most part, those have been either patched or 
worked-around (and afaik, there are very few issues on currently 
shipping hardware).

For example:

* Early on, Samsung had some lovely behaviour that would brick laptops 
sometimes if poked just right. This was not a Linux-specific issue, 
though it was reported as such originally.

    http://mjg59.dreamwidth.org/22855.html

* Some machines (Lenovo thinkcentres) were doing weird things that 
"passed the tests" but is stupid. Like refusing to run a bootloader 
unless it identified itself explicitly as "Windows Boot Manager" or "Red 
Hat Enterprise Linux".

    http://mjg59.dreamwidth.org/20187.html

* Some of the "early" UEFI equipment had some really glaring issues that 
were never patched. My own server at home actually hangs when attempting 
to register a new UEFI bootloader. That's not desired behaviour, but 
little I can do to fix it. This is perhaps worse because it's an actual 
Intel-branded motherboard, with an Intel UEFI. If Intel could mess up 
their early UEFI servers...

    http://I haven't written this yet.


Now Secure Boot is a different beast. It's simply verifying signatures 
of your boot loader, etc. Compare that to the Lets Encrypt talk from 
yesterday: Signatures are all well and good, but you (and your system) 
need to initially trust somebody to get the ball rolling. For consumer 
hardware, that's Microsoft.

I won't get into the politics of why Microsoft is running the signing 
organization, or how I don't think that's an entirely bad position 
currently, and how they've actually done a mostly decent job in the 
role, surprisingly. This would be a whole debate on it's own, and some 
theoretical "Lets Encrypt for bootloaders" would actually be worse for 
security. But I digress...

>From a windows point of view, you can be relatively sure that your OS 
itself isn't compromised, and it can be trusted to behave properly 
(insofar as you trust Microsoft. But if you don't, then why are you 
running Windows).

Secure Boot itself could be a desireable feature even if you don't trust 
Microsoft. If you install and trust your own keys (and remove 
Microsoft), you can then self-sign your boot chain. You can then be sure 
that only the components you've configured/signed are loaded, and no 
"evil maid" has altered your system (aside from hardware keyloggers, 
etc).

To use myself as an example, I need to type a passphrase at boot to 
decrypt my disk. However, I don't have any way to verify that the screen 
I'm typing my password into is actually *my* boot-time password screen, 
or a lookalike booted from USB/replaced on my system/etc). Secure Boot 
can solve that problem.

In practice, there seems to be little interest or tooling around 
entirely self-signed boot chains. That said, while I do have UEFI 
machines, I don't have any that support Secure Boot. So I haven't played 
around with it, or researched any of the tooling to self-sign your boot.

Most Linux distros are signed with a trusted key already (yes, via 
Microsoft), so you probably don't need to disable it.

>So the setup is:
>
>/dev/sda is the Windows 10 SSD
>/dev/sdb is a 1TB HDD for the Windows side
>/dev/sdc is the new M.2 for Ubuntu
>/dev/sdd is the USB stick for installing Ubuntu from (and of course only
>temporary)
>
>I ran in to nothing but trouble with this on this install.  Ubuntu seems to
>install fine, for the most part, but it always failed when it came time to
>writing GRUB on the Windows 10 disk. I tried going with different sorts of
>partitioning schemes, using GParted to set up the linux side prior to
>installation, I even tried other distros such as Fedora to install.  Just
>couldn't get past the "writing GRUB" part.

What's likely happened is you have an EFI Windows 10 install on a GPT 
disk. This is normal.

You were trying to install Legacy BIOS Ubuntu, installing GRUB to the 
windows disk (because it's /dev/sda, and that's where BIOS magic 
happens). BIOS Grub on a GPT disk is a problem.

The problem is that Grub stores it's core.img in the "Post MBR Gap".  
Basically, the unused space before the first partition actually starts.  
However, on an GPT disk, this space isn't available. The solution is to 
create a small (1MB) partition of the appropriate type. Grub will 
recognize this and use it. However, if you've already partitioned the 
drive, you're SOL.

Some more information about booting with BIOS grub on a GPT disk:

https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions

>So, with nothing else to think of, I turned on the EFI stuff in the 
>BIOS,and sure enough, Ubuntu was able to write GRUB to the Windows 10 
>drive with no problems.  I now have a working dual boot configuration 
>(and as a bonus, I haven't booted into Windows since the install).

The "proper" way that Ubuntu should have installed, using UEFI, on 
/dev/sdc is to create a new EFI partition, likely /dev/sdc1. Ideally, 
you could remove your windows drive and still have properly boot Ubuntu.  
And vice versa.

Doing this on a BIOS system would be.. problematic. GRUB would be on 
/dev/sda, but it's stage2 would be on /dev/sdcX (your /boot partition).  
Removing either drive will result in an unbootable machine. Joy.

>I mentioned this to a few friends of mine and one of them seems to think
>that the new M.2 drives require EFI (or UEFI, whatever) to be turned on for
>proper operation, but I haven't been able to confirm this yet.

Depends. You were obviously able to see the drive after booting via BIOS 
mode, and (disk formats aside) nothing would stop you from installing a 
bootloader on one.

However, m.2 is just a connector. The device itself could be either USB, 
SATA, or PCIe (NVMe). It's very probable that NVMe booting would depend 
on UEFI firmware support.

-- 
Chris Irwin

email:   chris at chrisirwin.ca
 xmpp:   chris at chrisirwin.ca
  web: https://chrisirwin.ca