image capture ipxe error input/output 1d0c6139
-
-
@KnightRaven
So it appears to happen when trying to do a deploy as well. Tried to deploy from pxe/fog menu and choosing the image and is getting stuck at same place. Same error i think but it exited to fast to be sure.Maybe a rights issue? but it was working yesterday before network changed.
-
I am also noticing that some of the imaging info is not pulling up on the home page webgui.
Bandwidth image does not show but title bar does. And Pie charts/graphs not showing for storage group/node. The boxes are there but no graph. Not sure if related but thought I’d make a note if it is. -
@KnightRaven Based on what I’m seeing, the node located at IP Address 10.114.56.67 is unreachable.
-
well it’s my only node for this campus. everything else is working from it. Just not imaging. The web gui is on this node and works. so are the other services.
I imagine after changing info it may be a hiccup somewhere. an address mismatch in a file, but I dont know what other settings to check. The boot.php is accessible from other machines. But unable to get to imaging. The error only presents itself when imaging. either by task from gui or by choosing image from pxe/fog menu.
-
@KnightRaven How are you accessing the GUI?
-
@Tom-Elliott
Sorry, was called to another matter.I access the webgui by http://10.114.56.67/fog…
This is from other pcs as well. Not just locally from the server. -
did you change the ip address of the fog serveR?
-
@Wayne-Workman
Yes. Had to to match our new subletting rules. Followed the steps to change it from the wiki in fog. -
@KnightRaven
Would the imaging be defaulting to using multicast? I’ve heard some other techs report problems with multicasting using Ghost. But unicast seemed to work ok.Ghost has been our standard but it’s an older version. Been trying to setup fog for myself and test it to give an alternative. Been going good til this subnet change. If I can’t get help from our networking side for it to talk across the subnets it may be a bust.
-
@KnightRaven is the fog server on a different subnet than the host requesting access?
-
@Tom-Elliott No. They are in the same room and same subnet.
-
@KnightRaven @Tom-Elliott @Wayne-Workman
it looks like it may be a multicast issue, if Fog defaults that way. Just heard that the multicast settings haven’t been pushed with the new subnets. Or so I’m told -
@KnightRaven said in image capture ipxe error input/output 1d0c6139:
@Wayne-Workman
Yes. Had to to match our new subletting rules. Followed the steps to change it from the wiki in fog.duh. Read, Wayne.
So, after setting the right IP in /opt/fog/.fogsettings you then run the installer. Is that what you did? Also - it’s fine to re-run it again.
-
@Wayne-Workman
Yes, exactly. I think I checked the settings in fog first. I went to the fog settings -> web and tftp settings in the webgui and changed it there first. But I did change the .fogsettings file and then re-ran the installer.The last couple of updates it didn’t prompt for a schema update when opening the webgui after installing update. Just went straight to login. Not sure if that matters. or is as designed in the RCs.
-
@KnightRaven Well, the only reason “multicast” would need to be enabled is for the initial TFTP boot, after that it’s using HTTP (TCP).
-
@KnightRaven if you visit that boot.php url, what do you see?
-
@Tom-Elliott
OK.
Well, I think I figured it out. I may have missed updating the storage node info. The graphs/pie charts are back working now.Setup capture and is working. Ugh. the one thing I didn’t double check after it all. Being that its the only storage node I didn’t think to check it again.
Thanks for all of y’alls time. sometimes it just needs more eyes and a better understanding of how this works. Y’all have a great day. I need a beverage.
thanks,
Jason