George is correct in what he’s said here. If this is a simple isolated network with one switch, two clients, and a fog server - then the FOG server just isn’t running DHCP as it should be. You can check if the service is running or not with service dhcpd status and you can try to start it with service dhcpd start on Ubuntu 14. Your configuration file will be at /etc/dhcpd/dhcpd.conf If you told the FOG installer to do DHCP, the fog installer would have built this file for you and configured DHCP too, and enabled it and started it as well. I can test that this is working properly on Ubuntu when I have some time. I can say that it works just fine with CentOS 7, I’ve not tried DHCP via FOG on the other major distributions in a few months but I don’t think any of that code has changed much.
My comments would be the same with only 15 hosts even if you are staying on 1.2.0. You can do a manual copy and paste much faster than messing with database exports and imports. If you had a 100 hosts then I “might” explore the database route first.
@cpast The developers confirmed and fixed the issue and it was done in time to get into the RC15 release. If you have not done much configuration the easiest way to get this fog server back on track is to:
If you have any configurations you want to save make sure you export the settings.
Refresh the installer to RC15 (git pull or svn up )
Login to mysql using mysql -u root (provide a password if you gave root a password for mysql)
key in drop database fog; (understand when you do this your entire fog configuration will be gone, and then reset to default in step 6. Save what you need saved before you execute this command).
Key in exit
Run the installer again in the …/bin folder (this will install RC15 and rebuild the fog database)
@dholtz-docbox On Dells, they can be in UEFI mode, but if legacy option ROMs is enabled, that UEFI system will boot from something like undionly.kpxe. But when this happens, it will never properly exit to a GPT disk. I’ve seen this before at work.
Most likely, the answer here is to configure DHCP to hand out only ipxe.efi.
This makes a lot of sense. I have seen the FOG Client referenced numerous times and thought it to be the web portal this whole time! Thanks for pointing me in this direction though! This is exactly what I wanted, before I went and did a whole bunch of unnecessary work, heh.
I’m confident the installer doesn’t touch iptables or firewalld. The plainrouter and router and other stuff in .fogsettings is only for configuring DHCP. I think that DHCP is messed up.
If you modify /opt/fog/.fogsettings and change these fields:
Then the FOG installer will never again touch the DHCP configuration or DHCP service. Then you can configure /etc/dhcp/dhcpd.conf the way it needs to be for your setup. Feel free to post this file to get help with configuring it if you need.
Understood - I felt I should have done that as well; my mistake.
That said, I have resolved the issue. The issue was addressed by updating the swap drive’s UUID. I raised this question before, how the swap drive does not correctly re-assign its UUID upon deploying an existing image. I had to manually re-assign this to get the image capture to work correctly. Moving forward, the swap drive’s UUID needs to be set as a part of the post-imaging process. Otherwise, subsequent image captures will fail, it appears, from my experience so far.
Nonetheless, thank you for being so attentive - all of you. You guys are seriously the most enjoyable group of dev’s I have had the pleasure of asking questions.
OK. Thanks. I guess I will just recreate my original image without LVM. I will probably get rid of the XFS while I am at it since they don’t shrink. BTW, 1.2.0 and 1.3.0 both treat the LVM partition the same.