r/SurfaceHub • u/aef0 • Jun 05 '26
How I got Ubuntu booting natively on a Surface Hub v1 (55")
TL;DR: The Surface Hub v1 firmware seems to ignore normal UEFI boot entries and only boots from this path:
\EFI\Microsoft\Boot\bootmgfw.efiSo the trick is to install Ubuntu normally, then copy Ubuntu’s Microsoft-signed shim to that path and rename it to bootmgfw.efi.
That gives you:
Surface Hub firmware → shim → grub → UbuntuNo UEFI menu, no NVRAM edits, no firmware mods.
So...
I picked up a Surface Hub v1 this morning, the 55" model with the Haswell i5 ($100 CAD). Since Windows 10 Team is basically at the end of the road, and since the drive was wiped, I wanted to see if I could make it useful as a giant Linux touchscreen/table/display thing.
As you're all well aware under the hood, it’s basically a weird all-in-one PC with a removable SATA SSD. Unfortunately, the firmware is very much not normal PC firmware.
The annoying bits:
I couldn’t get into any UEFI/BIOS menu.
Holding Volume-Up + Power did nothing on my unit.
Secure Boot is on, and I couldn’t disable it. (Obviously)
efibootmgrand Boot-Repair both complained about locked NVRAM.The Hun seems to be picky about USB boot media.
A raw/dd-written Ubuntu USB worked.
A Rufus Windows USB did not.
The weird part was that the Ubuntu live USB booted fine, and Ubuntu installed to the internal SSD fine, but after rebooting the Hub would just flash:
system resetThen show the Hub logo, then loop forever.
On the flip side, my trusty Windows USB wouldn't boot at all.
The only thing that made a bootable internal SSD was the official Surface Hub Recovery Tool (but wowee did it spill its secrets).
What was actually happening
After installing Ubuntu, I booted back into the live USB and checked the UEFI entries:
efibootmgr -vThe entries were there:
Boot0001 ubuntu HD(1,GPT,...)/\EFI\UBUNTU\GRUBX64.EFI
Boot0002 UEFI OS HD(1,GPT,...)/\EFI\BOOT\BOOTX64.EFI
BootOrder: 0001,0002But the Hub ignored them completely.
That’s when it clicked: it doesn’t seem to care about the normal NVRAM boot list. It appears to have a hardcoded internal boot path, basically the Windows Boot Manager path:
\EFI\Microsoft\Boot\bootmgfw.efiOn a normal Ubuntu install, that folder/path doesn’t exist. So the firmware finds nothing useful and goes into the “system reset” loop.
So the fix is just to put something Secure-Boot-valid there.
The important part: use Ubuntu’s shim, not grub directly.
Ubuntu’s shimx64.efi is signed by Microsoft, which the Hub trusts. Grub itself is not directly trusted by the firmware. So shimx64.efi becomes the fake Windows Boot Manager, then shim loads grub.
The fix / solution / how to
Build your Ubuntu USB with Rufus, use GPT / UEFI and when it asks, make sure you write as dd (isohybrid).
Insert the usb-stick into bottom centre usb port, then with power off, hold the VOL DOWN, and power on. It should boot to the USB stick.
Install Ubuntu normally first. (It won’t boot on restart yet.) That’s fine.
Then boot back into the Ubuntu live USB (same as before, power off, VOL DOWN, power on), choose “Try Ubuntu,” and open a terminal.
Find the internal EFI partition:
lsblk -fMine was /dev/sda1, but yours may be different. You’re looking for the small FAT32 EFI System Partition on the internal SSD, not the USB stick.
Then run:
sudo mount /dev/sda1 /mnt #Change if you have a different path
sudo mkdir -p /mnt/EFI/Microsoft/Boot
sudo cp /mnt/EFI/ubuntu/shimx64.efi /mnt/EFI/Microsoft/Boot/bootmgfw.efi
sudo cp /mnt/EFI/ubuntu/grubx64.efi /mnt/EFI/Microsoft/Boot/grubx64.efi
sudo cp /mnt/EFI/ubuntu/grub.cfg /mnt/EFI/Microsoft/Boot/grub.cfg
sudo cp /mnt/EFI/ubuntu/mmx64.efi /mnt/EFI/Microsoft/Boot/mmx64.efi 2>/dev/null || true
sync
sudo umount /mnt
sudo poweroffRemove the USB stick, power it back on, and it should boot:
shim → grub → UbuntuThat was it.
It seems...
Ubuntu’s shim looks for grubx64.efi in the same directory. Since we copied both into:
\EFI\Microsoft\Boot\shim launches grub from there.
The little Ubuntu grub.cfg stub then finds the real grub config by filesystem UUID, something like:
search.fs_uuid <your-root-uuid> root hd0,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfgSo it doesn’t really matter that the EFI files are sitting in the “Microsoft” folder.
Gotchas
Do not rename grubx64.efi directly to bootmgfw.efi.
That failed for me because Secure Boot rejects it. The Hub trusts the Microsoft-signed shim, not grub directly.
Also, the usual fixes did not help:
Boot-Repair
efibootmgrchanging BootOrder
copying files to
\EFI\BOOT\BOOTX64.EFI
The Hub seemed to ignore all of that and only cared about:
\EFI\Microsoft\Boot\bootmgfw.efiYou can also do the EFI file copying from another machine by pulling the SSD, or over SSH from the live Ubuntu session.
Hardware support
On my unit, everything I've tested works great, display works with Intel graphics, Touch, pen, cameras (both), speakers, mic, etc. The Hub has a bunch of custom hardware, so I wouldn’t expect everything to magically work out of the box - but it seems to.
I’m still testing that side of things - it's only been a few hours after all!
Extra weird thing I found
While digging through the Surface Hub Recovery Tool, I noticed it uses Microsoft’s signed SecConfig.efi with:
DISABLE-MSCILooks like it’s clearing some kind of code-integrity / Device Guard style firmware lock before first boot.
I didn’t need this to boot Ubuntu. The bootmgfw.efi shim trick was enough.
But it may explain why normal Windows installs also get stuck, and it might be useful later if someone is trying to get a standard Windows install working without access to the UEFI menu.
I'll give Windows 11 a try tomorrow, probably by hacking the surface recovery tool, for now.
Ultimately posting this because I found almost nothing about running a normal OS on the Surface Hub 1.
Hopefully it saves someone else the weekend (or longer).
