Posts made by george1421

@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.

1. Yes it can be updated dynamically. I have example snippets of a post deployment script that shows how. https://forums.fogproject.org/post/69726 In my case I didn’t use the fog client at all and set the computer name, target OU, timezone, location, and keyboard using the IP address of the target system and knowing what IP range each site had. Look at this thread, the top post has links to some of the other ones where I go into a bit more details on the post deployment scripts. https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection Its much easier to edit the unattend.xml script using sed for string locating and replalce. So when I setup like the computer name I would leave the default to something like <computername>*</computername> and then search for that string and replace it with <computername>usnycap002</computername> to define the computer name in the unattend.xml
2. I kind of answered that in 1. With the postinstall script if you call the hostinfo script you can get access to most of the fog ui variables that you can include in your post deployment script. Again in this post it shows you how to replace the computer name using the fog run time variable $hostname https://forums.fogproject.org/post/69726

@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.

1. 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.

2. 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.

1. You have the fog client installed and the services hasn’t been disabled before image capture. The fog client is starting to do its action before windows is fully installed.
2. You have a driver install that is forcing a spontaneous (all of a sudden) reboot of the computer before windows is installed.

@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.

@Mr_____T If you have a router that can’t be managed or doesn’t support pxe booting, then dnsmasq is the best answer.

@Mr_____T I agree with Tom. Many soho routers will put thier IP address as the {next-server} value instead of the FOG server’s IP address even if there is a spot to configure the {next-server} / dhcp option 66 value.

With wireshark you should be able to capture the DORA (discover, offer, request, ack/nak) process since its transmitted with broadcast messages. So any computer connected to the same subnet as the target computer should be able to detect this messaging. In wireshark you can set a capture filter of port 67 or port 68 or use a display filter of bootp. Once wireshark is setup and you have the filter applied you should see at least 4 packets that align with the DORA communications. Look at the OFFER packet coming from your authorized dhcp server. (hopefully there is only one offer packet, or you might have a rouge dhcp server breaking the process). In the offer packet, look at the dhcp header fields there should be two if interest {next-server} and {boot-file}, if they exists and are correct look in the dhcp options section for options 66 (boot-server) and dhcp options 67 (boot-file). Both sets of fields need to be properly filled out.

If your dhcp server is setting itself there and you can’t change the values then as Tom suggested we use dnsmasq to configure a proxy-dhcp configuration to override what the client is being told from your main dhcp server in regards to boot file and boot server.

@bsedash You are going to have two areas where you will have difficulty here.

1. You re using an older version of FOG and FOS kernels. Newer hardware support will be missing.
2. FOG is primarly focused on desktop imaging and you are trying to image a server class hardware. I’m not saying its impossible to use fog for this, you might just need a custom kernel that has the qlogic network driver enabled.

Where the booting process is failing is where iPXE tries to get an IP address. This is where ipxe boots and then tries to get an ip address, none is received. FIrst make sure you are using nic1 on the server since this ipxe build is configured for workstation class computers and it will stop looking after the 3rd found network interface. Also since you are using fog 1.5.9 the version of delivered ipxe is quite old. Lets recompile and install the latest version of iPXE. If that gets you to the fog iPXE menu then that will solve the first problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

For the next problem, update the fos linux kernel (bzImage) but going to the webui and fog configuration -> kernel update. Update to the latest 6.x kernel to get the latest hardware support.

@El-Fogito ok lets get our hands a little dirty to debug this issue.

Schedule another image capture on this troubled server. Pick a target computer that is available for you. Before you schedule another capture tick the debug checkbox then schedule the deployment.

On the target computer you will see several screens of text that you must clear with the enter key. Eventually you will be dropped to the FOS Linux command prompt. At the command prompt try to ping the troubled fog server.

now lets try to mount the images/dev share. On the target computer issue the following commands

mkdir /ntfs
mount  10.20.10.38:/images/dev /images 

If the mount is successful then issue a ls -la /images this should show the content of the /images/dev directory on the fog server.

umount /images

If everything is good then you can single step through the deployment by keying in fog at the fos linux command prompt.

@El-Fogito Hmmm everything looks good. I should have verified this question first but is 10.20.10.38 the IP address of the correct fog server?

Is the target computer on the same subnet as the fog server?

The print out of your troubled fog server told me that things are setup as they should be and you didn’t create an unknown configuration.

@alessandro19884 said in HP Z8 Fury G5 Workstation Desktop PXE boot:

Update:
I’ve also follow this instruction:

Just to verify did you follow the instructions to rebuild ipxe? I’m finding it suspicious that the autoexec.ipxe file wasn’t found. That is something that should be compiled into ipxe. (fwiw: pictures speak better than words because we can see that its failing in ipxe (at least this time) ). The FOG delivered ipxe files has its own script built in and doesn’t use autoexec.ipxe (akin to DOS’ autoexec.bat file from 30 years ago).

@bmick10 Just to be clear recompiling and installing the updated version of iPXE address your init.xz stop issue?

@alessandro19884 This issue is tricky in that it could be iPXE or FOS linux that is failing. I don’t think this has anything to do with your disk subsystem on the target computer. Its not to that point yet in the booting process.

Lets first rebuild iPXE to the latest version because it could be the hand off from iPXE to FOS linux. Use these instructions to recompile iPXE on your fog server. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

The second part is lets update the FOS Linux kernel to the latest. In the Web UI under FOG Configuration -> Kernel update. Update to the latest version of version 6 of linux kernel.

I would do one of the above at a time so we can identify what was actually at fault.