PostDownload Script Not Working & Bugs To Report
-
Which is it?
Are you on 1.3.0-RC-26, or are you installing 1.3.1-RC-3
I’m seeing conflicting information between the two posts you have running now.
-
@RobTitian16 If you’re not on the latest, please use git to get the latest. The
upgrade to trunk
wiki article has been updated for it. -
@Wayne-Workman Thanks both - I’m now on 1.3.1-RC-5 and these problems are still occurring.
-
If boot from hard drive says chainloading failed, I think you need to change the exit type.
As for the script, I ran it through shellcheck and it notes several problems.
Not all of those are necessarily faults (since it can’t be aware of variables assigned outside of the script), but some do stand out.
One small thing I noticed is on line 24 where there’s
umount ntf
instead ofumount ntfs
Also, on line 77 you only check for one variation of ntfs/Windows/Setup/Scripts, but I’ve seen at the very least a ntfs/Windows/Setup/scripts as well.
-
shellcheck is an amazing tool.
-
@Quazz Thanks - I realised I had copied over some old script. This is the new one with still no luck in getting it to run:
#!/bin/bash . /usr/share/fog/lib/funcs.sh 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 /ntf >/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: $*" # Give the reader a chance to see what the error was sleep 12; # Terminate the post install script exit 1; fi # This next section determines the IP of the host system, cuts the last two octects and sets the FOGIP variable to # the correct IP address of the FOG server depending on the location (as the subnets are designed by location - i.e. # 10.1 is for the UK, 10.2 is for the US, etc.) myip=$(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2) case "${myip}" in 10.1) sitecode="UK"; timezone="Greenwich Mean Time"; FOGIP="10.1.0.102"; sitelocal="en-GB"; uilang="en-US"; ;; 10.2) sitecode="US"; timezone="Eastern Standard Time"; FOGIP="10.2.1.103"; sitelocal="en-US"; uilang="en-US"; ;; *) # Default code for the unknowns - we set the FOGIP to the development server in the UK. sitecode="CompanyName"; timezone="Greenwich Mean Time"; FOGIP="10.1.0.102"; sitelocal="en-GB"; uilang="en-GB"; ;; esac # Check if the direcotry /ntfs/Windows/Setup/Scripts exists, and if not then create it. if [ ! -d "ntfs/Windows/Setup/Scripts" ] then mkdir /ntfs/Windows/Setup/Scripts fi # Copy the FOGService.msi across to the target computer. [[ -f ${postdownpath}FOGService.msi ]] && cp ${postdownpath}FOGService.msi "/ntfs/Windows/Setup/Scripts/FOGService.msi" # Check if the file SetupComplete.cmd exists in the source folder and then copy it to the destination on # the C: drive. if [ -f "/images/drivers/Common/SetupComplete.cmd" ]; then cp /images/drivers/Common/SetupComplete.cmd /ntfs/Windows/Setup/Scripts/SetupComplete.cmd # append the msiexec command to the end of the setupComplete.cmd file echo "msiexec.exe /i %windir%\Setup\Scripts\FOGService.msi /quiet USETRAY=\"0\" WEBADDRESS=\"${FOGIP}\" " >> /ntfs/Windows/Setup/Scripts/SetupComplete.cmd # Re-enable the FOGService and then reboot the computer echo "sc config FOGService start= auto shutdown -t 0 -r" >> /ntfs/Windows/Setup/Scripts/SetupComplete.cmd # just in case we edited the setupcomplete.cmd file in unix lets filter it to make it DOS compatible unix2dos /ntfs/Windows/Setup/Scripts/SetupComplete.cmd fi # now lets use the timezone variable and update the unattend.xml file. You may need to edit the variable to # point to where your unattend.xml file exists. Remember case IS important. unattendfile="/ntfs/Windows/Panther/unattend.xml"; sed -i -e "s#<TimeZone>\([^<][^<]*\)</TimeZone>#<TimeZone>$timezone</TimeZone>#gi" $unattendfile # now lets deal with the internationalization stuff in the unattend.xml file sed -i -e "s#<InputLocale>\([^<][^<]*\)</InputLocale>#<InputLocale>$sitelocal</InputLocale>#gi" $unattendfile sed -i -e "s#<SystemLocale>\([^<][^<]*\)</SystemLocale>#<SystemLocale>$sitelocal</SystemLocale>#gi" $unattendfile sed -i -e "s#<UILanguage>\([^<][^<]*\)</UILanguage>#<UILanguage>$uilang</UILanguage>#gi" $unattendfile sed -i -e "s#<UserLocale>\([^<][^<]*\)</UserLocale>#<UserLocale>$sitelocal</UserLocale>#gi" $unattendfile ;; *) echo "Non-Windows Deployment" debugPause return ;; esac
Going through Shellcheck.net only pointed out variables I assume are called from other scripts (like the fog.postdownload script).
-
@RobTitian16 The things I pointed out personally are still not addressed in this script.
One small thing I noticed is on line 24 where there’s umount ntf instead of umount ntfs Also, on line 77 you only check for one variation of ntfs/Windows/Setup/Scripts, but I’ve seen at the very least a ntfs/Windows/Setup/scripts as well.
I don’t know exactly why it’s failing for you, but I suggest a debug deploy to try and figure it out.
-
@Quazz Thanks - they’ve been adjusted.
I found that SetupComplete wasn’t actually running (but was being copied across). I now know why:@Tom-Elliott said in Rolling FOG out to US Site:
@RobTitian16 It will run as soon as the system completes sysprep steps (Setting up your device).
The last thing it does is “SetupComplete.cmd”.
The path should be:
C:\Windows\Setup\Scripts\SetupComplete.cmd (though you can try with setupcomplete.cmd) as well.
Of not, for Windows 8 and Windows 10, if the image is sysprepped using an OEM version of the software it will NOT run the setupcomplete.
So I’ll have to adjust my unattend.xml file to run the SetupComplete.cmd instead.
-
I’ve marked this as solved then.
You’ve already proven that postdownloadscripts IS indeed running and copying the files where needed. You even proved that the client has the files as needed.
As for the boot from hard drive, this is almost always due to how the system is being told to boot. For example, if you’re using Grub only and the boot disk is on SATA1 it could fail because the boot information is not looking at SATA 1, rather it might be looking at SATA 0. If SANBOOT isn’t working, try GRUB, or Exit types (There’s multiple GRUB Types, and as this is windows try GRUB_FIRST_FOUND_WINDOWS).
If it’s UEFI, you may need to try rEFInd to boot up properly. I haven’t tested the register + image setup. If anybody else here wants to give it a shot while I cannot at the moment, feel free. I will test it when I get home just to be sure though.
-
@Tom-Elliott The register and image setup is confirmed to be working in the latest release Thanks!