Mounting File System Failed
-
Then maybe permissions? Can you run
chmod -R 777 /images -
-
@Tom-Elliott no go. What is actually happening in this part of the upload process ?
@Wayne-Workman thanks, I hadn’t come accross that one yet -
Following this guide:
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFSI keep getting FOGFTP: Login failed.
username: fog, Password: xxx
Error: ftp_login(): Login incorrectI found tftp_ftp username and password in fog settings. So I changed it to xxx (it was a different generated one) but it still doesnt work.
I have tried logging into ftp with an external ftp client from my VM host machine, and it gets password rejected.
Can I test it this way and how do I change the password ?I chec
-
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP
I’m full of links tonight
There is a section in there on credentials, that’s what you’re looking for.But I am not fully understanding why you are getting errors about FTP, nothing in that NFS troubleshooting article below uses FTP. That error usually happens at the end of a image capture attempt. Or, if you’re just trying to log into your server using invalid ftp credentials.
-
@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…
