@Joe-Gill Well, I suppose the first thing to try is this group that failed - but by itself, without other multi-cast tasks running. See what happens.

The firewall was blocking http for some reason. I don’t know why, http was opened up, I did it myself and it still wouldn’t allow it. We just disabled it. Not good practice but @kentucky_smith said he didn’t need it. SELinux was also in permissive mode.

You would just follow the instructions in the fog wiki.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

@george1421 said in database update failed after capture:

Is this a systemic issue with the 1.3.0-rcX upgrade script? We’ve seen quite a few of these exact issues in the last few days??

It’s systemic only because people don’t know that they really should define fog web ui user and pass inside of /opt/fog/.fogsettings exactly like the installer says. Additionally, people are changing the Storage Management DefaultMember password without realizing that they must too change the password setting in .fogsettings, and re-run the installer, or do it all manually.

You know what I think?
@Tom-Elliott I think if people change the Storage Management password, that the new password should be tried against that node before being stored in the DB. If an FTP connection fails with the new credentials, show a big fat message saying the credentials are bad and won’t be stored, and to first update .fogsettings and re-run the installer, and that they ought to have web ui credentials defined too so the installer can auto-update the node’s password FOR them.

@TomBagley Did you change the fog server’s IP? Have you tried updating to the latest RC5 ?

change images to Images in the image path inside /opt/fog/.fogsettings and then you can either re-run the installer, or manually change the images to Images inside /etc/exports and then restart nfs and rcp.

I’m just now reading through this thread, it’s good you updated to RC-5.

The way I’m reading the OP,

You have one node called “DefaultMember”, in an earlier picture from Location Management, it’s listed twice, with two different locations and two different storage groups. In a later picture from Storage Management, I only see one storage group, “default”.

Another thing to note is that “DefaultMember” 's max clients is set to 0 in a picture above. This would mean it would not image anything at all, because max clients is zero.

Maybe it’s best to explain what you’re trying to accomplish first?

Also, you may find this article and the video in it highly helpful:
https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

For future readers, the steps in the wiki for moving the ssl stuff for a “new” server would also work for making “another” server have matching certs. Here is the link:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

@tigerpride said in DHCP failed - undionly.pxe:

I’m not sure why partitioning is considered tricky, I just used the default guided for my VM and used the whole disk. I picked bare install (no LAMP).

So, Linux becomes incredibly ill if you fill the root partition. I’ve had it happen to me, it’s happened to co-workers at other sites. It’s happened to people on the forums. If you fill your root partition, you’re fog server will crash hard.

This is why we would always recommend putting images on their very own partition. So if that partition fills, ok it’s full, no crashed server as a result.

@TomBagley Sorry for not replying in so long. I’m not entirely sure what issue is happening, but 7492 is now old. We are on RC-6 now.

And, I image laptops all the time with fog. Laptops that have both WiFi and physical links. FOG registers the physical link when doing a full registration via the FOG boot menu. The FOG Client if in use, will register the WiFI MAC. I’ve never had an issue with this.

You’re using USB NICs. For these, I’d recommend ignoring the mac for the fog client.

If you want the imaging process to ignore a MAC, you’d check the “Ignore mac for imaging”. The thing is, FOS (Fog Operating System) doesn’t turn on, enable, nor even see WiFi Macs. So you are safe to never worry about WiFi MAC addresses.

With the USB NICs that are shared among many computers - the truth is you aren’t going to have the NIC hooked up all the time, just for imaging. You can optionally tell the FOG Client to ignore the USB NIC MAC if you like - but only if the MAC is already associated with a host. If the USB NIC MAC is not already associated with a host, this will cause the new client to go ahead and associate the newly detected WiFi MAC with that host I believe, and you can. This is because the new FOG Client reports on all MACs of interfaces capable of accessing network resources (i.e. not a bluetooth mac).

Ignore MAC for Imaging:

Ignore MAC on Client:

Hopefully this answers your questions, if you have more please ask them.

#wiki worthy

@sourcaffeine I’ve updated the FOG Client article to include a section on polling, here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Polling_Behavior

For why the legacy client is still being used - it’s so people can transition more easily. If there was no ability to transition easily, people would have more work to move to the coming 1.3.0 release. For example, imagine an organization with 10,000 computers, all have the legacy client installed, and they are using a 1.2.0 server. Do you think they will just move to 1.3.0 if 1.3.0 could not control the legacy client? No. Because the FOG Client might be a vital piece of their management. You don’t just image 10,000 systems at once, you image some at a time and move to the new client as you can. And if 1.3.0 can’t control the legacy client, then those people would have a huge gap in very needed management capabilities. How would people do something as simple as schedule an imaging task, if the existing legacy client cannot be ordered to reboot? Should we force people to use outside software like active directory, group policy, or something else? No. We provide a pathway in fog, anything less would be unacceptable.

@Motech09 Just delete that directory - be careful with that.

And just re-clone the repo.
Follow instructions in here:
https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

@TomBagley I can see the deleted post, your root directory is about full? that would cause serious issues.

@TomBagley said in http:///service/ipxe/bg.png Error 0x3e11613b / Fog UI Stuck in Loop:

@Wayne-Workman Yes, very nearly. I deleted because I was able to access the FOG UI eventually. How do I know what I can/can’t delete? Or should I be looking to rebuild onto a VM with more space?

I’d first start by looking for snapins that are in /opt/fog/snapins but are not in the web interface snapins management area, and delete the ones that shouldn’t be there.

There are some linux commands you can run to list all files sorted by size, I’ll see if I can find them.

@cojohnson Test the FTP credentials for the main.

@alexwellslinden It sounds like the host is passing through iPXE successfully, and there is no task, so it’s sent to the HDD which has no valid OS on it, or the firmware is in the wrong mode (BIOS/uEFI) and can’t boot from the HDD.

@jamesb Well, if you have ruled out the patch cable, gunk in the chips, RAM, and know that all the other exact-same models work fine, you’re left with just the problematic computer. It could be a bad power supply, giving out too much or too little voltage, or unsteady voltage. Or it could be a bad motherboard.

You could try to update the firmware on the motherboard to see if it helps.

@K.Hays said in Problem updating fog: Backing up Database ... failed:

@Wayne-Workman I believe so

Doublecheck that this username/password is correct inside /opt/fog/.fogsettings
They are listed as snmysqluser and snmysqlpass and snmysqlhost

@Buzer1 we need to know what version of fog.

@mclapper68 Try to uninstall the remi repo, and then re-install it.