Dual boot Windows 10 and Ubuntu 15.10 Linux on HP Envy 13 D008NA

My eldest daughter has flown the nest and gone to university. For her first term, she took her trusty 7 year old Acer Aspire netbook with her. With an unofficial memory expansion and a conversion to Ubuntu, it’s seen her through both her GCSE’s and A-Levels, and is still going surprisingly well for its age. However, it’s really well past the time for it to be retired, and my daughter deserves to have something a little significantly more stylish and capable. She didn’t want an Apple, and wanted to keep Ubuntu as her primary OS. She also felt that keeping Windows available (as it would certainly be preloaded on anything we bought) made sense in case she needed it for anything specific.

So after a fair bit of investigation I bought her an HP Envy 13 model D008NA. This is a beautiful metal-bodied Ultrabook with the latest Intel Skylake Core i5 processor, 8GB of RAM and a 256GB SSD, preloaded with Windows 10 Home 64bit. A trial of the latest Ubuntu linux (15.10) from a “live USB” works well, with only the built-in fingerprint reader seeming to be unsupported, so getting it running Linux and Windows 10 in a dual-boot configuration certainly looks possible, though there are a few roadblocks to overcome:

• Microsoft no longer supply a Windows Certificate of Authenticity with OEM (preloaded) computers, so there is no visible indication of the Product Key for the preloaded Windows 10
• HP don’t supply install media (only the ability to recover to the “factory state”)
• The HP recovery process uses hidden Windows partitions on the laptop SSD
• This is designed and shipped as a UEFI-only system

But we like a challenge! There are two approaches to this problem; either shrink down the existing pre-installed Windows 10, and install Linux next to it, or start from scratch, wipe the SSD, and install new copies of both operating systems. It turns out that HP (in common with most suppliers of consumer IT) ship their preloaded Windows 10 with quite a lot of bundled “trial” software that we don’t want. So my ideal endpoint is a fresh install of bare Windows 10 Home 64 bit, with a fresh install of Ubuntu Linux 15.10 64 bit, in such a way that both coexist happily, and are easy to keep up to date (especially as Ubuntu 16.04LTS isn’t far away now). So, that means finding Windows 10 install media and the product key. It also means finding a way to recover the laptop back to factory state (in case everything goes badly wrong) that doesn’t depend on the internal SSD, as I’ll be overwriting that. And then there are the usual problems of getting Windows to coexist with another operating system, complicated by the need to do everything within a UEFI context. For me that means having Grub be the system Boot Manager, which will then start either Linux or Windows (actually, it will chain to the Windows Boot Manager, which will do nothing but seamlessly start the single instance of Windows).

Getting hold of the Windows install media turns out to be trivial. Microsoft now make them freely available for download. Thankfully I can also get the full version, rather than the European-legislation compliant version that needs post-install updates to provide full multimedia functionality. Turning that ISO into a bootable USB key was harder than expected, but eventually I found this tool called Rufus. Since this is a UEFI-based system, it’s essential to get the options right, and because of a “glitch” in the Rufus tool’s GUI, you also need to get them right in the right order! The trick for me was to specify the USB device, then select the ISO, then specify the partition scheme (which needs to be GPT only), then the filesystem (NTFS). That (and only that!) combination produces a USB memory key that can be booted by the HP.

The product key was a concern, but after a lot of reading, it seems that the way this now works is that the manufacturers burn the Product Key for the preloaded Windows into the NVRAM of the motherboard at manufacture time (for interest the standard defined by Microsoft is available here). The good news is that NeoSmart Technologies provide a free tool to read that information out. So now I have the Product Key to activate Windows 10 Home 64bit, although if I understand the process correctly, I shouldn’t need it, as Windows should be able to detect and use the license key that is embedded in the hardware without any intervention on my part. See posts 10 and 11 of this thread for some really useful background to how Windows licensing and activation really works.

Next problem was how to get factory recovery working without access to the SSD. As it happens, we have warranty cover that would get us out of that hole if the worst came to the very worst. But I’d rather not have to call on HP (and the delays that would entail) if I need to just reimage the laptop. Fortunately, a little Googling revealed this HP Support Page that explains the options available. It turns out that it is possible to create a set of external recovery media, using a preloaded application, that is buried somewhere in the Windows 10 menu system (or possibly behind one of those strange, rotating blocks that Windows 8/8.1/10 seem so keen on). Anyway, 20 minutes with a 32GB USB memory stick, and we have a bootable recovery solution that ought to be able to reimage the whole laptop back to “factory fresh”. Result.

So now it’s time to take a firm grip of the keyboard, and start changing things. In particular, I need to check that I can restore the laptop back to its factory state. If that doesn’t work, then now is the time to invoke the HP warranty process! Fortunately, booting from the recovery USB key works perfectly, and restores the laptop back to it’s Factory fresh state in about 40 minutes.

