Best posts made by george1421

@Lee-Rowlett I only included the bits of the script that were relevant for the task at hand, there are other error and environment checking bits that are not shown. But you are right the partitions may move around so that is why I assigned them to a variable that could be adjusted with a fancy select statement. It does work with win10 if you use the unattend.xml script function.

This is very, very strange everything should come across except for the physical media. I guess we need to check the apache error log. If you were on rhel it would be /var/log/httpd/error_log. Try the data import and then right away tail the error log and see if the import threw a silent error.

@RobTitian16 Your golden image can be as setup as you need. My recommendation would be for you to use MDT to build your golden image with all of the windows updates applied, install your applications that can be installed before deployment and exclude applications that cannot be prepackaged because they build an install unique guid (like managed antivirus applications). Then sysprep the image capture then deploy with FOG.

If I did this on my campus I would check into the options for unattended install then setup MDT to install these images automatically during reference image build. If you can get the remaining tweaks done by scripting you can integrate those scripts into the MDT build too. I know it takes time to setup the first time, but then after that you can churn out new reference images by just starting the MDT task sequence.

On our campus we have 2 base images. One is a windows thin image which is windows, .net, vc++ libraries and the fog client. Then we have a fat image that includes the thin image content plus all of our standard office applications (office, java, av, flash, acroreader, etc). We use the lite touch method to create both images every quarter.

Now there is another philosophy you can use. Deploy a thin image and then use either snapins or some other deployment tool (like PDQ Deploy) to push out your standard applications.

Any route you take the key will be to see if you can install the applications using a silent or unattended install command line and then identify the tweaks you need to do to the application and script those during the install. This is all for the reference image build or post imaging deployment.

And one last thing, in your unattended.xml file, if you have the copyto key set any changes made to the administrator account on the reference image will be copied to the default user account when sysprep is run. That way any tweaks make to the administrator account will be reflected in the new profile when users first login.

@cnkpadobi Not sure, but the pcap was damaged some how after 192.168.0.23 booted. When you pxe boot the one that fails, please pay attention to the IP address being issued. You should see that on the bios screen just before it transitions over to iPXE. So you have to read fast. That will tell me that I’m looking at the right system.

One question, the system that doesn’t boot is that a uefi system or bios (legacy mode) too?

Now that we have the capabilities to query FOG database variables during the ( (b)ash ) post install scripts [ https://forums.fogproject.org/topic/6463/expose-fog-host-and-image-properties-to-post-install-scripts ], it would be interesting to see if its possible to replace PXE booting for select (troubled) hardware with USB bootable FOS image.

The main issue I see is in implementing such a system is that for pxe booting kernel boot time parameters are passed from the iPXE boot menu to the bzImage as its is launched. For USB booting there would not be any intelligent boot parameters because these are currently handled programically by the boot.php script. So the USB FOG client would need a different way to collect these kernel parameters. Enter in the feature request listed above. Using a similar method the USB booting FOS client could query the FOG server to request this information.

For the USB booting FOS client we will use GRUB as the boot menu managers, to give a similar experience as the FOG iPXE menu. The GRUB boot loader could pass a kernel parameter to bzImage (and then onto to the inits) to signal it being a USB boot. This flag would then instruct the FOS client to query for the missing kernel parameters (or just eliminate the kernel parameters all together in favor of the php query method.

I’ve looked in the inits and these are the only scripts I found (so far) that reference the kernel parameters directly.
/bin/fog.capone
/bin/fog.checkin
/bin/fog.sysinfo
/usr/share/fog/lib/funcs.sh

With funcs.sh actually doing the conversion from kernel parameters to (b)ash variables. It looks like it would be trivial (so to speak) to check if the USB boot kernel parameter existed and then launch the direct query to the fog server which would populate the required (b)ash variables.

I understand that some concessions would have to be made because the grub boot would be pretty much static. The USB boot FOS client would only support the basics of registration, image capture and image deploy. Any other functionality beyond that would be nice to haves.

We already have guidance on how to create the FOS usb boot drive [ https://forums.fogproject.org/topic/6532/usb-boot-target-device-into-fog-os-live-fosl-for-debugging ] so we do have the majority of the required technology already developed. We would just have to develop a php page that would create the required kernel parameters as exported (b)ash variables as we have with the hostinfo.php script.

@Wayne-Workman I though you would know of a wiki for that.

Just off the top of your head, do you know of a wiki that talks about pxe booting from usb flash. I know how to do it for uefi, but not bios. If not I can work on a process tomorrow.

@RobTitian16 You can’t shake a stick at the internet without finding a guide on how to setup MDT. Google is your friend here.

https://www.404techsupport.com/2016/01/setup-mdt2013u2/

The idea/concept is to setup your golden image on a vm using mdt to build it. Configure that image, then capture and deploy with FOG.

MRCUR is right. Just create a new image definition and then change the image associated with your lab reference image to that new image definition and finally upload your reference image to the new image definition. And the last step is to change your reference system back to your default image definition.

From there if you want to switch to the new image, you can just pxe boot the computer and do a quick image to select the alternate image for your target computers in the lab.

As for sysprep, I say always do. But if you are pushing out a standard image to the same hardware from where it was captured from I’ve heard of people who do this without sysprep. Just make sure your reference image is not connected to a domain when you capture it.

Just as a recommendation to properly trap the condition of a IT tech USB booting the FOS client into a capture/deploy mode without the first scheduling a capture/deploy task via the FOG Management GUI, I would ask the following concept added to tail code in /bin/fog

This says that if the FOS Client was booted from USB and the type is Null (as in the case of no action waiting for the target host) trap the error and inform the IT Tech what action to take next. The wise guy in me would probably say “Nothing to do here, go away” but that might not translate to well globally.

    case $type in
        down)
            fog.download
            ;;
        up)
            fog.upload
            ;;
        *)
            [[ -z $type ]] && type="Null"
                #New code added here
                if [ $boottype == usb ]; then
                   handleError "Fatal Error: No scheduled task was found for this host.\n\nPlease schedule a task using the FOG webgui before usb booting this target host.\n"
                else
                    handleError "Fatal Error: Unknown request type :: $type"
                fi;
            ;;
    esac

