I'm trying to boot a Linux Live USB for installation on my old Microsoft Surface 2, a tablet equipped with a Nvidia Tegra 4 SoC. Obviously, it needs the SoC drivers to run the GPU. I have a couple of Live USB distros I could try at booting. The first I’m attempting is the Debian 10 ARM HF. Right now, I’m concerned about the bootloader & it seems it would need the package:


Of course, this is a chicken & egg problem, as I need to have the distro installed first, before it can utilize this package. So, how do I modify the Live USB’s bootloader to utilize these binaries inside said package:



If at all possible, by simply swapping files in the Live USB’s root directory?

Come on, everybody’s just itching to give me a distraction. Here’s your chance.

  • Or, else, I swear I’m gonna buy another tablet.
    – Dehbop
    Commented Sep 13, 2021 at 11:09

1 Answer 1


I understand Surface 2 is a 32-bit UEFI system with an ARM architecture, so when commanded to boot from a removable media, the firmware will just look for \EFI\boot\bootarm.efi on any filesystem type it understands (at least FAT32, but a Microsoft firmware just might be able to read NTFS too, I guess?). If it finds that file on your live media, then it should consider that media bootable, load the file and execute it.

rEFInd would be a nice UEFI bootloader, but apparently it supports 32-bit hardware only on the x86 platform, so there is not a 32-bit ARM version of it in existence. But GRUB and systemd-boot apparently have 32-bit ARM versions available.

For UEFI, it can indeed be as simple as creating the appropriate directories in the Live USB's root directory and placing a copy of the bootloader in the specified directory using a specified filename (for 32-bit ARM, \EFI\boot\bootarm.efi). The rest depends on what that bootloader is actually going to be: if you use an ARM version of GRUB, you will need to write at least a minimal GRUB configuration file that will tell GRUB where the kernel and initramfs files can be found on the live media. I'm not too familiar with systemd-boot, but generally you would have to place the things it expects to find to their expected locations on the live media.

U-boot, on the other hand, would be relevant if you were developing an embedded system from bare metal, to use U-Boot as part of your own custom firmware. But it sounds like you are not doing that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .