Mounting File System Failed
-
@Wayne-Workman Hmm strange then…
I get that ftp error at this point in the troubleshooting NFS page
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFS#Testing_NFSecho ‘This is the text I use to test with.’ > /images/test.txt
-Create deploy task
-Choose Schedule as debug task
–Click “Create*”I also can’t get to a command line on the client(host?) PC in the boot menu to get to the next part:
"At the client, if it did not WOL, turn it on. After the client shows options on the screen, you can press [enter] to be given a command prompt. " -
@Rusty Then that is definitely an FTP related issue. The article just below on FTP can walk you through correcting the FTP credentials issue. If you can’t schedule a task, then you wouldn’t be able to get anything on a host.
Also, you said in your OP that the /etc/exports file was empty. That’s pretty concerning. Can you try to re-run the installer and see if that helps your /etc/exports to be populated with the right config?
Also, feel free to post your
/opt/fog/.fogsettingsfile with your IP addresses and passwords omitted. -
@Wayne-Workman Thanks, Ill update this thread when I get it solved
-
FTP issue is solved now. I went through the excellent https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP guide and changed the FOG OS user account password to match the others (I didn’t think it was different, but it must have been).
This solved the issue where I got stuck in going through the also excellent https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFS. I couldn’t get the images capture though, some other errors I need to work through. I think relating to partitions not in the right state or something like that. -
Thanks for letting us know. Great that the wiki was helpful for you!
If you need further assistance please post the exact error messages you see and we should be able to help you out.
-
Thank you.
Yep when I get to it, I will post what the next errors are. -
I had new issues this time…
I brought my PC with the FOG VM into work (was testing at home) and I had to change the gateway IP and DNS server.
I thought re-running the installer was the best way to do it?
I ran it once or twice before I realised I had to change the router option in the Linux network card settings. Then the installed picked it up.
This is where I was having “tftp connection timed out” issues.
After following this: https://wiki.fogproject.org/wiki/index.php/Tftp_timeout…#Testing_TFTP
and getting to the storage management section and checking the password, I noticed the “interface” was set to “eth0” instead of the strange “eno16777736” that VMWare allocated.
So changing that fixed THAT issue. But why the heck did this issue suddenly appear ? Did the installer change it on me ?No that wasn’t it! after another reboot it it doesn’t work again, still getting “tftp connection timed out”
Tested tftp from another machine OK.
A couple of times now it has downloaded the files quickly and shown the fog menu. Then it won’t work again for the next 20 reboots or so
Some images from wireshark: In between the two images is just the rest of the file transfer
-
Does restarting the tftp service help?
service xinetd restartCheck netstat to see if it is listening on port 69:
netstat -antup | grep ":69" -
@Rusty the intermittent hit-or-miss you’re describing with TFTP suggests that you have more than one DHCP server in your environment and not all of them are configured with options 066 and 067 properly.
-
@Sebastian-Roth
[root@localhost bin]# netstat -antup | grep “:69”
udp 0 0 0.0.0.0:69 0.0.0.0:* 7860/xinetd@Wayne-Workman Funny you say that, last night (after my problems) our old DHCP server was restarted and the DHCP service started again, so this morning we had issues with 2 running.
However that’s fixed now and like yesterday it’s still not working.
Whats the best way to check for other DHCP servers ?
Shouldn’t the Wireshark capture I posted show it? -
@Rusty Do another capture just to be sure.
-
@Wayne-Workman Attaches is the last part of another capture. Just like previous, the PXE gets an ip, immediately downloads undionly.kpxe but then
“iPXE initialising devices”
tftp://10.0.0.51/default.ipxe… <<- This is where you see the ARP broadcasts start again.
After several seconds, it gives up and boots the HDD
-
I did another capture/filter with ip.src==10.0.0.51 || ip.dst==10.0.0.51 for curiosity. This capture is from immediatly after the download of undionly.kpxe to when PXE gives up and boots the HDD.
-
@Rusty Packet 328 and 329 in the last capture you posted looks interesting. It happens again at 559 and 560. What name was it trying to resolve?
Looks like it was trying to find a PTR record for 51.0.0.10 ??? Is that right? Can we see more?
-
What is happening at this stage ?
to get undionly.kpxe tftp needs to have worked ? which means the option66/67 is working on the DHCP server
but now it seems to not be working… -
@Wayne-Workman Sure, whats a PTR record?
-
It just worked again, so I uploaded an image. Then it worked a second time.
Now its not working again (trying about 6 times now) -
A PRT record is a reverse lookup for DNS. Basically it asks DNS for this IP address what is its conical host name.
While I haven’t read this entire thread, for DHCP its best for option 66 to be an IP address and not a conical host name. Some PXE clients are just not that smart enough to know how to look up a name for option 66, so set it to the IP address of the FOG server.
Also I know they have been working on the boot image (in the last 3-4 days) where it was getting stuck at the initialing devices. You may want to try to update to the latest SVN. It sounds like you are almost there.
-
@george1421 Thanks.
My DHCP options use the IP of the fog server, so I’m not sure why that is the case then…OK thanks
-
after updating SVN, I re-run the installer ?
Anything need to be backed up/recorded etc ?
