@x23piracy Because there is a difference.

Typically for bios (legacy) mode the exit mode is SANBOOT (that is the way iPXE attempts to location the hard drive). For uefi system the best exit mode is rEFInd, which is an external program that is used to find the boot drives. You may be able to tweak the refind.conf file to look for legacy stuff but I haven’t tried it.

There is something I just discovered the other day while I was hacking FOG’s boot menus. That is the platform variable. ref: http://ipxe.org/cfg/platform you can use that in your boot local section to test to see if the platform is efi or pc-bios and then select the best exit mode there.

such as in: (warning I just glued this code together there is no testing done)

:bootlocal iseq ${platform} efi && goto boot-efi || goto boot-bios goto MENU :boot-efi <don't know the syntax for refind> || goto MENU :boot-bios sanboot --no-describe --drive 0x80 || goto MENU

@Wayne-Workman There were other issues like missing kernel command and incorrect variable name as well. Though in current FOG versions you cannot put stuff in /var/www anywhere you like because of our redirect configuration. When you turn on redirect engine debug logging you can see why. I remember having had a first unsuccessful go with trying to come up with a different redirect/rewrite config that works for the API but still allows you to have files pretty much anywhere in /var/www…

To me this sounds as if the OP never had IT in UEFI mode. I am pretty sure of that because when you try to PXE boot a legacy binary in UEFI it should not even get as far as “initializing devices” …

It worked with the following versions : mono 3.10 and fog client 0.11.12 on a debian 7 system.
Thanks !

@jgallo I’d put everything on the same particularly as it addresses replication directly. The ftp error however is not because of the password you add when installing a new node. That password is what’s created for the node automatically. Sometimes, however, it’s possible it creates unusable characters.

Nice it’s now working fine 🙂

Thanks, it was quick 😛

@roger Most probably you are seeing a Spanning Tree issue here. Configure the client ports on those Ciscos to Port-Fast and the problem should go away…

@tom-elliott said in fog.man.reg in 1.5.0. RC9:

http://${web}… to just ${web}…

Well I feel dumb. Missed one. Confirmed and that works. Thank you once again.

@george1421 What is this project called? Do you see any difference between the df -h output? Mind posting a picture of the output when booting the patched FOS?

the restart did it for me:

[09-14-17 8:44:09 pm] * Starting FOG Multicast Manager Service
[09-14-17 8:44:14 pm] * Checking for new tasks every 10 seconds.
[09-14-17 8:44:14 pm] * Starting service loop.
[09-14-17 8:44:14 pm] * No tasks found!
[09-14-17 8:44:24 pm] * No tasks found!
[09-14-17 8:44:34 pm] * No tasks found!

@sebastian-roth

I’m confused regarding what the author is attempting to do with FOG. I believe he’s trying to install XP from a Windows XP CD ISO file using FOG. He doesn’t appear to be uploading a hard drive to FOG from a PC on which XP was installed and Sysprep’d.

Once upon a time, before FOG, I used PXE to load an ISO into RAM that could be any ISO - like the Windows XP ISO file. I also used a customized BartPE image to copy / clone to the local HD a sysprep’d xp disk image of various sorts, using the Microsoft IP stack and SMB.

Looking at the root=/dev/ram0 parameter is very reminiscent of that approach, where the ISO is copied to RAM over TFTP or HTTP and then booted. If so, one would end up having to do a manual install, if the ISO is the Microsoft CD, or an unattended install if the ISO had been altered accordingly. I did this w/o FOG, using PXECLIENT, etc. and with FOG v.32 by editing the FOG Menu and adding the items to load the ISO. I was also able to compress the ISO using an SDI format that come from XPEmbedded.

With this approach, there would be no capture step, and FOG would just be used as a boot loader to get the ISO up and running.

Or am I missing something?

Jim

Please make a new thread with an appropriate title for the fog issue.

@jgallo only in that case that I’m aware of. I don’t know what the problem is though I suspect it’s because firewalls are blocking access to port 21.

@tom-elliott yep its working thanks for all your help guys

Hello,
I deleted the record and then I updated “crn-cr02-19” with fog’s graphic interface
It’s OK
Thanks a lot !

@george1421 Thanks. I’ll try the upgrade and see if that fixes it.

@sebastian-roth

As recommended, I did upgrade to RC-9, and yes the issue has been resolved. Thanks all! Please mark this as solved!

@sebastian-roth @george1421

Sorry for the late response on this guys.

The issue with this turned out to be with the OEM recovery partition that came with our dell machines. For whatever reason fog didn’t like it. Removing this partition fixed the issue and we now have the new fog server, and all the new hardware synchronizing and imaging correctly.

Thank you guys again for all your assistance in this thread (and the others). This forum has been extremely helpful

@tom-elliott Anything is possible where I work. : )

I will see if that could be the issue and let you know.

@sebastian-roth said in Snapins - ISO File:

response within a week. So I guess the OP is happy w

Yes this issue has been solved. Thanks !