[quote=“Uncle Frank, post: 42937, member: 28116”]Who would’ve thought that it were wrong entries in /etc/exports… Sounds a bit like you hit the wrong keys when installing FOG. When the installer asked for the path you gave ‘y’ for ‘yes’ maybe…[/quote]
Well I actually just used the script I had posted in these forums that I made when .33b was still the dev.
I guess something changed in the installer for the images path not defaulting to /images with a y?
Well I feel dumb,
I just had to edit the etc/exports file after updating to say
/images …
and
/images/dev…
instead of
y…
and
y/dev…
Not sure why it changed itself to y as the images directory, it looks like everything is working now. Thanks again for all your help.
Thanks,
-JJ
I just installed nfs-common on mount test machine and I got a more detailed failure.
Edit: Oh an my permissions are currently set to 777 for the /images folder for the sake of testing.
Typically I have them set to 775
owner and group is fog
I have also tried setting the group to www-data
[url=“/_imported_xf_attachments/1/1726_mount attempt.PNG?:”]mount attempt.PNG[/url]
The image files are all there right sizes and all.
exportfs -a gave a bunch of errors
[url=“/_imported_xf_attachments/1/1725_exportfs -a.PNG?:”]exportfs -a.PNG[/url]
I also get this error when I try to start a job with an image that worked fine with 1.2
I made sure all the options in the image management are the same as they were before and all that jazz.
I also tried the mounting again with just mounting in one command and got a wrong fs type, bad option, bad superblock error.
Screenshots attached.
Thanks again for all the help.
[url=“/_imported_xf_attachments/1/1723_job from fog.PNG?:”]job from fog.PNG[/url][url=“/_imported_xf_attachments/1/1724_tried again.PNG?:”]tried again.PNG[/url]
I am having a similar problem so I tried mounting on another computer. I attached a screenshot of the output.
It said permission denied, so I tried with sudo and it says only root can do that.
Thoughts?
[url=“/_imported_xf_attachments/1/1722_mount fail.PNG?:”]mount fail.PNG[/url]
Thanks, I just tried that, but I noticed the same problem in another thread where someone is having the same problem, and where you told them to try the same thing. So I’m going to post the results over there
[url]http://fogproject.org/forum/threads/problem-with-permission-denied-after-fog-server-restart.12503/[/url]
Gotta help keep the forum organized and what not right. I’ll post here again if I here back about whether or not option 43 was touched by someone else.
Thanks again for all the help.
Well after updating to the latest svn and watching and monitoring the packets as the mtftp thing took 10 minutes on a vm and then restarting the server, the 8000 elites magically started working again and it looks like VMs too.
Maybe option 43 was enabled somewhere I don’t have control over, it’s a common model in the college and some people using the same dhcp server use landesk for their imaging, maybe they were trying something with that. I’ll ask around, I don’t like magical solutions to problems other people might be looking for answers too.
Maybe I just had to let the mtftp run it’s course a few times?
As for VOIP, that does exist on our network, lots of ip phones, but it’s never caused a problem before.
Now I am having a new problem though. The answers probably somewhere else in these forums though. I’m now getting a can’t mount nfs error. Probably to do with updating FOG versions, oh and by the by I really like the new interface and I’m excited to try out this mac os X image option. But first I gotta solve this NFS not mounting thing.
Thanks for all your help. I love these FOG forums, so very helpful all the time.
-JJ
Oh yeah, I knew that about the packet size. I just haven’t used wireshark in a while, how silly of me.
I had left the packet capture on and noticed that there was some more tftp traffic about 10 minutes after the tftp abort.
It transfers 203 blocks one packet at a time and then send default.ipxe.
Since I wasn’t monitoring it when this happened I don’t know if that means it eventually did get to the boot screen.
So I started an upload task and stayed and watched this time.
It seems it does boot into it, yay! But it takes an extra 10 minutes on VM’s and the HP 8000 elite. And there’s the annoying proxy dhcp issue on the 8000 elite as well.
I’m not sure I’d quite call this resolved though, but I suppose having to wait an extra 10 minutes isn’t that big of a deal.
Thanks,
-JJ
It didn’t make a difference. =(
I’m trying the latest svn to see if it makes a difference. And I’ll try pointing the filename to undionly.kpxe instead
I did the wireshark thing it showed tftp being aborted with error code 59, which is of course undefined in wireshark.
I attached some screenshots to help visualize the problem and the tools I have to work with…
fyi
mefog is the hostname of the fog server and the ip is 10.2.114.238
10.2.114.174 is the ip of the vm I’m trying to boot to pxe.
Thanks again,
-JJ
[url=“/_imported_xf_attachments/1/1706_dhcp options.PNG?:”]dhcp options.PNG[/url][url=“/_imported_xf_attachments/1/1705_dhcp entry.PNG?:”]dhcp entry.PNG[/url][url=“/_imported_xf_attachments/1/1707_mtftp.PNG?:”]mtftp.PNG[/url][url=“/_imported_xf_attachments/1/1708_wireshark.PNG?:”]wireshark.PNG[/url]
@Uncle Frank - Like turn on wireshark on the computer that is hosting the vm and then monitor it?
@Tom Elliott - The DHCP server isn’t something I have much control over. I know it’s on a linux machine and I can make host specific options for next-server and filename. It’s managed by the college that my department is in.
I read something about option 43 relating to this, but I don’t know if that’s s something I can change.[url]http://scug.be/sccm/2011/01/13/configmgr-2007-pxe-boot-amp-mtftp-defaulting-and-make-you-wait-for-10-15-minutes/[/url]
The only thing that has changed is that the port the FOG server is on got upgraded to gigabit, so it may be going to a different switch in the upper infrastructure than it did before. But if that was the problem I would imagine that it would be on more than just 2 specific models that the problem would occur. Though I did read something about portfast needing to be enabled on the switch level, but I can’t find where that was again.
Another related problem that may be of help that only seems to apply to the 8000 elites. Before, when I had a new computer that wasn’t registered in fog, nor having a reserved ip address on the dhcp server, if I booted to network on the same switch as the fog server the dnsmasq proxy dhcp would get it to boot to fog no problem. Now, only on this one computer model that we have a ton of, it gives a a error that says something to the effect of “No proxy dhcp requests were received” And then something about port 4011. I’ll try and recreate the error later when I have the time to put up the exact message.
Thanks for all the help, I really appreciate it.
Thanks,
-JJ
The 8000 elite is about 4 years old, it doesn’t support uefi, I just double checked and I have the vm set to legacy mode.
Or, are you saying that UEFI iPxe boot is working in the latest svn?
So, just a few weeks ago, I had no problems pxe booting into fog on vmware workstation VMs and HP Elite 8000 workstations. In the last week or two they all suddenly stopped booting to pxe. It will get an ip and all that jazz but then it says MTFTP… and then sits there until it times out.
I played with my dnsmasq settings a little with no change.
They all have next-server and filename options set on the DHCP server and are added in fog. They worked fine before, what could have changed that would have caused this. Maybe a linux update?
Every other model computer we use boots to pxe just fine, even in different buildings, so that makes it a bit more confusing that just this one model and VMs don’t work.
Any help would be wonderful.
Thanks,
-JJ
Oh and other general info
Fog is running on ubuntu server 14.04 x64
apache web server
version 1.20 (I am not opposed to a svn release if there’s one that might fix this problem)
It’s Windows 8.1, not sure what ISD is. Is there a way to get around that so that it starts right away?
When I deploy a snapin with a sfx.exe it sends the file and extracts the archive to the appropriate folder, but then it doesn’t run the command.
I’m trying to deploy the snapins on domain computers with only non admin accounts. I use a program called runasspc to run the installers as admin while normal users are logged on. When I test the sfx on a domain account it works flawlessly. But not when it’s deployed from fog.
Let me break it down.
For my snapins I use the sfx method
I put the following into a 7zip archive.
runasspc.exe,
crypt.spc, (encrypted file with admin username/password that points to the script),
and the install script (calls the net use to connect to the samba, the installer from the samba server, unmounts the net use, and then deletes itself and its directory)
I then make a sfx.exe with sfx maker as is described [URL=‘http://fogproject.org/forum/threads/how-to-make-a-simple-snapin-start-to-finish.304/’]here[/URL]
In the Sfx I have a task that runs the script through the runasspc.exe and it’s encrypted credentials.
Hopefully that’s not too hard to follow and someone can help me see what I’m doing wrong. I’ve looked at many other forum posts but didn’t find anything that helped.
Thanks,
-JJ
I’m not a big fan of the username and password in scripts either, but then I discovered a command to make the script delete itself and its containing directory at the end of the script. Just add this to the end
cd …
rmdir .\dir /S /Q & exit
or to delete just the script try this
del /f/q “%~0” | exit
Hope that helps
Sadly That didn’t do the trick. I’m not sure if it did this before I did this or not, but when I start a task with instant deployment it does have the right time. But it still thinks 10 minutes from that time is in the past.