@krishna said in PXE Windows Client registration:
10.20.0.9 has no relation to my environment.
Well this information has to be coming from somewhere.
For the subnet where your clients are running, look at your dhcp server. Confirm what is at dhcp option 66 on your dhcp server. If its set correctly then we will need you to get a pcap of the booting process. To that point is the fog server and the target computers on the same IP subnet?
@fry_p said in Dell Vostro 470 - UEFI net boot fails:
I am wondering what else I could try if this is a fixable issue.
@krishna From a web browser if you key in http://10.20.0.9/fog/service/ipxe/boot.php?mac=00:00:00:00:00 you should get the text that makes the iPXE menu. Do you get this menu?
@tesparza said in One central FOG server plus multiple Storage nodes in different locations possible?:
Master server or Storage node
It depends on the location. If you are pxe booting at the remote site then the slave at the remote site. This would be for dhcp option 66.
If at HQ then the HQ fog server.
Understand how this will work at the remote site. You will transfer iPXE boot loader from the local site, then iPXE will reach out to the master node to get the iPXE boot menu. Then when something in the iPXE boot menu is selected bzImage and init.xz will be loaded from the local (storage node) fog server.
@tesparza said in One central FOG server plus multiple Storage nodes in different locations possible?:
So does the storage node hold any image or essentially is just like mirror?
A storage node contains a copy of all images on the master node, where the replicate checkbox is selected in the image definition.
@rodluz said in Post Download Scripts Included Variables:
What does the dots command do?
That is a fog built in command. It makes pretty text like this.
This is step 1................
Cleaning up ..................
Done Processing ..............
You will see this text during imaging. It fills the remainder of the line with dots adjusting based on the length of the text string.
Also does the file have to be a .rek filetype or can it just be a txt
I just picked a file extension probably not in use. The .rek file is short for I was a total brain wreck by the time I finally figured out how to do what I wanted to with that process.
@rodluz Here is my code that I used top patch the deployed image. It has the concepts you might need.
#!/bin/bash
# Only do patches of the PlatformVersion file exists
if [ -f "/ntfs/Windows/PlatformVersion.rek" ]
then
platVersion=$(<"/ntfs/Windows/PlatformVersion.rek")
echo " ";
dots "Platform Version";
echo "${platVersion}";
# Identify what Image version we deployed
case "${platVersion}" in
3.1.0.2*)
# Unattend.xml is missing the driver load section
rm -f /ntfs/Windows/Panther/*nattend.xml
cp "/images/patches/${platVersion}/Unattend.xml" "/ntfs/Windows/Panther/Unattend.xml";
;;
3.2.0.0*)
# Unattend.xml is missing the driver load section
cp "/images/patches/${platVersion}/Unattend.xml" "/ntfs/Windows/Panther/Unattend.xml";
;;
3.3.0.2A*)
# Unattend.xml is missing the driver load section
echo "Patching the unattend file in 3.3.0.2A";
cp "/images/patches/3.3.0.2A/Unattend.xml" "/ntfs/Windows/Panther/Unattend.xml";
echo "Patching done";
;;
*)
# Nothing really to do if the version is not identified
echo "OS patching is not required";
echo " " ;
;;
esac
# Clean up any *nix stuff in the SetupComplete file
[[ -f "/ntfs/Windows/Setup/Scripts/SetupComplete.cmd" ]] && unix2dos /ntfs/Windows/Setup/Scripts/SetupComplete.cmd
debugPause;
sleep 5;
fi
@aloniada Where did you get vmlinuz and initrd from? Was it off the lubuntu iso image? If so, if lubuntu is similar to ubuntu and debian, you need to use the netboot kernels. This is typically a separate download you need to get.
At the time vmlinuz starts, the lubuntu kernel is in charge. The only thing the fog server is just sharing its disk via nfs.
@rodluz There is a couple of ways you can go about this. I’ll tell you the hacky way to get what variables you need.
Schedule a debug deploy. Schedule a deployment task to a test computer, before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer. After several screens of text you need to clear with the enter key you will be dropped to the FOS Linux command prompt. At the fos linux command prompt key in fog and press enter. This will start the imaging process in debug mode. The imaging process will stop at each breakpoint in the code. Contine the imaging process until the fog banner is displayed. Press ctrl-c to exit the script. Now key in the word set these are all of the variables available in the post install script. You can also run this command to see the parameters passed from the FOG server. cat /proc/cmdline The image name you are looking for is defined there.
Now to your task. You could use one of the tag fields in the host definition to pass a parameter to the post install script.
In my build environment I use MDT to create the golden image. One of the task sequences I have writes a build version to a text file. In the post install script I read that build version to identify if I need to do any fixup (swapping files, changing stuff in the golden image, etc) during a post install script. You could do something similar for the windows version. i.e. leave some bread crumbs behind in the golden image so you can use them during the post install script.
@fred06 It will be a bit easier than I first thought because I have a break point already in the code a the right spot.
passwd give it a simple password like helloip a sfog to start the imaging process.set if you see variables like clientdriverpath and remotedriverpath then these are the variables in the code at the point where the script is looking for the source files on the fog server. Make sure there are no extra characters in the paths. Use putty to copy the text out and paste it into this thread so I can see what the variables are.ls /images/drivers/HPConpaqPro6305SFF/win10/x64 and see if you can see the content of the directory. There has to be something amiss here. Make sure the case of the path is correct. With linux case is important.If you find something either in the file path or the script you can fix it and restart imaging by just keying in fog again. If you need to fix the script for some reason, you will edit the script on the fog server, change was is necessary then restart the imaging process with fog to see if the script runs as expected. You can restart imaging as long as the target computer doesn’t tell the FOG server its done at the very end of the imaging script.
@fred06 OK give me a minute to collect a few things. We are going to do a debugging session to see if we can understand what is going wrong with the script.
@fred06 ok so we now know what dmidecode is outputting. What does the output of ls /images/drivers look like?
@aloniada Do you actually see the kernel boot? Ubuntu 20.x brought some new pains into pxe booting a live OS. I’m suspecting the nfsroot=${fog-ip}:/images/os/lubuntu/ is causing some issues.
If you look at a debian image args
imgargs vmlinuz initrd=initrd boot=live components fetch=http://${fog-ip}/os/debian/10.7L/filesystem.squashfs
They are actually fetching the filesystem using http.
I also noticed that you mix 32 bit and 64 bit. Are you implying that both will not boot via pxe?
@sebastian-roth said in GParted Live from FOG:
By the way, do you think the double … vmlinuz vmlinuz … in that line is correct? I don’t think it’s causing an issue but nevertheless stumbled upon this.
Well that format is understood but still a little confusing to read. If you rewrite the call so its a bit clearer it would look like this
kernel tftp://${fog-ip}/iso/gparted/live/vmlinuz
initrd tftp://${fog-ip}/iso/gparted/live/initrd.img
imgargs vmlinuz boot=live config components union=overlay username=user noswap noeject ip= vga=788 fetch=tftp://${fog-ip}/iso/gparted/live/filesystem.squashfs
boot
In regards to the OP’s error. One might think that secure boot is turned on or you are trying to boot a bois or uefi boot image with the opposite firmware.
What I might do is on the fog server and run file /tftpboot/iso/gparted/live/vmlinuz to see if it comes back as a valid linux kernel.
@lcsmd I have a tutorial here how to create the FOS Linux boot drive.
https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image
Because of the way the forum works part 1 is at the top of the article and part 2 is at the very bottom.
Also look at your forum chat for a few additional hints to get started.
@greg-plamondon I’m looking at the iso image and I think we should be able to pxe boot it.
In the tftp root directory create a dir to hold your files.
mkdir -p /tftpboot/os/port
Copy from the iso image /boot/vmlinuz and /boot/initrd.xz to /tftpboot/os/port on the fog server.
Then you will want to create a new FOG iPXE menu similar to this
Menu Item: os.Porteus.Kiosk
Description: Porteus Kiosk 5.2.0
Parameters:
kernel tftp://${fog-ip}/os/port/vmlinuz
initrd tftp://${fog-ip}/os/port/initrd.xz
imgargs vmlinuz initrd=initrd.xz quiet first_run
boot || goto MENU
Menu Show with: All Hosts
Lets see what that does for you. We may have to tweak the image args because I see a parameter of http_server= in the syslinux config but its not in the grub config.
@lcsmd For this specific model we may need to bypass iPXE because its not compatible with this limited hardware. We do have a way to boot directly into FOS Linux from a usb drive. Does this hardware support booting via USB?
@rotoi Are you still running fog 1.3.3? More specifically you updated the kernel to something more modern, but have you touched the init.xz file? FOG 1.3.3 doesn’t (shouldn’t fully) support NVMe drives. The NVMe protocol wasn’t created until much later than FOG 1.3.3. Its akin to trying to install Windows 95 on an 11th gen laptop. It would kind of work, but not really well.