While I doubt this will fix the problem, I do hope to have a nicer approach to having a device receive an IP Address now.

As stated before, the current mechanism just waited for “ANY” ip address to be assigned to any NIC as needed. As long as it received an IP address (regardless of if that IP could communicate to the FOG Server) it would break out and try “driving” forward with the tasking.

I’ve added what I hope will allow a more dynamic approach to detecting the real fog network. Would you mind giving a try using the init’s and instructions here:

wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

With this, you’ll also get the latest fixes from last night in regards to resizing code bits and what not. (This isn’t a bad thing)

@Wayne-Workman Thank you, that’s exactly what I needed! Problem solved.

@ch3i
Okay, I’ll test that and let you know. Thank you for your help.

@george1421 That will be overwritten the very next time he updates fog unless the blexports option in /opt/fog/.fogsetting is set to 0

You can edit this file with vi or nano and set that option to 0. This way the changes that George suggests will stick the next time you update fog.
Reference:
https://wiki.fogproject.org/wiki/index.php?title=.fogsettings#NFS

This is a Face Palm picnic error!

I was updating the main fog settings. I was thinking if I changed that setting it would change it for all hosts. I forgot I have to edit the host information to make a change to a existing host. (Did this via a group)

Still, my username and password hadn’t changed between the fog upgrade, so something was wrong, but I should have spotted my error when trouble shooting 🙂

This ticket can be closed

Good day,
issue is solved; line 060 was being used by WDS server, which is inactive for some time and we do not use it anyway. It was agreed to disable this line and so FOG server is already running smoothly - 40 GB test image deployed on testing PC within 3 minutes. AWESOME! Plus I’ve managed to integrate few utilities such as Clonezilla, Clonezilla Server Edition (or DRBL live), System Rescue CD, PMagic, GParted and AVG Rescue CD.

Will come back with other questions; thanks so far!

@oraniko Either you want us to help you fix the issue or you want to do your own thing.

FOG RC 15 and 16 where both released 15 actually hopefully having a fix to the problem you’re describing.

If you really want to go back to 1.3.3 that’s up to you, but doesn’t help us fix what the problem actually is.

@IhaveNoIdea said in Help with school project:

And now i got another question, i have movable hard drive where i have installed linux and fog. The main hard drive in computer is win 7 and can fog clone it and make image off it?

The way I interpret that is the computer has two disks in it, and he’s got Linux + fog on one, and Windows on the other. Still the second disk cannot be imaged by FOG if it’s in the same system that is running FOG - at least not literally like that anyways.

@george1421 George hooked me up after sending him a screenshot. Turned out to be something incredibly simply on my part–search scope was set to “Base and Subtree” instead of “Subtree and below”. I seriously compared these side by side I don’t know how many times, but my brain was not seeing that difference for some reason.

Really appreciate the help!

@george1421
I had Pxelinux.0 in my dhcp, the new code replace it now.

@oraniko yes you found that pxelinux.0 is not wanted/needed with the current version of fog.

Thanks a lot for the fast response
that worked perfect!

@george1421 Thanks for the info, I’ll look into that. Our network is quite small and I’ve fogged dozens of machines here. This was the first time I’ve ever encountered this issue.

@george1421 Thanks again you’ve been a great help, I went through the install again and was able to PXE boot my first host on the private PXE net.

I had the same issue. For me, the problem was solved by manually creating the fog database and the fog user, and then rerunning the installer. We have a few fog servers and have always used the same mysql password, which is not blank. I don’t know if that’s what caused the failure of the db creation, but I figured I’d mention it, since the default suggestion on the installer is to use a blank password. Also, we are trying to use https, so I ran the installer with the “-S” option.

I hope this solves your issue - though given the recommendation from the developers to use trunk, it’s probably best to do that.

@george1421
Hi,
I reshaped and deployed the image
All is Ok now
thanks for your help

This was a known bug and has been fixed in 1.3.5-RC-13 I believe was the “official” fix.

@MentalBlank This happened because you used the defaults for CentOS 7’s installation. There is a guide here for how to cleanly and properly install FOG on CentOS7: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

1.3.3 is outdated, I would recommend the latest release candidate of 1.3.5, there are a lot of fixes in it that are worthwhile.

If you don’t want to reinstall the OS, we can help you remove space from /home and put that space into /images. You still need to update to the latest RC though. 1.3 and 1.4 have some problems. We will need the output from the following commands to help you move around the space, please copy/paste the output into a nice code window here:

lsblk df -h pvdisplay vgdisplay lvdisplay fdisk -l

@Tom-Elliott said in Primari mac 02:00:00:00:01:00:

@Tom-Elliott thanks Tom…I’ve done this, and I would make more test during this days and give you an update!

@Tom-Elliott

Oh yes, it’s works with this permission :). Thanks you