Hey,

i was remote on the system and we installed the current RC (switched to dev branch).
Helped him out with some sysprep lines, added to stop fog service, set it to disabled and so on.

Seemed to work well but he still has a problem with the dell’s 7050’s but i have the feeling we have that spanning tree problem like here:
https://forums.fogproject.org/topic/10512/dell-optiplex-7050-fails-to-pxe-boot

This is what he gets when trying an 7050:

Bild Text

The op will ask his network admin for a check, i suggested to connect fog and the client with a dump switch and then to the environment. This is not done yet.

The initial problem with the dell 7050’s isn’t solved yet!
@msaglioc99 any chance to give the thread subject a better name (subject) about the problem?

Regards X23

@jodantiger Well you better tell me how this partition layout was created. How would I know…

Maybe try mounting it while you are in debug mode

mkdir /mnt/sda1 mount -t vfat /dev/sda1 /mnt/sda1 ls -al /mnt/sda1 umount /mnt/sda1

If vfat does not work then try ntfs instead. Take a picture and post here.

I was looking for this solution. I just wanted to create a simple standard user with no password for students to log into. I created a powershell script and just used this line personalized for me:

NET USER username “password” /ADD

I took out the password and set Student as the username. It created a standard user named Student. Worked slick.

These errors are not related to any updates that happened to FOG, ubuntu. These are hardware errors with the target computer. The ACPI errors are a bit of a warning and can be ignored, if they bug you too much you can disable acpi on this target computer by placing acpi=off in the host’s kernel parameters.

The USB ones are a bit more confusing. It appears you have a malfunctioning USB device connected to this target system? Is the firmware up to date on this target computer?

YES! It works!

Very good ducumentation, best Support!

Thank you very much!

@brian-hoehn Check the time on the imaged laptop and the fog server and make sure they match. I’ve had this problem before and it was very confusing until I changed the time or time zone inside the fog configuration web page.

@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