@Tom-Elliott @bjmarowitz Well, my actual problem was a bit more complex than that.

First, I was able to get multicast to work properly (via a thread I started an Tom helped me with. Found out old files left behind during upgrades and incomplete/incorrect installations were the problem.) The FOG server I was working on was a for my school. (They partnered with a non-profit organization; we do PC refurbishing for them. In return, they get the opportunity to give students hands-on experience. I’m a work-study for the IT program chairman.)

After all the work to get it functional, I took some time away from the lab to get caught up on school work. On Monday, I speak to the chairman about the lab and he tells me the multicast function is a bit dysfunctional. He couldn’t get multi-cast to work again, not without a system reboot of the server. I wasn’t there to witness this, so I take his work on it. He said they stall on the Partclone screen. He also made some changes to some things. What specifically, I don’t recall, though I’m pretty sure they weren’t directly multicast related…

I go to check the server logs for multicast, but it’s empty. In fact, all the logs were empty. They worked when I was working on the system last week Wed. Anyway, I set up a multicast job just to check. I don’t even think I got as far as I should’ve. REALLY weird.

Well, this IS Trunk, so things happen. Maybe an updated install would help? I pull the new version via SVN and install. No problems. Set up the multicast job. The workstations boot into FOG and then start crashing out. (Kernel Panic at some point later during my troubleshooting…) Something went REALLY wrong.

Now unfortunately, I didn’t document my troubleshooting and testing well enough. Suffice to say we’re now on a 1.2 FOG install until I figure out what is going on (I like Trunk/1.3’s web interface design and feature set more, so yeah…) I haven’t touched it since getting 1.2 up and running initially (I left it doing an image pull test.) I probably won’t be touching FOG again until this Thursday and Friday. (I need to catch up on schoolwork on my class days.)

It’s a convoluted mess on my end. So until I figure out something and have pertinent and sensible info to relay for advice (I can’t have people making sense of my mess when I’m not even quite sure where to start…), I’ll be quiet about the matter… Though now I have some questions (had thoughts while typing all this up):

@Tom-Elliot Are the TFTP boot files in 1.2 compatible with the features of Trunk? Or do I need the TFTP files included with Trunk for it to work?

1.2 works, so I know for sure the boot files for it are non-corrupted. My original Trunk install was actually a 1.2 to Trunk upgrade installation…

I did pull the TFTP boot files many times during my testing spree.

Again, you won’t hear from me again really until Thursday at the earliest. I hope I make progress, even if it does wind up being a dumb moment on my part.

You’re not the only one with this kind of problem. I’m guessing the TFTP boot files were updated at some point because now I get a “Non-system disk” error for pretty much anything beyond the initial FOG Boot Menu. At one point I was getting the reboot problem you described as well.

My current issue is in under FOG Trunk 5293.

At one point I was running 5191 and had a different problem (which was correctly swiftly; Thanks @Senior-Developers @Moderators !) Version 5191 had no issues with booting. I updated later to I think 523x or so and had the boot issues. I was able to recover from that by re-installing an older revision to get older boot files. Fixed the problem. But now I can’t even do that. Even with a fresh install or either 5293 or even 5207.

I’m gonna try getting 5197 installed as that should be a version that has the bug I reported fixed but should still have boot files that had worked for me previously.

@Tom-Elliott Oh, did not know that. I was using the Wiki as a reference and it never mentioned that switch. The Wiki simply states to delete the .fogsettings file. Nice to know that now. I’ll have to take note of that for our documentation.

Final Progress Report

So I actually got Multicasting to work. Apparently the switch from 1.2 to Trunk left some files behind and/or wasn’t truly complete. Some stuff I had tinkered with in 1.2 was held over in Trunk. So I essentially screwed myself over on that one.

In any event, trimming down the install (i.e. deleting almost everything from FOG), pulling a fresh copy of the trunk via SVN, and MAKING SURE the installation truly completed all the way fixed my problems. I hate self-induced problems like this, but live and learn.

Thanks for all the help! I now have a better feel for mucking around in FOG.

Some thoughts:

I noticed that if I had DHCP already running the script would abort because setting up DHCP failed. This apparently was part of my problem. (I wasn’t paying enough attention until my attempts at re-installing the system pointed me to an incomplete re-installation process.) I had to comment out that line in the script to make it easier to re-install FOG. DCHP was always running. (I’d just restart manually it afterwards, just in case.) It seems that the script interprets DHCP already running as a failure. (It doesn’t seem to have this problem with any other running service.)

Also, would it be too much to ask for an option in the installation script to purge the current settings and start fresh? I had to delete the hidden .fogsettings file a couple of times during my endeavor.