The only issue I can see for dnsmasq is that the fog server is not on a subnet by itself. From what I think I understand the fog server is on the same network as the clients and the dhcp settings are coming from a remote location. Unless I’m off on this you can not run dnsmasq and dhcp-relay for the same subnet since both will respond to the dhcp request

@RobTitian16

Q1 Batch file: This is an independent batch file from MDT. We do a few clean up actions just before sysprep and power off. We do this via a batch file and at the end of the batch file it runs the sysprep command with a consistent syntax. That way we get the same exact action every time we build a master image and then sysprep it. It could be done manually by copy and paste, but its much easier to run the batch file. We do have the sysprepit.cmd file as well as some branding stuff installed as a MDT package. That is how it gets copied over to the reference image as a MDT package.

Q2 CAB file: Understand there are 2 different cab files in play here. We install the winpe cab file in the reference image since that contains the core drivers we need post deployment. The driver path /images/drivers/{hardware_type}/{os_type}/{arch}/{driver files} is the extract of the model specific cab file. If you give me a specific dell model I can point you to the proper cab file.

@gabbas Correct. You first create an image definition then connect that definition to a reference host to capture … dang Tom is too quick.

For this part of the PXE-less boot the FOS client, I think its a wrap (finished). There is sure some nice to haves that can be done inside the inits but for the usb and the usb booting part I think I’ve reached the end. While I’ve only tested this on a bios system, I expect it to work under uefi too.

Here is the final grub menu for this iteration. I plan on writing a complete tutorial on how to build this usb later tonight.

set myfogip=192.168.1.88
set myimage=/boot/bzImage
set myinits=/boot/init.xz
set myloglevel=4
set timeout=-1
insmod all_video

menuentry "1. FOG Image Deploy/Capture" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "2. Perform Full Host Registration and Inventory" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=manreg
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "3. Quick Registration and Inventory" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=autoreg
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "4. Client System Information (Compatibility)" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=sysinfo
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "5. Run Memtest86+" {
 linux /boot/memdisk iso raw
 initrd /boot/memtest.bin
}

menuentry "6. FOG Debug Kernel" {
 echo loading the kernel
 linux  $myimage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 keymap= boottype=usb consoleblank=0 rootfstype=ext4 isdebug=yes
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

To not add too much more noise to this thread. It looks like yum isn’t able to resolve the external repositories dns names.

On this fog server, you set a static IP address, did you remember to update /etc/resolv.conf with the DNS servers the FOG server will use to query for internet names?

Since you have direct internet access can you ping www.google.com? Or one of the repositories mirrors.gigenet.com?

First people seem to have better luck pxe booting with ipxe7156.efi instead of ipxe.efi.

To your questions.

1. Secure boot: Not unless the OS you are booting with is Microsoft Certified ($$$). Secure boot needs to be off for imaging.
2. GPT should work with win10 just fine.

I can tell you that FOG 1.3.5 stable has an issue with expanding/shrinking hard drives under certain conditions. I’m not saying that this is your issue, just there IS an issue under certain conditions. This issue was resolved in the 1.4.0RCx branch. Barring any unexpected new problem 1.4.0 stable will be released very shortly. You can either upgrade to the 1.4.0RCx branch or wait a little for 1.4.0 stable to be released.

@RobTitian16 What you need to confirm is does the entire target path exist?

If I had to bet, I would say this path exists on the target computer c:\windows\setup and thats it. If that is the case you need to create the scripts folder in c:\windows\setup folder.

Also remember I said CASE is important. /ntfs/windows/setup/scripts is not the same as /ntfs/Windows/Setup/Scripts as it would be in the windows OS it self, you are still running linux here.

If you single step through a fog deploy like I posted and run into that error, press ctrl-C to blow out of the script. Then you can inspect the /ntfs path to ensure everything is as you would expect it. It helps with debugging greatly.

Don’t give up here, you are doing some pretty complex stuff with FOG, but will end up with a sweet solution when it all comes together.

@Quazz said in Group Snapins:

You might be interested in post download scripts for this. Will accomplish basically the same thing, but in a more universal manner.

A post install script is the best for pushing drivers, since the target computer has access to the network using FOS, once windows boots and the drivers are not loaded you are off-line.

There are two tutorials that will help you.
https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog

This one has some background info that is useful.
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction

@Wayne-Workman said:

@george1421 a full install is fine. It’s the storage node install that fails. I had the exact same issue with a new CentOS 7 install

Let me make sure i understand this. The issue is with the storage node install, right? If so I can spin up a new centos 6.5 instance in about 10 minutes. I can confirm this with a clean install if needed. But I’m not seeing this as an issue unless the FOG installer is bringing in other repositories. That also doesn’t explain how/who php5.6 is install on this target computer. Either way I can confirm this on a clean install.

@Andy-Nicolson It does look like bios version A8 and A11 touch on wol and pxe booting enhancements. And A07 addresses “Fixed the UEFI Network boot option will not show up when Load Legacy Option ROM is not enabled”

I would surely update to the latest bios/firmware. If that doesn’t address the issue and this 9030 is still under support call dell because this does sound like a firmware bug.

@Tom-Elliott No fair giving Rob the answer. Shame on you!!

Hint: You learn more from your mistakes than your successes.