With that reassurance, I booted into the Live Ubuntu 15.10 environment, and using gparted I wiped the SSD. I then repartitioned it (using the GPT scheme) as:

1. 250MB, FAT32, “EFIBoot”, flags=esp/boot
2. 80GB, unallocated (eventually for Windows 10)
3. 4GB, Linux-swap, “Swap”
4. 18GB, ext4, “Root”
5. 136GB, ext4, “Home”

When an OS is installed in a UEFI system it adds an entry to the EFI Boot Manager’s list of installed OS’s, telling the EFI Boot Manager where it’s EFI file is, and getting a unique reference number. I wanted to remove the entry for the pre-installed Windows 10 from the UEFI system (its stored in NVRAM, not on the SSD) to minimise the opportunity for later confusion. To do that, I installed efibootmgr by running the command sudo apt-get install efibootmgr, and then ran it with sudo efibootmgr. I then deleted the entry for “Windows Boot Manager”. On my system that was entry 0000, so I did that by running the command sudo efibootmgr -b 0000 -B. I was EXTREMELY careful not to remove any other entries, as I could easily prevent the system from booting by deleting the wrong entries.

And then I installed Ubuntu 15.10 onto the SSD, using the Swap, Root and Home partitions. Confusingly, the installer asks where the bootloader should be installed, but of course, as this is UEFI, the EFI boot code MUST be installed into the EFI partition (which is marked by the ESP/Boot flags). In practice, the Ubuntu installer knows this, and ignores whatever you tell it when installing in UEFI mode, but the dialogue is a little confusing.

Having tested that the installed Ubuntu system works, the next step is to install Windows 10. My first attempt to install Windows 10 failed, as the SecureBoot setting in the BIOS prevented the bootable Windows 10 installer from starting up. So I temporarily switched that off, booted the Windows 10 USB installer, and pointed it at the unallocated space that I left on the SSD. Windows then partitions that space into two partitions; a small one reserved for its own private use called the MSR, and the rest for the main Windows environment, ie the “C” drive. Unfortunately Windows insists on rebooting several times during the install process, and at this stage in the process it’s highly likely that those reboots will cause Ubuntu to start up, not continue the install of Windows. My approach was to “catch” each reboot by pressing ESC then F9, and then manually guide the reboot back to Windows again by navigating the UEFI firmware back to the Windows EFI bootmanager, which is at /efi/microsoft/boot/bootmgfw.efi in the EFI partition. As expected, Windows 10 never asked for the product key, and self-activated as soon as it connected to the Internet – which was remarkably easy.

Once Windows was actually installed, I followed advice I found on the Internet, and turned off the Windows “Fast Startup” feature while I did the final configuration of Grub. This is a Microsoft feature that caches system-state across restarts (similar to hibernating) so I’m not sure how this could interfere with reconfiguring Grub, but I figured better to be safe than sorry. I did this by:

1. Open Control Panel (Win+X->Control Panel from the desktop in Windows 8+)
2. Navigate to Power Options
3. Click “Choose what the power button does”
4. Click “Change settings that are currently unavailable”
5. Uncheck the box that says “Turn on fast startup (Recommended)” at the bottom.

You should be able to re-enable Fast Startup after reconfiguring GRUB, but I’ve not bothered, as I’ve not noticed any significant change in boot performance with it turned off on this machine (boot times are incredibly fast anyway). At this point I shutdown Windows, and rebooted into Ubuntu. There I reconfigured Grub, changing the file /etc/default/grub to make Grub remember the last OS I booted, and it make it the default for the next boot, with a 15 second timeout while there is a visible OS Selection menu on the screen:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
# GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=15
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""


I then ran the command sudo update-grub to make those changes live, and to allow Grub to locate the Microsoft Boot Manager, and add it to it’s menu entries. This means that now when the system boots, Grub will get default control when the SSD is selected as the boot device. It then gives you the option to choose between Ubuntu or Windows 10, and will default to booting whichever was chosen last time. The advantage of this is that when Windows 10 runs its automatic updates sequences it expects to be able to reboot itself multiple times, and this Grub configuration will accommodate that requirement without someone needing to sit in front of the machine and babysit Windows through its updates.

Finally, I booted back into Windows, and downloaded the HP Support Assistant, which is supposed to manage updates for all the drivers on the laptop automatically. My experience was that it only downloaded and installed about 4 or 5 of the 15 or so required drivers, so in the end I manually downloaded and installed all the HP drivers for this machine. I’m hoping (but not hopeful) that now the right drivers are all in place, the HP Support Assistant may manage them all properly from now on.

Now I just have to transfer my daughters data over to the Linux partition, and install any required applications; an easy job.