EFI boot order always resets after a reboot - windows

I've recently set up a dual boot between Windows 10 and Arch. Unfortunately the Windows Boot Manager always boot first. I've already tried to change the sequence via efibootmgr -o but after I reboot it always resets it to to Windows boot manager booting first. Does anyone know a fix to this?

This is a quirk of your UEFI implementation. The easiest way out of it is to replace ESP:/EFI/BOOT/BOOTX64.EFI file to be your transient bootloader (i.e. GRUB2), as right now it's probably a Windows bootloader that UEFI sets as default one no matter what.

Related

How to create a secure boot enabled USB flash

I want to create a Ubuntu bootable USB flash and install my apps in that, then pass USB to any other person. they should run Ubuntu from USB flash and run my applications from it, so that nobody could change Ubuntu's kernel modules and also my application's modules and I want to prevent booting Ubunto if one of that modules was changed.
I think I have two options to achieve my purpose, first, UEFI bootloader programming and checks hash of USB contents through my customized bootloader, second, Use secure boot feature of UEFI.
I prefer second option because I think secure boot does everything I want and it is much easier than the first option, but I couldn't find any tutorial for creating secure boot enabled USB flash(with only my keys).
I will appreciate you if you could provide a step-by-step tutorial for clear default keys, enroll my keys, enabling secure boot for flash disk, and everything else I will need.

native boot of a windows subsystem linux distro, as a standard distro at bootup of windows 10

Is it possible to boot the Wlinux (a windows linux subsystem distro) filesystem natively instead from the windows bootmanager (or refind grub etc)?
Like a dual boot system, but be able to either boot in at start, or access the linux system via wsl.
For reference I have a surface pro 5, and I know that its neccesary to disable secure boot ...etc. More curious of whether this can be done or not, and if so is there a particular way to do it succesfully ?
Thanks
No. WSL is not a full desktop replacement or even a VM. It aims to reduce the need to use VMs. If you want to dual-boot, you'll need to grab a Linux iso. See https://learn.microsoft.com/en-us/windows/wsl/faq.

Can a Kernel Mode Driver Prevent a Windows System from Booting?

I have recently been attempting to create a GPIO Driver for SBC's using an Intel chipset that run Windows 8.1 and have begun testing it on an actual system. After loading the Driver and updating the Intel chipset I am using, the system appears to hang after loading the BIOS. Unfortunately, this disables my mouse, keyboard, and video, preventing me from entering BIOS or the boot manager.
While it is possible that the chipset update caused the system to become unbootable, it is highly unlikely considering we use that update for our other SBC's running the same chipset.
So my question: Is it possible for a Windows Kernel Mode driver to prevent a system from booting up past BIOS/POST?
I appreciate the help, since, clearly, I am no expert on this topic.
Yes, if your driver is being loaded at boot time it can prevent the booting of the OS and it will end up in BSOD(Blue screen of death) error with related bug check.
According to bugcheck displayed by the OS you can resolve the issues with your driver.
Or sometimes if its not giving any error and just hangs you can use WinDbg to check the bugcheck.
It depends on the error control of the driver service. Boot time drivers can also fail at any point. There is nothing special about the failure happening during boot. Instead, what is relevant under this scenario depends more on the ErrorControl value of the driver service which specifies how to proceed if it fails to load or initialize properly. A value of 3 (critical) would reboot the system to LKGC. Same rules apply to a win32 servic as well..

Writing Windows 7 UEFI entry to NVRAM

I am currently working on a script to image multiple lab machines I am in charge of with Windows 7, unfortunately they are UEFI Dell machines which work in a silly way. On the machine I created the image with in the Dell setup utility there was a UEFI entry in the boot menu for Windows which loaded the /boot/Microsoft/bootx64.efi file or some such equivalent, when I image the machines everything goes fine except when I boot them I get the good old 'No Bootable device found error' and when I go into the Dell setup utility there are no Windows entries. I can manually add a entry that points to this UEFI partition and the boot file, which will then boot fine and weirdly on boot add another entry to the NVRAM that points to the same file under the typical name 'Windows Boot Manager' or something. I have been trying to find some way to add this NVRAM entry without having to go into the Dell setup manually since I am imaging a large number of machines and this would just complicate the process. I originally tried just chainloading a grub bootloader after the imaging had finished to detect the windows installation and boot it which would theoretically add the entry to NVRAM itself and stop me from having two entries or having to interact with the machine myself. I also haven't been able to find any information on directly adding an entry to the NVRAM on the linux side that would do the same thing I accomplish through the Dell setup utility. Anyone have any experience with this?
Thanks
The operation of the Boot Manager is defined in the UEFI Specification, Chapter 3.
If you can write a UEFI application and boot to a UEFI shell and run your application you can use the Runtime Service for setting a variable to create a BootOption and add that BootOption's number to the BootOrder. This is what the MS bootloader is doing when it detects that there is not a BootOption defined for Windows, and this is way there is a new entry in the list after you boot to Windows.
Not sure what your default boot order is for your platform, but it may be possible to boot to a USB key with an UEFI shell by default, as this is a common configuration of defaults due to manufacturing requirements.
Check out the projects on tianocore on sourceforge to get a better idea of what would be involved in doing what you wanted to do.

How can I trigger the boot process of a bootable CD after normal boot?

I have been fooling around with different versions of Multiple boot softwares, trying to create a USB pin with my favorite PC tools and a folder with ISO's for which to boot after a normal boot into DOS (or something).
But a lot of ISO's don't work correctly, or at all (ie. Windows boot CD's etc.), so I got a new idea:
Would it be possible to create a bootable MS-DOS USB pin, and then after having booted, trigger the normal booting sequences of a CD-rom from the DOS prompt?
Like this:
Turn on PC.
Hit key to get boot sequence menu (in my case F12).
Select "Boot from USB".
Let the USB boot into DOS (... or whatever else could be used for this purpose?).
From DOS prompt start "some program/script" to trigger a bootable CD in the normal optical drive, as if it had been triggered directly from the BIOS boot sequence menu.
(if this was possible, I would then proceed to add a menu with the option to start virtual CD-drive software and mount ISO files to my USB pin)
Thanks for any advice and/or ideas and thoughts!
Theoretically, you can use Int13h/AH=4Ch to start a CD-ROM boot from code running under the BIOS. However, I seem to remember reading that most BIOS implementations don't actually implement this part of the El Torito standard. (That was a long time ago, so perhaps you won't have this problem on a modern BIOS, although I wouldn't count on it.)
It is important to note that (in my experience) this is unlikely to work once you've booted an operating system. DOS doesn't change the CPU mode (provided you don't install any extended memory drivers) but it does change the system context in other ways - for example, IIRC, it hooks several of the BIOS interrupts. As a result once DOS is running you can't overwrite it (in order to boot another OS from a CD) without things falling over.
So, in order to make this work (a) you have to run your code in the bare BIOS, with no operating system present; and (b) you need a BIOS that implements the boot function properly. The first part is just a matter of getting the hang of bare assembly and the BIOS functions, but the second part is pretty much out of your control.

Resources