@Tom-Elliott
Not sure if you got the keyboard issue figured out or what drivers / patches you added, but I have successfully used this in the past for SP4
https://github.com/cransom/surface-pro-3-nixos/blob/master/multitouch.patch

I wanted to share my experience with trying to get something signed for Secure Boot with my imaging program. It basically comes down to that it’s very difficult for open source projects to get something signed.

First of all you need to get your bootloader signed by Microsoft, no way around it. Second it requires an EV code signing certificate. These are expensive and you can only get them if you are a legitimate business. You must use a shim, otherwise every change to a kernel or bootloader would require resigning them from Microsoft which is not feasible. Also, shim does not currently support Proxy DHCP servers. The basic workflow is this:

Compile the shim with a self signed CA baked in, then you can sign your kernels and bootloaders against the CA without the needing resign the shim with MS for every change.

Submit the shim and your EV certificate to Microsoft

They will reach out to the shim maintainers who will ask you a bunch of questions about how you will use the shim. If you tell them you are going to use it with iPXE they probably won’t approve it. You need to tell them you are using Grub. If they catch you signing anything other than what you say, they will blacklist your shim.

If everything checks out then they’ll send you the precious signed shim.

I personally scrapped the idea of trying to get a signed shim because of the business requirement. Too much extra cost, not to mention the hassle of doing taxes with a business that doesn’t actually make any money.

The future looks dim because of secure boot

I believe this is a dynamic memory issue. Disable dynamic memory in hyper-v and the newer kernels work. The 64 bit kernels also seem to work even with dynamic memory on.

I just wanted to take a minute to share what I know about this subject.

XFS
Does not have the ability to shrink period. It can only grow. The only possible solution is to do a file backup using something like xfsdump, then recreate the filesystem. Or make the smallest partition possible when you first install, then grow after imaging.

OSX
There is nothing special about fusion drives, the issue is that fusion drives are coupled with OSX’s core storage feature. Core storage is basically lvm for mac. When using a fusion drive a volume group is created and spread across the two drives, giving you added speed on the ssd portion. I assure you the drive is not hidden and you still control over your drives. It just appears as one drive. You will most likely never be able to image core storage from a linux environment except as raw. It’s like when you want to capture lvm on linux you need to active the lvm first or it will be captured as raw, the only problem is there is no way to activate core storage on linux.

Hope that helps.

I’m fairly certain this a kernel issue. What are you running hyper v on? Latest windows 10 build, server 2016? I ran into this with the latest hyper v, not with fog, but same principals apply. Using the 4.13 series 64bit resolved the issue for me. What kernel are you using?

Hi all, I’m the dev of CrucibleWDS proxy, let me know if you need any assistance with this. The latest version adds support for booting pc and apple devices together, it also supports Apple’s native NBI netboot process as well as iPXE. It is actually named CloneDeploy Proxy DHCP now. Here is the latest source.
https://github.com/cdadmin/clonedeploy/tree/master/clonedeploy_proxy_dhcp

and latest binary
http://sourceforge.net/projects/cruciblewds/files/testing/cd_proxy_1.0.0.zip/download

I have been using this reliably on CentOS and BSD for some time now. I can attach my init script if necessary.

I wanted to share my experience with trying to get something signed for Secure Boot with my imaging program. It basically comes down to that it’s very difficult for open source projects to get something signed.

First of all you need to get your bootloader signed by Microsoft, no way around it. Second it requires an EV code signing certificate. These are expensive and you can only get them if you are a legitimate business. You must use a shim, otherwise every change to a kernel or bootloader would require resigning them from Microsoft which is not feasible. Also, shim does not currently support Proxy DHCP servers. The basic workflow is this:

Compile the shim with a self signed CA baked in, then you can sign your kernels and bootloaders against the CA without the needing resign the shim with MS for every change.

Submit the shim and your EV certificate to Microsoft

They will reach out to the shim maintainers who will ask you a bunch of questions about how you will use the shim. If you tell them you are going to use it with iPXE they probably won’t approve it. You need to tell them you are using Grub. If they catch you signing anything other than what you say, they will blacklist your shim.

If everything checks out then they’ll send you the precious signed shim.

I personally scrapped the idea of trying to get a signed shim because of the business requirement. Too much extra cost, not to mention the hassle of doing taxes with a business that doesn’t actually make any money.

The future looks dim because of secure boot

I’m fairly certain this a kernel issue. What are you running hyper v on? Latest windows 10 build, server 2016? I ran into this with the latest hyper v, not with fog, but same principals apply. Using the 4.13 series 64bit resolved the issue for me. What kernel are you using?

Thanks everyone for the suggestions. I’ll continue testing and report back if I find a solution.

@Quazz Fairly certain. Domain join is being done by the sysprep answer file, not the fog client. Drivers are not installed in time for the sysprep answer file to join the domain, but on the next reboot they do get installed.

@Quazz Same location for both. Windows 7 just copy drivers to c:\windows\inf works fine. Doing the same for Windows 10 does not.

Yes they are inf, if not it wouldn’t work for Windows 7 either, as far as I know.

@Quazz Unfortunately I have tried that too. Still the same result. Drivers not installed in time for domain join, but upon next reboot they are installed. This all worked fine in Windows 7, I’m thinking there just might not be any workaround for Windows 10.

What I have discovered is setting the devicepath in the registry does work with Windows 10, but not during the First Boot phase, but after the answer file is applied for the specialize phase and reboots again, then the devicepath is read. The problem with that is that the network driver is not yet installed when joining the domain from the answer file.

In your case, perhaps a generic nic driver is found that works during the domain join(or maybe you aren’t joining the domain with sysprep). Difficult to say.

That was the first thing I tried, unfortunately it doesn’t work. If you look at the diagram I posted, the offlineservicing pass does not get applied without mdt or sccm. It requires WinPE. In terms of using Fog, the only stages that get applied are First Boot and Windows Welcome.

I know this isn’t directly an issue with Fog, but I wanted to see if anyone else has experienced this problem. In short, manually injecting drivers does not appear to work correctly with Windows 10. Windows 7 worked properly when modifying the devicepath in the registry but not anymore, the drivers do not get installed during Sysprep, resulting in the computer not joining the domain during the Sysprep phase. After the computer reboots to Windows then the drivers are found. I know some have recommend setting the driver path in the offline servicing section of the sysprep answer file, but that answer is not valid. That phase is never processed unless the image is applied using WinPE. You can see the workflow in the attached pic as well as more explanation here.

https://technet.microsoft.com/fi-fi/library/cc749307(v=ws.10).aspx

I know it’s a long shot, but I was hoping someone had a workaround.
Thanks