@mitzayapa edit the file /tftp boot/default.ipxe and change the IP address to match your fog server. If it already matches then I don’t know how much further I can try to help. The router, at that point, is looking at itself for next-server.
Posts made by Tom Elliott
RE: Multicasting Issues
sounds like, to me, the switch is not allowing udp broadcast forwarding. This is just a guess at this point.
I’ve tested Multicast, and all seems to be working fine.
I’ve also messed a lot, today, with the fog scripts. Hopefully things are better and I’ve been republishing them as I find things and fix them too.
To me, like Wayne suggested, you should start by imaging within the same switch first (not across vlan’s).
RE: Multicasting Issues
Most times when I see the “This task has been cleaned” directly after it starting, I find it is because of the interface of the network not being set properly for the interface on the system trying to run the multicast job. I will test just to see if things are still good, but I’m nearly certain this is the case.
You could try running the command you see in the log by itself to see if it spits out any other pertinent information as well.
RE: active tasks occasionally not displayed
@mrayzies I found some strangeness in the fog.js file and this should be corrected for now.
I don’t know what to do to get the exact output you’re seeing. You can clearly see the sub is set to active in the URL. It works on almost everything else I’ve tried and I need a direct path to replicate if you can figure out one sure fire method.
RE: Replication runaway on one storage node
I’m half tempted to find out first if there was another problem altogether. I say this because there is checking. So the only way I can think of, assuming the actual replication service is fine based on the other nodes receiving the image, is the image is transferred but at the remote site the image was corrupted. So every cycle would cause it to try to replacing the file. Maybe HDD on other side was having an issue? Just thinking.
I’ve decided to publish the init’s I’ve been working/sitting on since before Christmas. With these init’s come, I think, a ton of improvements in how to handle Partitions. There’s minimal assumptive (as I call it) code for handling the generation of partitions. The minimal part is only left in for the compatibility of old images. Everything else should be very much generic and operational.
I’ve tried testing all possibilities, but I try and try and always seem to miss something.
Please let us know if the new init’s are causing issues?
RE: iPXE timeout after upgrade to trunk
I’ve solved the thread.
The timeout was because this system is on an isolated network.
The isolated network IP is 192.168.1.1, but the wifi lan is set to 192.168.1.207 (which gives the device internet for upgraded/updating).
To enable the installation to operate, I changed the IP address to 192.168.1.207 as the DB settings were already set.
This ipaddress was used to generate the default.ipxe file which was what was causing the problem and I over looked it.
RE: problem updating to trunk. Stopping web service......failed!
I’m assuming it’s safe to solve this now?