@rogerdodger Typically to would bake that into your golden image, so your deployment was all self contained.
But to your point answer me what is on that sd card? Do you boot off from the card or do you boot into windows and then run a batch file from the sd card?
There are a few options if its self bootable or you can make a winpe image that containes the files you need and then you can boot that from the fog server. SO you have a few options based on what you have on the sd card.
@Tom-Elliott Thank you for the update. I should have looked at the code.
So the OP needs to update the current curl call with this ?
base64mac=$(echo $mac | base64)
token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php")
curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php" -A ''
To make it work now?
@sega It would be helpful to have a picture of the error message to know where its getting stuck at a percentage. But If I have to guess, it would at the beginning of the imaging process where its downloading bzImage or init.xz to the target computer. When it gets hung it doesn’t ever continue.
If its getting stuck here you might want to rebuild iPXE with the latest version.
Also you didn’t mention the version of FOG you are using.
@Eazis the Arch value is probably not unique enough for your needs. arch 7 defines one of the uefi flavors. The likelihood that both of your systems being the same uefi type is pretty high.
There is something else that might be a bit more hardware specific. That value is the uuid field. I can tell you that for Dell computers the uuid is model specific. Actually the first 4 characters of the uuid is Dell spelled backwards in ascii.
So how can you tell the system’s uuid? Use wireshark on a witness computer connected to the same subnet. Start wireshark and use a capture filter of port 67 or port 68 or use a display filter of bootp With wireshark running pxe boot the target computer. You should see 4 or more packets. Look at the DISCOVER packet, this is the target computer saying “hey I’m this come configure me” In the discover packet is the uuid field. Compare these uuid fields between the two different hardware in question as well as 2 of the same model of computers. With that info you can create a custom dhcp class filter to send the appropriate boot file for the unique uuid system.
@Tom-Elliott I think I understand what is going on here, and what the OP is trying to do. I think I tried to do the same thing and ran into a similar error.
If I can guess correctly, the OP is trying to create a custom task, as with maybe the fog built in task to scan a vm for a virus (only used as an example). What the OP did is create a new custom task with the task type edit plugin. The intent of his task is to boot using the parameters values, as if you were to create a fog ipxe menu. What the OP wants to do is to apply a custom task to a set of computers. Have the target computers reboot and then run the contents of the parameters block as if there was a tech sitting in front of the computer and select the menu entry. So that is the premise of what I was trying to do.
What was really happening is that the task was applied to the target computer and then rebooted, but instead of booting using the parameters in the parameters box, it boots into fos linux and applies the contents of the parameters block as kernel parameters instead of booting winboot. So in this case the OP is getting the Null message because fog didn’t tell it to unload or download an image. I’m not sure if I explained it properly, but I can understand why the OP got the Null message, because that is coming from FOS Linux and not wimboot.
@zaboxmaster This should work unless something changed in the inits.
So first lets start a debug deployment. Tick the debug checkbox before you schedule the deployment. pxe boot the target computer. After a few screens of text that you need to clear by pressing the enter key you will be dropped at a the fos linux command prompt (I understand that you usb boot but we need to pxe boot here to get into the right mode).
(insert flash back) you updated the fog.man.reg file and its copied over to the FOS image using the fog postinit script file. Its possible that the custom fog.man.reg file is not being delivered to fos linux.
So what you will do is single step through the deployment until we get to the postinit section.
(back to reality) at the fos linux command prompt key in fog At each breakpoint in the deployment you will need to press the enter key. Somewhere along the way before the partclone screen you will see the message about the postinit scripts running. Press the ctrl-c after the post init scripts run. Now verify that the fog.man.reg file in /bin on the fos linux engine has been updated with the curl command from your OP.
If that file has been updated. then try to execute the curl command from your OP. That should create a file in /tmp as hinfo.txt look to see if it has content. It should have many lines of variables with its value.
@fogcloud Do you have a specific concern about having ssh enabled on the fog server? Are you trying to meet some kind of compliance certification?
@fogcloud FWIW fog shouldn’t use ssh for imaging. It uses ftp, nfs, http/https for imaging. I think there is another protocol but I can’t remember off the top of my head, but its not ssh.
If you are concerned about ssh being open you can either enable a firewall on the fog server or move the ssh port to some other random place so the fog server is still accessible if needed via ssh.
If you are concerend about security you could also install fail2ban to block repeated attempts to remotely log into your fog server.
@theyikes Well the first thing I would do is look to see what the kernel name is in the casper directory. Ubuntu does change this kernel name from time to time. I do think the file name listed looks suspicious. I would expect something like vmlinuz without the extension. But look to see the kernel name and adjust accordingly.
@michaelkoch1811 with the proper command line switches (sorry I can’t remember off the top of my head) the fog installer will create a self signed certificate, setup the web server and recompile ipxe with the ssl certificate. Then FOG will use ssl for communications. You can not bring your own certificate, it will need to be a fog installer created self signed certificate.
@theyikes from the linux reboot will restart the server and shutdown now will power it off.
@theyikes firstly understand that you are using fog in a way it was not intended to be used. That doesn’t mean it can’t support other functions, its just FOG’s primary focus is in another direction.
With that said to specifically answer your question. Files downloaded by fog can either go into the tftp path /tftoboot or in the http path /var/www/html/fog or the nfs path /images depending on which protocol you want to use to download the iso file using the FOG iPXE menu.
I have an extensive tutorial on how to pxe boot alternate boot images in this tutorial: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
If you want to boot the entire iso image you can use the memdisk command, but just be aware that only works on bios based computers (not uefi) and there are some restrictions in that the iso image must be less than 2GB in size (size restriction of 32 bits). For uefi systems you will need to one of the other methods to boot depending on what you are trying to load over the network.
Lastly understand that the success of net booting iso images are depending on if the creator of the iso has allowed it. Some iso images reference a cdrom path directly in their programming. This makes netbooting almost impossible since its referencing hardware that doesn’t exist during netbooting.
@HorizonG said in FOG Golden Image, Sysprep and unattend post install:
’d also try renaming the post as explained:
with the command: sed -i “/ComputerName/s/*/$hostname/g” $unattend >/dev/null 2>&1
The variable $hostname comes from FOG, the variable $unattend must come from your script to define the location of the unattend file on the target hard drive.
Something to know, If you are questioning if each script is being called, place an echo some text at the top of each script. This way you can see each script being called.
One other tip I use for debugging post install scripts is to run a deployment in debug mode. Schedule a deployment, but before you hit the schedule task button tick the debug checkbox. Now schedule the task. PXE boot the target computer you will be met with several screens of text that you need to clear with the enter key. This will drop you at the fos linux command prompt. Now key in fog to start single stepping through the deployment. At the end of the image push you should see the post install scripts executing. If you use the debugPause; command at certain locations in your script you can stop the execution and wait to press enter. If you were to hit the ctrl-c key you can exit the deploy process. What this will do is give you the exact environment where your script is running. You can try different commands or fix the post deployment scripts. If you enter the command fog again you can restart the deployment process again without rebooting.
One last tip is that when you are interacting with the deployment process you are executing on screen 1, if you need command shell access you can press alt-f2 to go screen 2 run some comands and then pop back to screen 1 with alt-f1 to continue your script.
The pather location is the location where microsoft recommends you place the unattend.xml file, because it will look for the file there first. Where you get things confused is if you have an unattend.xml file in both locations because it will aways use the pather location first.
@HorizonG I’m going to touch on a few things as you mentioned them in your OP.
If you are using the enterprise os for deployment with a vl key, the setupcomplete.cmd file should be called by winsetup. This is a feature of windows not fog. You could setup your unattend.xml file to auto login X times and then in the first run section call external batch files and powershell scripts.
Make sure you place the unattend.xml file in the proper location in the panther path. You will have much less issues if you place it there. Then when you call sysprep define the path to the unattend.xml file.
Your folder structure is OK. When I was doing deployments I put all of the files needed for post deployment (minus the unattend.xml file) in c:\windows\scripts directory.
To your specific questions.
<computername>*</computername> and then search for that string and replace it with <computername>usnycap002</computername> to define the computer name in the unattend.xml@rodluz I got everything to compile, but it was a pita.
I did compile the 0.3.32 version of partclone and 4.3 of mdadm on buildroot 2024.05.1. The new compiler complains when package developer references files outside of the buildroot tree. Partclone referenced /lib/include/ncursesw (the multibyte version of ncurses). Buildroot did not build the needed files in the target directory. So to keep compiling I copied from by linux mint host system the files it was looking for into the output target file path then I manually updated the references in the partclone package to point to the output target. Not a solution at all but got past the error. Also partimage did the same thing but references and include slang directory. That directory did exists in the output target directory, so I just updated the package refereces to that location and it compiled. In the end the updated mdadm file did not solve the vroc issue. I’m going to boot next with a linux live distro and see if it can see the vroc drive, if yes then I want to see what kernel drivers are there vs fos.
@rdfeij Well I have a whole evening into trying to rebuild the fog inits (virtual hard drive)…
On my test system I can not get fos to see the raid array completely. When I tried to manually create the array it says the disks are already part of an array. Then I went down the rabbit hole so to speak. The version of mdadm in FOS linux is 4.2. The version that intel deploys with their already built kernel drivers for redhat is 4.3. mdadm 4.2 is from 2021, 4.3 is from 2024. My thinking is that there must be updated programming in mdadm to see the new vroc kit.
technical stuff you don’t care about but documenting here.
buildroot 2024.02.1 has mdadm 4.2 package
buildroot 2024.05.1 has mdadm 4.3 package (i copied this package to 2024.02.1 and it built ok)
But now I have an issue with partclone its failing to compile on an unsafe path in an include for ncurses. I see what the developer of partclone did, but buildroot 2024.02.1 is not building the needed files…
I’m not even sure if this is the right path. I’ll try to patch the current init if I can’t create the inits with buildroot 2024.05.1
@rdfeij OK good you found a solution. I did find a Dell Precison 3560 laptop that has dual nvme drives. I was just about to begin testing when I see you post.
Here are a few comments based on your previous post.
When in debug mode either a capture or deploy you can single step through the imaging process by calling the master imaging script called fog at the debug cmd prompt just key in fog and the capture/deploy process will run in single step mode. You will need to press enter at each breakpoint but you can complete the entire imaging process this way.
The postinit script is the proper location to add the raid assembly. You have full access to the fog variables in the postinit script. So its possible if you use one of the other tag fields to signal when it should assemble the array. Also it may be possible to use some other key hardware characteristics to identify this system like if the specific hardware exists or a specific smbios value exists.
I wrote a tutorial a long time ago that talked about imaging using the intel rst adapter: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid
@zguo There are two things I can think of to create the initial error message.
@rdfeij said in Problem Capturing right Host Primary Disk with INTEL VROC RAID1:
Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation [8086:a77f]
FWIW the 8086:a77f is supported by the linux kernel, so if we assemble the md device it might work, but that is only a guess. It used to be if the computer was in uefi mode, plus linux, plus raid-on mode the drives couldn’t be seen at all. At least we can see the drives now.
@rdfeij Well the issue we have is that non of the developers have access to one of these new computers so its hard to solve.
Also I have a project for a customer where we were loading debian on a Dell rack mounted precision workstation. We created raid 1 with the firmware but debian 12 would not see the mirrored device only the individual disks. So this may be a limitation with the linux kernel itself. If that is the case there is nothing FOG can do. Why I say that is the image that clones the hard drives is a custom version of linux. So if linux doesn’t support these raid drives then we are kind of stuck.
I’m searching to see if I can find a laptop that has 2 internal nvme drives for testing, but no luck as of now.