/mnt/pools/A/A0/images is the directory on his NAS. You should still mount it to /images.
To be clear, if you have the drive mounted correctly without any other changes, to /images , the FOG Dashboard should show the correct disk information. I really do believe that the mount is correct, and the problem is with the client not having correct permissions.
I feel like the issue is the client not having read/write permissions on the NAS. Like you said, the FOG system has permissions, and the mount is fine. I am fairly sure that it is not a problem with the NAS, as (mine at least) has no password required, and guest access to read and write enabled, and the export has No_root_squash which should allow non-root to have full permissions.
I have a feeling that there is a password field or setting in FOG that is being over looked.
I also didn’t get a chance to build from scratch today. I don’t want to take down the FOG system I have because it is in production and the system I was going to use has a hardware failure. When I get my parts in, I’ll try again, using these directions:
[url]http://fogproject.org/forum/threads/request-fog-nas-tutorial.419/[/url]
For your /images and /images/dev folder it looks like you have the ownership of root, when it should be (according to the above thread) fog.
The only comment I can make at the moment is that you are not alone in this problem.
[url]http://fogproject.org/forum/threads/fog-server-fatal-error-failed-to-mount-nfs-volume.115/[/url]
I’m about to wipe my systems and start from scratch to see if I can figure this out today.
Any update on this? We’ve got some Win 7 units that have no trouble making images, but will not deploy.
HP units have a hidden partition for their recovery… it seems that this causes problems with images. In my shop, I haven’t finished an HP image because on a fresh restore (maybe 40GB used on drive), I haven’t seen an image filesize smaller than 220GB.
I will look into those again. I looked through them while doing this though. The permissions used from the first link are more inclusive than the permissions from the second link. I didn’t notice that before, but I tried adding those as well just now, and no change.
Here is a text dump of what shows on the unit that I am trying to upload an image from.
[CODE]* Send method…NFS
##############################################################
Fatal Error: Failed to mount NFS Volume.
##############################################################
##############################################################[/CODE]
Should be noted that 192.168.15.72 is my FOG server. 192.168.15.15 is my FreeNAS box with the storage and /image file. I know the store mounts correctly because I can see it in Ubuntu and I have full permissions to read/write/execute on it.
Bumping this thread because I have the same problem. mntcheck files are there, ubuntu system can see the mount and can write to/read from it.
I’ve using a FreeNAS system with a NFS share, authorized network set to 192.168.16.0/24 (my local subnet). All directories box checked, mapall user set to root.
When I try to pull an image, it does exactly what the OP says. Stuff about permissions. I’ve chmoded /images on the ubuntu box (mounted from my FreeNAS). Is it possible that I need to change the permissions on the FreeNAS system somewhere? I’m out of ideas and google hasn’t been of much help anymore for this roadblock.
Been a busy few weeks, haven’t gotten a chance to play with this in awhile. But, yesterday, I did.
I loaded up an Alienware M17xR4 to make an image and happened to glance at it while it was pushing along… at 4.5GiB/min… That made me pretty happy, so I grabbed another one once it was done and loaded up 2 of them, pulling an image, they [I]both[/I] were reporting ~4.2GiB/min pulling from the FOG machine. The FOG homepage showed about 80MB/s of traffic, but it was all over the graph, where with the previous Dell units it would hit 700MiB/s and stay pretty flat.
So, I think that proves that my issue is related to the Dell units (N5110) or perhaps the stock kernel. I haven’t touched any of the kernel related stuff yet, but I think that is my next move.
Oh, also as a note while I was messing around with the Alienwares, I tried starting up one of the N5110 that I test with and as soon as the Dell connects, it slows the bzimage loading. When the Dell is pulling an image (at 700MiB/min) and I try to start an Alienware, it loads the bzimage slowly. If I pause the Dell imaging, the Alienware loading the bzimage takes off and goes it’s normal speed. Then if I unpause the Dell, both with go their respective speeds (Dell 700MiB/min, Alienware 4.2GiB/min). Thoughts?
[quote=“chad-bisd, post: 8373, member: 18”]You may be getting 100mb speeds due to the network driver in the FOG kernel (/tftpboot/fog/kernel/bzImage). Have you tried a newer kernel? Sometimes older kernels work also. You might try debug mode imaging and see if you can mount the nfs share and transfer a file. If it’s limiting to 100mb in debug mode, it’s probably the kernel module driver for the network interface.
In my FOG setup, I’m using 6 disks in a raid 5 array and gigabit switches and I get almost 4GB per minute on 4 computers imaging at the same time. With 10 going, I get about 2GB/min. I start to get limited by the disk throughput before the network throughput.[/quote]
I will try that after lunch, thanks.
In the past, using Ghost, we saw about 400MiB/min, so anything over that is an improvement. 4GB/min would be amazing. We reimage around 50 units a day, but not at the same time and a queue is not a problem, so those are hopeful numbers.
I started this project without a full understanding of how FOG is intended to be deployed. Our old network used Lacie NAS boxes that eventually crapped out under constant and heavy load (and thunderstorms). To start the replacement, I built a FreeNAS system that started with a RAID-Z2 array (8 * 2TB). It was supposed to end with three such arrays in the same box, and function with our Ghost system in place. We decided that there should be a replacement to Ghost as well, so then I got involved with setting up the FOG system. After recently reading about nodes, it seems like this might be a better way for us to go about things. Multicasting is not an option, and with Capone working so nicely, I don’t want to bother with it. Meaning that unicast performance is paramount in importance, so throttled at 100MBit is too slow to really be of use. The future may also hold some form of Link Bonding as well, but that’s for another thread.
[quote=“chad-bisd, post: 8330, member: 18”]Bring up a Linux box, liveCd will be fine. Mount the NSF share from fog server onto the client and pull and image file over. If you get 100mb speeds then it’s not fog.[/quote]
Tried this with a HP Touchsmart tm2. It jumped around a lot, but pulling the N5110 image over the network went well over 100Mbit at times. So now the question is, what in FOG is artificially limiting me to 100Mbit?
[ATTACH=full]167[/ATTACH]
[url=“/_imported_xf_attachments/0/167_Screenshot-2.png?:”]Screenshot-2.png[/url]
[quote=“chad-bisd, post: 8330, member: 18”]Bring up a Linux box, liveCd will be fine. Mount the NSF share from fog server onto the client and pull and image file over. If you get 100mb speeds then it’s not fog.[/quote]
Good idea, I’ll try that tomorrow when I have access to the machines.
[quote=“djm79, post: 8327, member: 1568”]I had something just like this not even two weeks ago. I ended up running tests from various switches moving further out from the Fog server until I found the offender. It ended up being a access layer switch that someone (cough my boss) went cheap ass on and didn’t buy a GBIC gig adapter for the uplink. So everywhere else had gig uplinks but the access switch for our floor was being jammed into a 10/100 port. Long story short I jumped a gig uplink port from our distro to the setup room to a cheap gig Dlink switch for imaging and bam 2.5 gigs on average. Takes about 5 min to drop a 14 gig image to a computer and as soon as I work out snapins I’ll shave another 5-8 gig off my images and it should be really fast then.[/quote]
That makes sense, I’ve heard horror stories like that.
This is happening in a very closed loop though. FOG server -> Gigabit Switch -> Client. Even FOG -> Client directly has these speeds.
I will try to be as detailed as possible about my issue as I’ve been pulling my hair out for nearly a week now trying to figure this out and I’d [I]really[/I] like to figure this out.
I have FOG 0.32 running on Ubuntu 10.04 with Capone. I can make and deploy images, Capone is working great. However, I can not get the FOG to push more than 100Mbit across the network. If I start one machine it works fine (at roughly 100Mbit - 600-800MiB/min). If I try to start another machine, it takes 15-20 minutes to load the bzimage and init image. If I start two computers at roughly the same time, they will load the init images fairly fast, but then share roughly 100Mbit of traffic. The meter in the FOG portal and the Ubuntu system monitor will both show ~100Mbit of traffic going out. If I try to add a third machine at this point it loads the init images very slowly, as soon as the first two machines are removed, the third will kick up to 100Mbit/s.
[U]Hardware - FOG Machine[/U]
[LIST]
[]PowerSpec S200
[]Intel Dual-core (C2D) @ 2.33GHz
[]2GB of ECC RAM
[]2 - 500GB HDD in RAID 1
[]Dual Intel NICs (currently not used)
[]Intel Pro 1000GT Quad port (PCI-X)
[/LIST]
[U]Test clients[/U]
[LIST]
[]Dell N5110
[]Intel i5 2450
[]4GB RAM
[]1TB HDD
[]Gigabit NIC
[/LIST]
[U]Network[/U]
[LIST]
[]Gigabit switches, mostly crappy, but they have proven to do 2GB/s+ on their backplanes through file transfers
[*]Cat6 only, new for this project
[/LIST]
I have run point to point from the server to the client, through switches, etc, always the same speed, never will go over 100Mbit/s.
I believe I have the current Intel driver for this NIC (e1000), as seen in the screenshot.
Please help before I lose all my hair!
Edit: Image is what I see while imaging one computer, this was taken about five minutes after it started. The CPU jumps around a bit, but does not go over ~40% even with three computers trying to image.
[ATTACH=full]165[/ATTACH]
[url=“/_imported_xf_attachments/0/165_Screenshot.png?:”]Screenshot.png[/url]
[quote=“chad-bisd, post: 5533, member: 18”]Capone plugin maybe. Quick register + quick image.
You can also modify FOG if you know a bit of PHP and/or shell scripting. You can make it give you a list of images to choose from when you boot. It’s very customizable.[/quote]
The ghost server we had before would allow you to pick by make, then model. When it worked, it worked very well.
Going one step further, I noticed that FOG can pull systems details. If it could grab the model information, then automatically load the correct image, that would be ideal. I have no idea how to get started with that though.
At my work we use a Ghost/Ghostcast system with a bunch of NAS boxes and use CDs to load WinPE and an image through ghost off a NAS box.
Well, we hate Ghost and would like to find a replacement that actually works the majority of the time.
From what I can tell, FOG looks like the thing that would work the best, however the managment stuff has me a bit confused. FOG seems to be designed to manage a large network of systems that stick around for awhile. My need is only to make images, and push images to systems once, then they leave the network. I do not need or want to have to reg each unit on the network, as that would be a lot of wasted time in my workflow.
So before I spend a day setting this up, is it possible to use FOG just to; Network boot->MakeImage/RestoreImage, without any reg of MAC addresses or hostnames, etc?