I would have to ask, what is your primary antivirus tool that is on these windows 7 targets?
Posts made by george1421
-
RE: [1.3.0-RC-8] 'Virus Scan - Quarantine' does not boot
-
RE: Making Fog Portable
@juice381 said in Making Fog Portable:
ODROID C2
Warning this post is off-point: I have not used an odroid device before, but I have used a raspberry pi. IF you are going to use the onboard micro sd for storage, used a good quality class 10 or uhs-1 device if you want any speed out of your device. I initially made the mistake of just going to the local big box store and picked up a cheap micros SD card. My first impression of the pi as it was junk, and unusably slow. After doing some research I decided to replace the sd card with something faster. Once I replaced the boot media with a samsug evo micro sd card the pi came to life. Depending on the number of images you need, the micro sd card may be all you need.
-
RE: How to pxe boot cent os 7
well the first one is stopping probably because you are telling it the nfsroot is an http path not an nfs mountable path. The protocols are different.
In your second section does /fog/kickstarts/centos6.cfg exist? But you are booting centos 7??
Here is a guide for pxe booting centos 7 that may get you closer. http://www.tecmint.com/install-pxe-network-boot-server-in-centos-7/
Your imgargs approach is right for additional kernel parameters. Also I would avoid the
|| read void
tags at the end remember you are dealing with an iPXE boot loader and not syslinux. I would also move your files out of the /fog path. You have an apache web server create a new parent directory called /bootimg or what ever and put your boot OS files under that like /bootimg/centos (also watch your case, its easier to use all lower case).If you want to see how the FOG developers download the FOS kernels you can key in http://<fog_server_ip>/fog/service/ipxe/bootp.php?mac=<registered_device_mac_address> You will see the kernel args and structure that iPXE needs.
-
RE: windows could not complete the installation
@MattPayerle Thats great you have it working (sort of).
I’m sure you know this already, but I will state it again. Make sure the FOG service is disabled in your reference image before you sysprep it. Then use the setupcomplete.cmd file and sc to reenable the service. That keeps the fog client from starting its job too soon in the OOBE process. -
RE: Chainloading Failed - Fog Menu - Boot HD
@Wayne-Workman said in Chainloading Failed - Fog Menu - Boot HD:
@Motech09 The default exit type (which is Sanboot) doesn’t work for that particular computer.
@Wayne, Ah your midnight mind reading classes are working. Nice job!!
-
RE: Chainloading Failed - Fog Menu - Boot HD
OK we need a bit more info, and a possible recommendation that you update to the 1.3.0 RC series before we do too much debugging.
What is version 13, is that fog 1.3.0 (something)? Since the svn versions became disconnected from the git version I can’t tell if that is current or not.
More to the point of your question, is this a uefi or bios (legacy) based target computer? Also please include the mfg and model number of the target computer.
-
RE: Fog Client Included After Imaging
The FOG client needs to be included in the reference image (with the service disabled) before you capture it. Posts deployment you would use the setupcomplete.cmd file to reenable the service. This keeps the fog client for executing commands to early in the OOBE install process that causes an install failure.
With that said you can include (inject) the fog client install post imaging with a fog post install script. This script would (in concept) copy the msi from the fog server to the target computer and then append the msi install commands to the setupcomplete.cmd file that will be executed once the OOBE process is complete. But the FOG server does not do this out of the box.
-
RE: Failed to obtain lease on eth0 after ugrading to Fog 1.3.0
@Wayne-Workman OK to state where we are (still not happy but…)
We’ve got past the pxe booting and are now at the exit mode for uefiI would like you to unhide the FOG iPXE menu for a few tests. I want to ensure that you can make menu selections and have the target system function correctly. What I’m interested in is the compatibility test, check for both network and storage media. I also want to ensure that you can register a target computer using the ipxe menu. If you can do that then the target and fog communications are working well.The part I think is failing is the exit mode for these devices to boot from the devices internal media. But lets take one step at a time and test each bit then work on the exit modes (usually what causes the most pain once you get the FOG iPXE menu to display).OK scratch that, I missed the post with the error about the storage node.
-
RE: FOG won't complete when reimaging a computer.
@rghawk said in FOG won't complete when reimaging a computer.:
Just meaning while in the process of doing a reimage(progress bar and percentage going across the screen in the blue, gray, and red screen) it will just stop and restart. Then after it restarts, the computer says Boot selection failed because of a required device is in accessible.
Just to be clear you are talking about the partclone (or what ever FOG 0.30 used) screen that is transferring the image from the FOG server to the target computer. At this point OOBE or windows setup program has not started.
So this might point to the fog server since you are saying that all target computers are doing the same. Check to see if you are out of space on the fog server storage disk or if you have a corrupt storage volume.
-
RE: FOG Client Service Updater
@Wayne-Workman said in FOG Client Service Updater:
If you go the PDQ route, be sure to include some way to first remove the legacy client. If it’s still there, the new client will not install.
Following Wayne’s instructions then you should create a batch script and deploy that with PDQ Deploy.
In that batch script you will issue the FOG client uninstall command
@echo off msiexe /X <guid of fog client> REM then install the new FOG client with msiexec /i fogclient.msi <what ever option switches>
-
RE: Lenovo Miix 700
@arton Just for clarity what were you trying to do when it created this menu? Were you trying to boot an unregistered device into the FOG iPXE menu or were you trying to deploy to this device?
The reason why I ask is that this menu isn’t complete. It has more lines than I expected but it isn’t what I expected. We may need to have the developers look at this.
I would have expected something like this based on the command I gave you
#!ipxe set fog-ip 192.168.1.88 set fog-webroot fog set boot-url http://${fog-ip}/${fog-webroot} cpuid --ext 29 && set arch x86_64 || set arch i386 goto get_console :console_set colour --rgb 0x00567a 1 || colour --rgb 0x00567a 2 || colour --rgb 0x00567a 4 || cpair --foreground 7 --background 2 2 || goto MENU :alt_console cpair --background 0 1 || cpair --background 1 2 || goto MENU :get_console console --picture http://192.168.1.88/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console :MENU menu colour --rgb 0x00567a 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item --gap Host is NOT registered! item --gap -- ------------------------------------- item fog.local Boot from hard disk item fog.memtest Run Memtest86+ item fog.reginput Perform Full Host Registration and Inventory item fog.reg Quick Registration and Inventory item fog.deployimage Deploy Image item fog.multijoin Join Multicast Session item fog.sysinfo Client System Information (Compatibility) item mdtlti.x86 MDT LiteTouch x86 Boot item winpe7a WinPE tester choose --default fog.local --timeout 3000 target && goto ${target} :fog.local sanboot --no-describe --drive 0x80 || goto MENU kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 imgfetch init_32.xz boot || goto MENU :fog.memtest kernel memdisk iso raw initrd memtest.bin boot || goto MENU kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 imgfetch init_32.xz boot || goto MENU :fog.reginput kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=manreg imgfetch init_32.xz boot || goto MENU :fog.reg kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=autoreg imgfetch init_32.xz boot || goto MENU :fog.deployimage login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param qihost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :fog.multijoin login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param sessionJoin 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :fog.sysinfo kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=sysinfo imgfetch init_32.xz boot || goto MENU :mdtlti.x86 initrd http://192.168.1.88/fog/iso/LiteTouchPE_x86.iso chain memdisk iso raw :winpe7a initrd http://192.168.1.88/fog/iso/winpe_amd64.iso chain memdisk iso raw :bootme chain -ar http://192.168.1.88/fog/service/ipxe/boot.php##params || goto MENU autoboot
Since you are running ubuntu can you tail the apache error log. I think its called error.log.
One last question, was this system upgraded or did you install it new? -
RE: FOG Client Service Updater
@Joe-Gill You can push out the client (or any msi or exe with an unattended installer) with PDQ Deploy. The free version will work for you. All that is required is the MSI and having/knowing the an account on the target computer that has admin rights. It will take you about 30 minutes to setup pdq deploy and create and deploy your first package. Its not a real big time sync. You can deploy to each machine you define, by machine OU or a custom list you can create. Its pretty flexible.
I do have to say the paid for version is well worth the cost. With the paid for version you can download already created packages for common software as well as create multi step intelligent install scripts (ie switch installers based on target system bits x86 vs x64).
-
RE: Lenovo Miix 700
@arton This last picture is what I might expect to see from pxe booting a bios (legacy) system with undionly.kpxe (not an uefi boot, it doesn’t matter but just trying to set the context). Is this the case? I’m still getting the impression that your install is broken.
What I want you to do next is to (with a web browser) key in http://192.168.15.187/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 and post the results here. Ideally this should display the FOG ipxe boot menu in its entirety (> 20 lines of stuff). If you get 3 or 4 lines and that is it, then we will need you to post (tail) the apache error log because something is broken.
-
RE: Lenovo Miix 700
@arton that’s very strange why the tftpboot directory is that why. Your screen shot contains what I would expect in the /tftpboot dir
Did the fog installer run to completion? Please run the installfog script again. If you are using a Debian based Linux you will need sudo then installfog.sh.
-
RE: Failed to obtain lease on eth0 after ugrading to Fog 1.3.0
@asbenavides said in Failed to obtain lease on eth0 after ugrading to Fog 1.3.0:
@george1421 I also tried a newer dell model 7020 and its doing the same issue as well.
That’s because I feel its a network issue (i.e. outside of FOGs control). The issue is proving its a network issue that is the tough part. Typically installing an unmanaged switch between the target computer between the target computer and the building switch will mask this issue, but it helps us point to the building switch at fault. Since all devices are doing this tells me it (the problem) is in common to all devices and all locations.
Another way to test is to plug the fog server and the target computer into an unmanaged switch and then plug the unmanaged switch into the building switch. Test this setup. If this works, then you will need to get a network engineer involved to look at your switch infrastructure.
-
RE: Lenovo Miix 700
@arton Well that’s not right for 1.3.0-rcX series. Did you upgrade this install from a previous release? This looks a bit like a FOG 0.30 tftp directory.
How did you install 1.3.0? I assume you downloaded the installer from git or svn, then did you run the installfog.sh script in the bin directory?
-
RE: Lenovo Miix 700
Right the NBP indicates this is a uefi device. In this case you need to use a uefi compatible boot kernel. As a suggestion, change your dhcp option 67 to ipxe.efi. Then pxe boot the target computer again.
FWIW, the undionly.kpxe is for bios (legacy) devices.
Looking at your ls command, ipxe.efi doesn’t exist. This IS an issue. Please confirm that you have ipxe.efi as well as about 4 others in that /tftpboot directory.
-
RE: FOG won't complete when reimaging a computer.
said in FOG won't complete when reimaging a computer.:
it just stopped finishing imaging
Can you explain exactly what “it just stopped finishing imaging” means?
I see two possible interpretations of this
- FOG fails to completely send the image to the target computer
- FOG does complete sending the image to the target, but the OOBE process now fails to complete leaving a broken install.
Which one is it?
-
RE: Lenovo Miix 700
said in Lenovo Miix 700:
start to pxe says download MIB
Just reading between the lines here, specifically “start to pxe says download MIB”
My bet is not MIB but another 3 letter name that starts with an N like NBF (I can’t remember the exact name). If that is the case then this sysem is a uefi based computer. So we also need to know what do you have configured for dhcp option 67?
-
RE: Failed to obtain lease on eth0 after ugrading to Fog 1.3.0
@Wayne-Workman I know in the inits that the developers added the loop for the count of 4 for dhcp discovery, which I think the timing should have put it past the 27 seconds forwarding threshold. There should be two values. There should be a loop count and then a wait time you can play with. You “could” pass a kernel parameter to adjust either. It wouldn’t be that hard to extract the inits and update the code. This way if the kernel new parameter didn’t exist then the defaults would be used.
Just in case its not a spanning tree issue we have also seen issues with certain network adapters and green ethernet (802.1az). Typically a dumb (unmanaged) switch would mask this issue. But in the OPs case they are using a pretty old dell o745, and it doesn’t have any of the green ethernet stuff.