PostdownloadFile Copy: Folders but no files?



  • Hello all,

    I am attempting to get automated driver injection working, and have based my setup off this guide. I’ve got it partially working, however, I am having an issue with my Windows 7 images where the files are copied to the partition by FOS, but Windows is only able to see the folder, and none of the files are visible within. I am not able to see them by modifying permissions or anything, they are just not visible - I am confidant the files copy, as my Windows 10 image does not have this problem (now I just need to build an answer file…), and I modified the script to have more verbose output and was able to verify. Any help would be greatly appreciated! Thanks in advanced.


  • Moderator

    @ssh-jon said in PostdownloadFile Copy: Folders but no files?:

    I did just think of a minor difference between the Windows 7 and Windows 10 images: for deploying Windows 7 to capture I create the partition structure manually using the latest version of diskpart, rather having Windows Setup build it. (This is because I build the image in a Hyper-V VM, but want to deploy it via UEFI, so I capture it as a WIM and re-deploy it on a UEFI compatible machine for capture.) It’s still the same structure, I just do it via diskpart.

    This doesn’t appear to be standard activity or in line with the MS design guide. Most people don’t have this level of skills, so you may be one of the few who will run into this issue.

    I take it the Hyper-V Gen1 VMs only have bios/legacy mode?



  • @george1421 Unless I’m missing a setting: Gen 2 Hyper-V VMs do not have a CSM, and so cannot boot any OS prior to Windows 8. However, I can confirm that even when built and captured exclusively from a virtual machine I am seeing the exact same behavior (I gave up and assumed I would have to use BIOS for Win 7 machines)!

    How can I be the only person experiencing this? I’m going to upgrade my FOG instance and see if that makes a difference, but I can’t imagine it would - or why…


  • Moderator

    @ssh-jon I guess I don’t have a response to this. I see this as you are creating a disk configuration in a nonstandard way.

    I would say creating your golden image in a VM is best practices. (I’m speaking a bit out of ignorance of hyper-v) I wonder why you are not just using a gen-2 hyper-v to create your uefi image? I create my reference images using MDT and 2 virtual machines (one bios, and one uefi). MDT will build them exactly the same configuration except one is bios and one uefi. Then sysprep and capture with FOG. It works for both win7 and win10 with driver injection (win10 has been a bit of a pain since 1709).

    So what I’m thinking is that FOG is copying the files as you see, but what is happing on the disk level is that MBR directory table is being updated by the linux tools but that directory table is not referenced by the running windows 7 OS.



  • @george1421 I had thought it might be permissions as well, so set user and group ownership to the fog user, and permissions to 777, and I still got the same results. Edit: also worth pointing out is that the files are being copied (verified by an “ls /ntfs/Drivers -r” and a debug pause in the script), Windows 7 just cannot interact with or see them.

    I tried with both cp and rsync, and the results are identical. Google is not lending me much useful help, though a lot of people that dual-boot have seen the issue (the completely useless solution recommended for dual-booting is to use an FAT32 partition).

    I did just think of a minor difference between the Windows 7 and Windows 10 images: for deploying Windows 7 to capture I create the partition structure manually using the latest version of diskpart, rather having Windows Setup build it. (This is because I build the image in a Hyper-V VM, but want to deploy it via UEFI, so I capture it as a WIM and re-deploy it on a UEFI compatible machine for capture.) It’s still the same structure, I just do it via diskpart.

    I wish FOG could deploy a WIM… This would be so super easy, lol.

    Aaaactually random side-note question: can I have FOG perform an action that I defined (via iPXE menu entry) on a host without user interaction? If so, I’ll have a super useful guide for some people…


  • Moderator

    @ssh-jon Intersting, is there some strange file permission on the driver’s directory for win7 that are not on win10 directory? Its strange that the folder structure is being created on the fog server, but no files are being copied.

    what command are you using to copy the files? rsync, cp or something else? I doubt this is the issue because win10 bits are working. I’m still leaning towards a permission issue for the win7 drivers on the fog server.



  • I have already verified that the the appropriate partition is being mounted, and that the files do exist in FOS. For some reason only the folder structure is visible in Windows 7 - but none of the files themselves are present.

    Windows 10 does not have this problem, I just can’t get Windows 10 to use the drivers…

    So, to be clear, in Windows 7 what I see on the C:\ drive after deployment has finished is the folder “C:\Drivers” and in it is (for example) “C:\Drivers\ThinkCentre M710q”, and within that folder are all folders for the various devices. There are no files, only folders.


  • Moderator

    Here is an updated version of the document you referenced: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

    My bet is that your partition table doesn’t match the assumptions of the first script. The updated document contains a bit more intelligence script to properly locate the C: drive

    If you need to debug your post install script I would recommend this.

    1. Place liberal echo statements in your code.
    2. Use the debugpause command after your echo statements.
    3. Schedule a debug deployment.
    4. Stop the script from running with a ctrl-c keypress.
    5. This will let you inspect the contents of the target computer under /ntfs directory on fos.
    6. If you need to fix your post install script do that on the fog server.
    7. Back on the target computer key in fog at the command prompt to restart the deployment process.

 

440
Online

41.9k
Users

12.4k
Topics

116.8k
Posts