Is this a uefi for bios (legacy) system?
If uefi did secure boot get disabled?
Its not clear if the FOG iPXE menu is loading. The error might indicate that iPXE is loading, but it doesn’t have the driver for the usb nic adapter.
From your iPXE kernel command you posted, it appears you are trying to capture an image with the fog server. Were you able to register the client successfully from the iPXE menu?
@stephzylstra said in Use provided USB to make FOG image?:
@george1421 MDT does definitely have some post-install scripts to do. I believe the customer is scripting out the OOBE setup so it will go straight to the desktop.
If this usb image installs correctly and completely at your locaito (away from the MDT server) you should be OK. If you expect the MDT server to complete an install started via FOG, I feel you will be out of luck.
We use MDT to build our reference image, sysprep it and then shut down the reference system. Then we pxe boot it and finally we capture it with FOG.
can you provide a screen shot of the error so we can see the exact error message?
What ipxe boot file are you sending to this computer?
As a test, can you place a dumb switch between the target computer and the building network switch? On the surface this sounds like it could be a spanning tree issue, were your building switch is not using one of the fast spanning tree protocols. The dumb switch will mask this bad behavior.
@lebrun78 If I could offer a different solution for you instead of “adjusting” the FOG programming code.
It is true that 7-8 years have passed since FOG 0.3x generation. So many things have changed (for the better).
I might recommend that you setup a fog server in that class room. That way that room can have full control of imaging to that specific room. Change the dhcp settings to point to the local classroom’s FOG server. This room FOG server then could be configured as you need it without impacting the master FOG server. The last thing you need to do is get the images from the master FOG server to the slave FOG server. That can be done on the Master fog server by defining the slave (classroom) FOG server as a storage node. The master FOG server will then replicate any images that have the replication flag set to the slave FOG server. The last bit you have to do on the slave FOG server is to manually create the image definitions on the slave FOG server so the slave FOG server knows about the images that have been replicated to slave fog server. This is not an officially supported setup, but it does work well without having to adjust the FOG main programming.
Keeping the FOG code unmodified allows you to take advantages of updates to FOG without having to adjust each update for this classroom.
@Tom-Elliott I agree, the OP will need to catch the image install just as the Litetouch WinPe image places the image on the target computer and starts the reboot into OOBE. Power off the target computer just as it restarts before OOBE starts configuring the PC. Power off the computer then power it on into a PXE boot and capture with FOG.
The other thing/issue the OP may run into is if the image relies on MDT to finish the system configuration. i.e. litetouch is still running post OOBE setup. You would be able to test this part by installing the image on a test system on an isolated network. If it installs correctly then mdt is not needed.
@chief Ok if you put a dumb switch in between the target computer and building switch and it resolved the problem. Then its probably one of the advanced protocols causing the issue.
This is typically spanning tree being enabled and not using one of the fast stp protocols.
Or you have green ethernet (802.3az) enabled on the building switch. We’ve seen this to be an issue with some realtek nics.
What might be interesting to see is if the OP keyed in the following from a browser window
http://192.168.5.10/fog/service/ipxe/boot.php?mac=00:0c:29:e3:3d:3f
This will display the fog iPXE menu contents destined for the host defined by the mac address. I’m going to suspect that the menu contents are not complete. Please post the results here in a code box.
Also the OP should look at the end of the apache error log for any useful errors.
And finally, knowing what you expected the host to do (i.e. did you assign a task to the host). That will help the developers understand the contents of the iPXE menu.
@Wayne-Workman (note this is not a lets beat up on Wayne thread).
While I go about this a different way, I can surely see value for this feature in a SMB or enterprise environment. If you look at it from a work flow standpoint, if I have a key associated with an image then as the workstation goes through its life cycle I can be sure that when I change the image that is deployed to the host, it will always get the proper key for activation. In addition when you look at the host record, you will see the key used to activate the host. Yes it could be done with groups but its just one more step that the Deployment Tech has to do for every system. FOG should be focused on reducing the number of steps to produce a solid image and not by adding more (case in point the persistent groups plugin (hack) )
And also consider image deployment using only iPXE and the FOS engine. Lets say you deploy an image via quick image (ok so I forgot the new name of the function). From quick/instant image you can select any image for deployment. If the key is attached to the image then the proper key will be assigned to the target computer without requiring FOG Management console access/interaction.
I can foresee a few caveats here too. If you have a host defined OEM key assigned to a host and then you assign an image to that host that contains a VLK key reference, your OEM key will be replaced with the VLK key potentially loosing your OEM key for every. But in most enterprises you don’t deploy with OEM keys anyway. But the point is you MUST be aware of this condition if you enable/deploy images that have a key association.
I surely see this as a value-add feature.
@Wayne-Workman I can say that Spiceworks (the app not the online community) does this. But the last logged on user is just that. Its not a one to many relationship its literally the last user that was logged in when the device was scanned.
I plugin is the right answer on how to add this. Understand I say that not knowing the details on how to do this. But is also raises the a philosophical question of, is fog moving towards system management tool or a deployment tool with a few system management add-ins?
But back on point, this mythical plugin would need to add the field to the page and then query the login history for that device and return the record with the last date.
@Tom-Elliott Well since this “feature” would only apply to enterprise image deployments, I can see the value of adding it to fog via a plugin instead of updating the stable core code of FOG. That way if the FOG System Admin wanted to use this function, turning on the feature would be as simple as installing the plugin (akin to enabling the location plugin).
Just to document what I “think” could be done to support this request. We do have to realize this is a windows only feature and FOG is used for many operating systems. But since the majority of operating systems being deployed are MS Windows based there is some merit to this request.
Beyond that, no other “new” actions are needed. The fog client will pick up that value and do what it already does today. It seems pretty quick of a fix. The only downside is that it does require an updated database schema to support the new “Host Product Key” field in the image definition.
@falko I got pulled off because we have a sick VM host server.
Also considering if the unattend.xml fails to use DISM /online in the setupcomplete.cmd to inject the drives that got missed (assuming there was any). One other thing that we do is inject the dell cab winpe pack into the reference image before image capture. That dell cab driver pack contains network and storage drivers. So those are “built into” our reference image from the start.
Again I’m taking jdd49 experience that its not working and trying to come up with a plan before I touch the system.
@Tom-Elliott From what I seen (web searches) if you disable the raid functions in bios then it will present the disks as JOBD. But then raid is disabled. If the system used windows raid (or apparently intel “fake raid”) then mdraid would see the disks.
The issue is that the S100 and S300 driver specs are closed source so no one has been able to reverse construct the drivers.
@Chrisjmuk How many of these systems are you going to deploy?
If its more than 2, you might want to consider using MDT for image capture and deployment. It surely won’t be as fast as FOG, BUT you can load the windows only RAID drivers in the deployment.
@george1421 Sorry no joy for you. There isn’t (at least what I can find) ANY raid controller driver for the S100/S300 dell raid cards.
I feel FOG is not a good solution for this cloning task. You may want to look into solutions that are WinPE based where at least you can inject the needed driver into the WinPE environment. All linux based imaging solutions will have the same issue as FOG.
@Chrisjmuk That is what I’m looking for. If we could find a driver it could be added to the FOS engine.
@Chrisjmuk ok if mdstat returns nothing then the mdraid driver is not able to see the S100 raid controller.
There may be no joy for you then.
https://www.cyberciti.biz/faq/dell-poweredge-s100-s300-linux-driver-raid/
I’m going to still keep digging.
@Chrisjmuk We need you to get to the FOS command prompt to figure that part out ( /dev/md126 ). Since we don’t have that hardware available, guessing is our best path forward.
@Chrisjmuk yes, this kernel parameter tell FOS to load the driver code for software raids.
@Chrisjmuk Sorry I was updating my original post. I’m going to lookup a tutorial that talks about software raids.
This article is not directly related to your situation, but it is a close friend.
https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid