@EAHarvey You might want to check your /images folder contents, though.

The way image capture works is they get placed in /images/dev first and then at the end they get moved to /images and renamed to the proper destination name.

This moving process uses FTP, failure to move them indicates some sort of issue with that, most likely credentials, but if you’ve recently run the (trunk) FOG installer, this should already be corrected in the mean time.

@Quazz okk im creating a new account and reinstalling fog

@george1421 said in 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.

My mistake, it is 1.3.0 RC and the host is a Dell 790 BIOS based.

@Quazz
Now it works with 7zip too.
Definitely something went wrong at last time.

@Wayne-Workman Ok ill be sure to look for that in the future. Thanks to everyone who helped! Ill be sure too update frequently now haha

@Wayne-Workman

Yulp. That was it. Re-ran the install and it updated the IP address.

Thanks for the help!

@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.

@arton Are you sure the HDD exit type isn’t just set wrong for this device? Try Grub.

@fry_p I have no idea but it’s pretty concerning. Please do regular exports of your DB using the web interface via FOG Configuration -> Configuration Save -> Export, do this once a day, keep the files safe.

If it happens again, do another export - so we can see what is in it, then move to the last good export.

Also pinging @Tom-Elliott so he reads through this thread.

@kyletmanel The error you posted says you’re not using a password. You should be providing a password if one is set. The command to access MySQL when a password is set is mysql -u root -p, so any instructions you see that say to enter into mysql via the command mysql, you would instead use mysql -u root -p

@Tom-Elliott
My image was created with trunk version and what you said about d1 files work for me. Thanks a lot to all!

@boeleke Would you be able to do a TeamViewer session with me so we can look deeper? Message me if you’re interested.

They don’t lose storage groups going from 1.1.2 to 1.3.0 (any rc you want).

They don’t lose storage groups going from and version 1.2.0 and earlier because Storage Groups for snapins didn’t exist at all.

Trunk introduced the idea that snapins work in a similar fashion as images and because of this should be allowed to replicate and move around to different groups and nodes.

So it’s no surprise they don’t have group settings defined. This is because we don’t know (we being the FOG team) how you intend to use your snapins and think it’s safer to allow you to setup how you need it setup.

Please define your relevant storage groups and reupload the files as needed. This should fix the storage group problem for you too.

Thanks to all who participated in this thread. I killed the switch port that someone had a Netgear router hooked up to and everything is working fine now. FOG menu is showing up. I haven’t tried pulling down an image yet, but I have a good feeling. I will do my best to up-vote the proper answers even the earlier posts questioning the possibility of multiple DHCP servers. I had a feeling one was out there, but I didn’t think it would have a such a huge impact on FOG. Again thanks everyone for all the help!

@ecicerkofski You can do as you please, but we are a community of volunteers, and the Developers have already taken the time to put in place what’s needed for Surface Pros to work in the latest FOG Release Candidate. We will be more than willing to assist once you’re on RC-8. We’re also willing to assist with helping you get to RC-8. Generally this works for existing setups:
https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

@RobTitian16 If you like, you can use my batchfile for this. It should work across all Windows ADK as far as I know

@echo off rem The fileserver IP set FILESERVER=192.168.1.155 rem Share on the fileserver. set SHARE=INSTALLERS\ISOFILES\0-WINPE rem Username for the share set SHAREUSER=root rem Password for the share set SHAREPASS=root rem amd64 or x86 set ARCH=amd64 rem Path to hold working files. Needs about 500MB of free space. set PEPATH="c:\winpe_%ARCH%" rem ########################################################## rem Don't edit anything below here rem ########################################################## echo Creating the PE image call copype.cmd %ARCH% %PEPATH% > NUL echo Mounting the image dism /Mount-Wim /WimFile:%PEPATH%\media\sources\boot.wim /index:1 /MountDir:%PEPATH%\mount /quiet echo Adding commands to the startup script in PE echo. >> %PEPATH%\mount\windows\system32\startnet.cmd echo ping %FILESERVER% >> %PEPATH%\mount\windows\system32\startnet.cmd echo net use z: \\%FILESERVER%\%SHARE% %SHAREPASS% /u:%FILESERVER%\%SHAREUSER% >> %PEPATH%\mount\windows\system32\startnet.cmd echo z: >> %PEPATH%\mount\windows\system32\startnet.cmd echo z:\64.bat >> %PEPATH%\mount\windows\system32\startnet.cmd echo Creating the pxeboot directory mkdir %PEPATH%\pxeboot > NUL mkdir %PEPATH%\pxeboot\Fonts > NUL copy /y %PEPATH%\mount\windows\boot\Fonts\*.* %PEPATH%\pxeboot\Fonts\ > NUL copy /y "%WinPERoot%\%ARCH%\Media\Boot\boot.sdi" %PEPATH%\pxeboot\ > NUL copy /y "%WinPERoot%\%ARCH%\Media\Boot\BCD" %PEPATH%\pxeboot\ > NUL echo Unmounting the image dism /unmount-Wim /MountDir:%PEPATH%\mount /Commit /quiet echo Optimizing the image imagex /EXPORT %PEPATH%\media\sources\boot.wim 1 %PEPATH%\pxeboot\boot.wim > NUL echo. echo All the files you need for your PXE server are in: %PEPATH%\pxeboot\

Adjusts the variables as needed.

Then you can have a 64.bat at the target location, which you can edit at any time to for example create a selection menu for different setup.exe files

@Joe-Gill Was it imaging from the main server or a node?

@Joe-Schmitt What in the world could have done that? Also - kinda scary too.

@Wayne-Workman Not sure, dynmically sized hard drives can cause all kinds of issues though, one of them being that you only get the space used when your image is deployed and you’re unable to expand it in Windows.