Mounting File System Failed



  • My fog server (CentOS 7, FOG 1.2(5307)
    running on VMWare
    DHCP server is Server2012 on another VM

    I can register hosts (tried on an old Dell Inspiron 1525 (win10) and also Asus N61 (Win8)
    After scheduling a capture tasks the Host starts doing its thing untill the error above appears.
    I have tried changing what sort of image is captured etc.
    Same error on both Host machines…

    Mounting File System Failed
    Failed to mount NFS

    Its not this:
    https://forums.fogproject.org/topic/4955/fatal-error-failed-to-mount-nfs-volume

    Tried this: (My /etc/exports file was totally empty) -is that normal ?
    https://wiki.fogproject.org/wiki/index.php/Image_Upload:_Error_Checking_Mount

    The size of my VM image disk size was set to 50GB I think when I created it, I thought space may have been an issue so thats why I tried to change the image capture to partition table and MBR etc. I was thinking these might be smaller images and so test if disk space was an issue.



  • After capturing images from multiple machines, it looks like this issue is due to an incompatible BIOS in these old Dell machines.
    I guess this issue can be marked solved…
    Thanks for your help everyone



  • @george1421 As am I. This is a crappy old Inspiron 9400 that should really go in the bin because it is so slow, but Ill have to keep it until I get approval for a some newer (used) machines.
    -Just tested an Inspiron 6400 from the same era (looks pretty much the same but 15") Same deal.
    -Just tested a newer Inspiron 1720 and it works fine.

    The BIOS versions have probably never been updated…not sure if its worth it, but I could do it for education sake.


  • Moderator

    @Rusty It would be interesting to know if this computer’s bios is up to date. From Wayne’s suggestion, it would be great to know what SVN worked so then we could go back to the devs and say what’s different between then and now, why did this stop working? I’m still leaning towards the hardware on this issue though.


  • Moderator

    @Rusty said:

    Actually the first instance of FOG I got going (Thanks @Wayne-Workman ) DID work with this machine, and I never saw an instance of this problem.

    If you can get a date for that, it would help out. We can install that old version and see what happens.



  • @george1421 No they are not the same, I do have another one the same as the problem one I think, Ill try that when I find it and its available. We have a high mix of different machines here, mostly Dell though.

    Actually the first instance of FOG I got going (Thanks @Wayne-Workman ) DID work with this machine, and I never saw an instance of this problem. Not exactly sure what version it was, and I just deleted those VMs this morning ;)

    @Wayne-Workman I made the change to undionly.kkpxe still no worky


  • Moderator

    @Rusty said:

    Updating to SVN 4367 didn’t help with this Dell Inspiron I have here. The second laptop I have here boots into FOG menu everytime.

    Not to fork this thread, but just so I can get this clear in my head.

    You have two computers that are exactly alike. They are the same models, with the same bios release and the same bios settings. But one boots to the fog menu and the other hangs at the init devices?

    Have you tried to reset the bios back to defaults on the one that doesn’t work, save and reboot, then make any changes necessary for your image (uefi, legacy, roms, etc.) save then pxe boot. If it still hangs. Power it off, remove the battery and charging cable. Then power everything back up. If it still hangs then I might consider the mobo has issues. There may be a way (kernel parameter) that the developers can set to tell exactly where its hanging.


  • Moderator

    @Rusty try undionly.kkpxe



  • Updating to SVN 4367 didn’t help with this Dell Inspiron I have here. The second laptop I have here boots into FOG menu everytime.


  • Moderator

    @Rusty Some systems will try to do a two way match between conical name->IP address -> conical name. This is a standard function of DNS. I’m kind of surprised that this issue (not having a reverse lookup zone) hasn’t been a problem.


  • Moderator

    @Rusty Trade out patch cables, if you have more than one of these problematic dells I would suggest trying with another just to see what happens.

    Are you using a managed switch?
    Are DHCP Helper addresses set on the managed switch?
    Is portfast enabled on the managed switch?

    What if you created a reverse lookup zone and it worked more reliably?

    A lot of things use PTR records. There’s no conformity. Printers sometimes, computers finding printers, computers with IP printers installed and drivers that want to use the FQDN, some client / server software uses PTR records. the list goes on.

    I wouldn’t be surprised at all if the firmware on the device you’re using is trying to querry for the PTR record just to fill some internal system variable (whether it’s used or not).

    as @george1421 said, it is good practice to have a reverse lookup zone. More stuff will work and you’ll have less mysteries.



  • @george1421 Ok. So this isn’t contributing to my issues*?

    Also excuse my ignorance, why should I add the reverse DNS lookup zone ? (what does it do for me practically?)

    Thanks !

    *Its possible there is a compatibility issue with the notebook I was using to image. I grabbed another old Dell and it seems to work everytime. I swapped back and Dell1 didnt work with several attempts, back to Dell2 and It is working 100%.


  • Moderator

    @Rusty said:

    Anything need to be backed up/recorded etc ?

    If it’s virtualized, I recommend taking a snapshot before updating Trunk versions of fog.

    If it’s not virtualized (and a production server), do a DB export (FOG Configuration -> Configuration Save -> Export) and a Host export (Host Management -> Export hosts -> Export) at minimum. Append the file names with the SVN version you’re using.

    IF you decided to blast away the current build you have and start over, copy your images and grab a copy of /opt/fog because it has your SSL keys in it.


  • Moderator

    Not to send you down a rabbit hole here, but I take it you don’t have a reverse lookup zone created for your DNS server. Because looking at the capture its looking for the 10.0.0.51 address but the reply from DNS is name not found. Can I guess that 10.0.0.51 is your FOG server? Outside of the scope of this project you should ensure you have a reverse lookup zone created in DNS.

    Here is a how to for 2012. http://www.tomshardware.com/faq/id-1954333/create-reverse-primary-dns-zone-windows-server-2012.html


  • Moderator

    yes after you do the svn up then cd to the bin folder and run setup again.



  • after updating SVN, I re-run the installer ?
    Anything need to be backed up/recorded etc ?



  • @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 :)


  • Moderator

    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.



  • 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)



  • @Wayne-Workman Sure, whats a PTR record?

    1_1447713018096_329.png 0_1447713018095_328.png


Log in to reply
 

710
Online

39.3k
Users

11.0k
Topics

104.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.