@Wayne-Workman I’ll try the procedures you posted. We do have a managed switch in the mix out of 3 total. The others are dumb switches. I’ll look into getting it arranged (physically) so the managed switch is out of the loop. It didn’t give us problems with the FOG 0.32 server we had originally, but shrug never know, right?

Well, the auto-naming/-numbering now works. Registering hosts for imaging is now far easier. Thanks for the quick fix!

As for multicasting: still having problems. I did check the interface name for the relevant settings (for the master node and one under FOG Settings). Still stalls at the Partclone screen. However, the FOG log still states that the various multicasting services are perpetually crashing and restarting. I’m guessing this is the current issue I need to resolve to get multicasting to work. They each stop working with the log stating they exit with error 255. If the services keep crashing, I assume that would screw over the multicasting jobs I set, no? What can I look at and/or try to stabilize the services?

@Tom-Elliott @Wayne-Workman Oh my… Thank you both!

I thought I already checked the interface. I was having minor issues with that when we switched from 1.2 to Trunk. Guess I didn’t check hard enough (though I never would’ve thought to check the interface name in relation to UDP Multicasting.) I’ll be double-checking once I’m in to look at the server.

@Tom-Elliott Thanks for the quick fixes to that (those) bug(s)! I’ll be heading in to my school in a few hours. I’m guessing I’ll just have to update the trunk copy I have (via SVN) and “re-install”/update FOG, correct?

Again, thank you for the help and support. I’ll follow up with a progress report once I get to work on the server once more.

@Tom-Elliott @Wayne-Workman My apologies. We started with a 1.2 install and then switched (upgraded( to a Trunk install. Web GUI says 5161 somewhere… So my primary issues are now in Trunk 5161.

@Wayne-Workman For the multicasting, could you define “master storage node set”? I only just got into FOG (and Linux). We currently have a single machine with CentOS 6.5 and just FOG Trunk 5161 on it. All the services required to run FOG are ran from that single server. So the only storage node with have is technically the FOG server itself. I’m currently home, so I won’t be able to look at the machine again until Monday, but I’ll take at look interfaces like you mentioned. I do recall having a slight issue with interfaces at one point, though that seems to be corrected for now. (Unicast and Torrent-cast worked.)

@Tom-Elliott Actually, now that I think about again, the multicast issue I had was similar to other threads I’ve seen here: The job is started, but the log says it stops and “completed” 10 seconds later. The hosts that are part of the multicast job just hang at the PartClone screen, waiting. This was in FOG 1.2 (so not quite relevant currently, I guess.) Currently in Trunk 5161, I think the 3 multicast services were spamming the log, terminating with a 255 error repeatedly.

I haven’t looked into the current multicast issues as much as I would’ve like. I got hung up on testing an troubleshooting the Auto-reg/Auto-numbering issue I came across. For now, I just want to focus on the AutoReg/-Number problem I have.

Thanks for the quick replies!

Hello. New-ish FOG user here.

I’m work-study helping my school set up a refurbishing lab for a non-profit. We were able to get a function FOG 0.32 set-up running on CentOS 6.5 after some hurdles and stumbling.

Our current project is setting up a 1.2 server on CentOS 6.5. FOG 0.32 served well enough, but the capabilities of the 1.x+ versions made us want to upgrade.

FOG1.2 was installed fresh on a new machine (different from the 0.32 machine we used; the 0.32 system is our fallback server currently.) We had issues with Multicasting, so we updated to the trunk version (vis SVN). Multicasting still didn’t work for us, but the newer torrent-casting works well enough (tested on 5 machines), so we decided this will do.

However, the Quick Registration Autonumbering system seems to have a bug in it. It doesn’t increment the number properly and apparently inserts invalid data into the DB. This invalid data manifests itself as “ghost” hosts. The “hosts” appear in the DB but can’t be manipulated in any way from the web GUI (they don’t even appear there). This includes ghost entries in Groups if I have a default group set in the autoreg options.

The autoreg numbering system is VERY useful to us since there will be refurb’ed machines we’re return. Especially because the lab this is being done in is for fellow students to get some hands on training. We do have a time table to eventually follow (we have leeway since we’re still in the set-up phase.) Having the autoname/number option work properly would reduce the workload on the core staff for the lab (an instructor and 2 work-studies.) We currently have 72 machines to re-image.

Is there anything I could check/edit that would correct the behavior of the auto-numbering system? Any help would be appreciated. We’d prefer not defaulting to using MAC addresses as the hostnames nor manually assigning hostnames via full registration or post-imaging.