Using GRUB is a little harder than using syslinux, but it is required if you want UEFI support. Here’s how to use GRUB2 for UEFI and LUKS encrypted volumes for the .Arch Linux side and still dual boot into Windows 10
[UPDATE: I should have mentioned that this article is built upon previous work I did using LVM on LUKS on an MBR system. There are scripts with comments that can be used to be a recipe for that at https://github.com/JDCNS/ArchVMInstall.]
This article is partly the result of Microsoft’s constant giving of five confusing names for the same thing and just plain backwards way of doing things. It is also partly because overall GRUB is such a flexible and customizable tool that finding all of the information in one spot is unlikely. Continue reading “How-To GRUB2 for UEFI and LUKS Encrypted Volumes for Arch Linux and Windows 10”→
These are my notes from working on Windows 10 UEFI SCCM boot images. They are the result of experimentation, so take everything with a grain of salt and realize everything is subject to change.
[Last Updated: 1 Jan 2017]
Reference Computer & Capture
Ensure that the SCCM capture media boots via UEFI in case it needs to reboot. Turn off Enable Legacy Option ROMs in the BIOS just to make sure.
Apparently, there is an issue with the size of the EFI partition if the default is used. Create partitions either from another image or from Linux and apply them and then install Windows 10. This will ensure that both Recovery and operating system directories are correctly captured and applied.
You should have “Capturing volume 1 of 2” and “Capturing volume 2 of 2” for task sequence “Capture the reference machine”, else you may have not booted UEFI before the capture. If instead you get “Capturing volume 1 of 1”, check boot settings and uncheck any Windows Manager entries.
Update:
I should state that when it did capture multiple partitions, it did so inconsistently. It was more or less every other time it would capture 1 — 2 and 2 — 2 vs 1 — 1. However, the server guys ran a patch a few months ago, and it now only does 1 — 1 period. I suspect that you might be running the same patch level.
Having said that, UEFI and Windows 10 still works. Since that was more or less what the article was about, I suppose you can quit reading after this paragraph because all you have to do is in your task sequence for deployment, you still create the partitions for EFI, etc, in Format and Partition Disk and simply deploy your image to the last partition (or OSDisk). You honestly don’t seem to lose anything unless you try to use Windows 10 Reset your PC option, as testing it out had it working the first time on a given computer only.
Some details of what I’ve learned since writing the original article:
1. Somewhere along the way, SCCM stopped capturing multiple partitions. There are ways to force it, but using the simplest create capture media no longer does it at all that I can tell. Even when it did work, it was inconsistent at best. It appeared to, more or less, capture 2 partitions every other time (but not always).
2. SCCM does not natively like multiple partitions. Sure, it can create them, but there are workarounds all over the web to do anything meaningful with them beyond that. Most of the time, the advice is to simply use something else if you really, really want to create and deploy multiple partitions.
3. If you simply want a UEFI boot, simply create the appropriate partitions in the Format and Partition Disk step and then deploy your OS image to OSDisk. Apparently, it is Windows 10 and the BIOS that will handle the UEFI without further ado. In the worst case, the Dell BIOS allows you to force UEFI, and some machines work better with legacy disabled. Forcing the Dell BIOS into UEFI mode and disabling legacy mode on some models, booting UEFI on the USB task media stick, creating the proper partitions and deploying Windows 10 to the last partition all seems to make it work fine.
4. SCCM especially does not like multiple OS partitions, and so we are testing it out by using two already existing images and deploying them using two different task sequences (and then manually running bcdboot if we want the boot menu). Doing otherwise either has the second OS overwriting the first or the entire sequence stopping after the first is configured. Obviously, we put the Format and Partition Disk step in the first task sequence but not in the second.
Under Apply Network Settings, add an entry for Network Settings and be sure to put in the suffix “domain1.ci.longmont.co.us” on the DNS tab.
Under the Setup Operating System, add “Run Command Line” step “Disable DEP”. In the Command line section, put “bcdedit /set nx alwaysoff”. On the Options tab, place a checkmark by Continue on error.
For deploying the image, in the Apply Operating System task sequence step, though, you only need the 2 – 2 image of the captured image package (.WIM) file. Do a Apply Data Image task for the recovery partition (1 – 1).
Partition layout should look something like:
SCCM task sequence create partitions for UEFI Windows 10 deployment
Task sequence will not install on an unpartitioned drive. Create a 450MB Recovery partition (NTFS) and a 100MB EFI partition (FAT32) at the beginning of the disk. The rest can be named anything and formatted NTFS.
Note that the recovery partition is not required. Some things might act wonky without it, but if you can dump it, I suggest you do so. SCCM is a royal pain when it comes to capturing both partitions.
Note the sizes. I believe some of the pain I encountered was due to an illegal partition size created by Windows OOB. Somehow create the Recovery and EFI partitions and then install Windows.
Boot Image Issues
If you create a task sequence with an x86 boot image but the stick is booting x64, then the UEFI SCCM task sequence will attempt to copy down the boot image called for. Unfortunately, it does this on its own and before the task sequence begins. Of course, the task sequence partitions and formats the hard drive, so the boot image is immediately lost. You can tell it will copy down the boot image because SCCM will ask you to reboot before running the actual task sequence.
If you change an x86 task sequence so it has a UEFI SCCM x64 boot image on a stick created with an UEFI x64 boot image, it will not copy down the boot image, which gets around that particular problem. However, the end result will be a non-bootable system, it would appear.
All of the documentation I have found state that you need to use an x64 boot image to deploy 64 bit systems and an x86 boot image to deploy 32 bit systems. Since we have been deploying 64 bit systems with an x86 boot image in the past (MBR only, naturally), it would appear we were simply lucky.
In general, it seems that the initial capture of an x64 UEFI image will only capture the main partition. However, if you use that image to gen the main partition of a working UEFI system, you can then sometimes get the capture task sequence to capture both restore and main partitions. [See update previous.]
I still believe it is related to the missing TSMBAutorun.exe on the capture stick. There is supposed to be one under each of the i386 and x64 subdirectories of SMS, but only the i386 subdirectory has it.
