Unable to Mount NFS
-
A thought. Could the names of the NFS services be the root cause of all of this nonsense? The proper terms for my fresh install were nfs-common and nfs-kernel-server as opposed to nfs-common.dpkg-new and nfs-kernel-server.dpkg-new. Portmapper is running, mountd is running, there is no firewall, the config files seem fine. There is no other differences I can spot between my home server install and the one at work.
-
It’s possible, I’m assuming your home server you’re using Debian 7 as well?
-
Yes, that’s why I chose to put it there. It’s not being used for anything else, but is already configured so it was just a matter of downloading and installing FOG. Of course there is a firewall and one of these new Motorola Surfboard modem/router combo deals on the network which will make any PXE booting attempt a pain. So I’ll still create the second VM just in case and rename those files come Tuesday.
-
I have a motorola Surfboard Modem on my network and have yet to have any issues pxe booting. It listens for tftp yes, but only from the isp, not my network as the specifics it’s looking for is unavailable on my network.
-
Hmmm maybe I’ll give it a shot. I just can’t stop thinking about this but don’t want to go into work on a Saturday.
-
All perfectly understandable. I don’t expect you to go to work on a saturday, but if you work at home on your own systems, you might come up with a workable procedure for yourself when you finally do get back to work.
-
A fresh install did the trick. I am in the process of imaging my desktop PC. For some reason it would only work if I set the OS to be windows 7 (it runs 8.1) and multiple partitions. However it is currently working. The only problem is my laptop refuses to connect to the internet which has forced me to write this from a cellphone. But that is a temporary problem. Over the next two days I will recreate the fog server in a virtual machine on my laptop in case renaming the NFS services does not help.
-
In regards to the test machine at work, renaming the services corrected the issue. I was able to start the imaging process. Unfortunately I could not finish because it is necessary to repartition the virtual hard drive to make more space which might require some doing. I have but two questions:
1. Why do active tasks always display as “queued” until finished?
2. For some reason pressing * does not cancel an image upload in progress. -
If the image type is not single-partition, resizable, the base FOG code does not update the task status until it finishes. There is a quick code change that will enable showing of progress for multiple partition, single disk images.
I don’t think the code is in place yet to show progress on upload tasks either.
-
chad,
progress does get displayed now, on all imaging tasks.
-
What sort of code change are we talking about? The feature would be nice, but is not critical.