@Don-Winters What is your dhcp server for this network, mfg and model?
The screen shots almost appear that you are not transferring the right bootloader name to the target computer.
Is your fog server and pxe booting computer on the same subnet? If so we can debug this issue a bit more in detail.
@londonfog I haven’t tried 20.04 yet, but here is the solution for 19.10. I don’t expect 20.04 to be to much different.
The NFS route is what you want. Also be aware that you need the netboot version of the kernel and initrd and not the ones off the iso image.
So you are getting hung up before the FOG iPXE boot menu. So the only thing we should focus on is pxe booting and the iPXE boot loader. FOG and/or the kernel is not in play at the moment.
One comment, the replicator connects to the remote FOG server using the fogproject user ID (as you know) but the password is dependent on the password found in the .fogsettings file on the remote storage node. You probably should run through and review the .fogsettings on the remote storage node and then from a windows computer attempt to connect to the remote storage node using ftp, with the user id of fogproject and the password found in the remote storage node’s .fogsettings file. If the ftp works, then confirm that the storage node configuration (via the master node’s web ui) is using the proper credentials and password to access the remote storage node.
@Greg-Plamondon said in Wrong Partition is mounted during deployment. (FOG 1.5.7.56):
for part in $parts; do
true
done
This is the section that needs tweaking on your script. This bit really doesn’t do anything, It loops through the partitions and says true.
@Greg-Plamondon You might want to update your partition detection script to the one used here:
#!/bin/bash
. /usr/share/fog/lib/funcs.sh
[[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"
case $osid in
5|6|7|9)
clear
[[ ! -d /ntfs ]] && mkdir -p /ntfs
getHardDisk
if [[ -z $hd ]]; then
handleError "Could not find hdd to use"
fi
getPartitions $hd
for part in $parts; do
umount /ntfs >/dev/null 2>&1
fsTypeSetting "$part"
case $fstype in
ntfs)
dots "Testing partition $part"
ntfs-3g -o force,rw $part /ntfs
ntfsstatus="$?"
if [[ ! $ntfsstatus -eq 0 ]]; then
echo "Skipped"
continue
fi
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
echo "Not found"
umount /ntfs >/dev/null 2>&1
continue
fi
echo "Success"
break
;;
*)
echo " * Partition $part not NTFS filesystem"
;;
esac
done
if [[ ! $ntfsstatus -eq 0 ]]; then
echo "Failed"
debugPause
handleError "Failed to mount $part ($0)\n Args: $*"
fi
echo "Done"
debugPause
. ${postdownpath}fog.copydrivers
# . ${postdownpath}fog.updateunattend
umount /ntfs
;;
*)
echo "Non-Windows Deployment"
debugPause
return
;;
esac
This one uses a bit more intelligence to find which partition actually has windows on it. I think your script is just picking the last partition and calling it good enough.
I was able to capture Windows 10 2004 UEFI from a source system with a 70GB disk and deploy it to a target system (VM) with 50GB disk. It deployed/booted and resized the disk without issue. Again my base image doesn’t have the recovery partition. Next week I schedule a new build task in MDT and leave the recovery partition in place at the end of the partition chain to see what happens on a deploy and resize. But for my use case 2004 works correctly deploying to a VM.
@symrex said in TFTP port is closed is it normal?:
Next-Server: xxx.xxx.xxx.xxx
Bootfile: undionly.kpxe
Option 66: yyy.yyy.yyy.yyy
Option 67: boot\x86\wdsnbp.com
It looks like someone setup a Windows Deployment server/SCCM server.
Just for clarity the next server and dhcp option need to be the same (exactly) the same goes for boot file and option 67.
The first part is in the ethernet header, that is for bootp the dhcp options are for dhcp. Some clients use bootp some use dhcp so they both need to be set correctly.
@Greg-Plamondon said in Wrong Partition is mounted during deployment. (FOG 1.5.7.56):
do you mind sharing your complex post download script with me
Sorry I will not do that because that is our secret sauce. But I can tell you I’ve documented it in the tutorials.
And in parts 3, 4 and 5 here:
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
@Greg-Plamondon said in Wrong Partition is mounted during deployment. (FOG 1.5.7.56):
Fog mounts /dev/sda3 which, in this case, is partition 3 the Recovery partition.
Why is this the case. What makes FOG pick /dev/sda3. I think that may be the question here.
The recovery partition being the last parition on the disk may be the issue with expanding or contracting the disk using “single disk resizable” within FOG in regards to 2004.
There is not quite enough info in your OP.
@Trev-lchs OK just for clarity the kernel is the FOS Linux kernel that does the imaging. That is independent of the pxe boot loader (that creates the FOG iPXE menu). Difficulty pxe booting then should be focused on undionly.kpxe for bios and ipxe.efi for uefi based systems.
@Trev-lchs Sorry I had to step away for a bit, it looks like you have it. The password found in the .fogsettings file should always be considered the master password since the fog installer/upgrade script will always reference this password when making system adjustments. If for some reason the web ui passwords get out of sync with this password you will get random failures as you saw.
@Trev-lchs you may need to be root or sudo it to view the file sudo cat /opt/fog/.fogsettings
@Trev-lchs OK, while you said you haven’t changed anything with passwords something else might be going on here. Lets have you run through this tutorial just to ensure everything is in its place and set properly: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
A good test once you complete the tutorial is to see if you can ftp from a windows computer to the FOG server using the user ID of fogproject and the password found in the .fogsettings file. (note you may have to drop the windows firewall to allow the ftp program to connect to the remote computer).
@ProfDrSir said in Imaging Windows 10 v2004 with UEFI - GPT Partitions onto 31GB or smaller drive. (and failing):
which fat standard are you using?
There are two methodologies here. The first is a thin image in that only the windows OS and updates are added to the reference image. All other applications like office, SAP, acrobat reader are added into the image on the target computer. The advantage to this is that when updated versions of acrobat reader or other applications come out you don’t need to rebuild your reference image (because it only contains windows + updates). You just change your post deployment tasks (snapins, or what every deployment tool you are using to deploy the later application)
The second is a fat image, in that you load all applications onto your reference image before you capture it with FOG (understand if you have applications that are based on a unique guid, like enterprise antivirus you must install those post imaging anyway). All of the time of loading these applications goes into the reference image and not post deployment. With MDT it takes about 1.5 hours to create and configure the reference image. When I capture it with fog the reference image is about 98% of the completed image. With a fat client I can take a workstation and go from bare metal to ready to move to the user’s worksite in 15 minutes. The system is fully configured and ready to roll. I don’t have to do much post install configuration.
To recap a thin install gives you the flexibility to modify the deployment with different applications or configurations at deployment time. A fat image you put all of your work in to the reference image up front and then enjoy rapid deployment on the back end.
Before win10 our methodology was to use the thin image approach because we could create a standard OS reference image and use it for a year or so. Basically the applications would update version more often than the OS. Now with Win10 we have to build a new OS every 18 months so the OS updates more frequently than the applications. That makes the fat image approach more beneficial.
As I mentioned a few times previously we use MDT and the lite touch approach to build our reference image. That way we can get a consistent build each time we rebuild our reference image. When we go between 1903 and 1909 we just copy our task sequences between builds and we get the same results (hopefully) when we build a new base image on the next release of windows 10 (the last OS you will ever have/need).
@ProfDrSir said in Imaging Windows 10 v2004 with UEFI - GPT Partitions onto 31GB or smaller drive. (and failing):
we can just remove / ignore that 4th partition it makes imaging slightly more tedious, but functionally should be the same as before I’d assume.
This is just my personal opinion but that recovery/restore partition really adds no value in a business environment. Using the windows recovery method it take an hour or more to bring a broken computer back. With FOG, and fat win image, I can go from bare metal to ready for the user in 15 minutes. Total tech hands on time is about 40 seconds for imaging vs dealing with the restore process. Now if you have irreplaceable data on the broken system your only option is to recover especially if bitlocker is involved.
In our case we never do an in place upgrade, its always nuke and pave when going between releases. I know the upgrade process works, its just we find its faster for nuke and pave (once the user’s profiles are backed up with USMT).
Just to be clear (I can read your request 2 different ways), fog doesn’t care about the source image or how its setup. FOG only moves disk blocks from the source computer to storage on the FOG server and then from storage on the FOG server to the target computer. How you prepair the reference image before cloning and what happens to the target computer after FOG is done is up to the IT technician.
But in general terms, for MS Windows you will want to setup the computer in audit mode to perfect how you want the target computers to appear, then sysprep the reference image and power it off (using a sysprep command line option). Then you pxe boot the reference image with FOG and capture the image. On the target computer side, you register the target computer with FOG. Then you assign an image to the target computer and create a deploy task. When the target computer is pxe booting FOG will image the computer then reboot it. On the first reboot the target computer will startup OOBE/Winsetup to complete the installation on the target computer, at this point of the first boot of the target computer FOG is no longer involved with the imaging process (said knowing that if the target computer is configured appropriately the FOG client will carry out an required post install commands).
There is a wiki page that describes capturing your first image that you might want to look over: https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image
(some of this info is derived from a chat dialog I had with the OP)
@symrex I was thinking about this a bit, since you can TFTP on the VM host server, what would happen if you spun up a new VM on the VM host server and tried to pxe boot into the fog iPXE menu. This would test if the FOG server was operational, then all you would need to focus on is why is it communicating off the VM Host server to the network. The next step is getting a test computer connected to the same network switch as the VM Host server. The connection has to be failing at some point in the booting process. We just need to find out where its working and then when it first stops.