Sometimes you just feel a little slow on the uptake. I put the pieces together and realized something. In the wiki entry on using FOG with FreeNAS, the instruction is to create 2 separate datasets --> images and images/dev. This is what sets up the different mount points that gives a problem with ftp in FreeNAS.

I deleted the 2nd dataset from FreeNAS and then went into the shell in FreeNAS to recreate the dev directory under images. I recreated the .mntcheck file and set the permissions for the FOG user. The rename of a directory from the windows ftp client now works to rename from images/dev/test to images/test so now the FOG image should work.

Would someone please update the wiki to not create 2 datasets, please?

Here is the test result I have come up with so far.

Windows ftp client to FOG server running Ubuntu:
I can successfully issue a rename command to move a directory from images/dev to images.
It looks like the windows ftp client work that as RNFR / RNTO

ftp> rename /images/dev/00142240c820 /images/0014test
350 Ready for RNTO.
250 Rename successful.

The same thing connecting to the FreeNAS server gives the error initially noted.

ftp> rename /images/dev/004045363e48/ /images/TEST/
350 File or directory exists, ready for destination name
550 Rename /images/TEST/: Is a directory

On the FreeNAS I can rename a directory as long as I am moving it within the same parent directory.

ftp> rename TEST TST2
350 File or directory exists, ready for destination name
250 Rename successful

The ProFTPD document I listed initially does state at the bottom that you cannot move directories across mount points. That would indicate that the only way to get FOG to work with FreeNAS to do this would be to move the files one at a time.

I don’t know if that would ever be implemented. I don’t know if there are enough people that really need it to make that happen. For now I will just go back and grow the vm disk.

George-
Our fog server is a vm and we are looking at using nfs storage rather than having to grow the vmdk on the vm or spinning up another vm to be a storage node. And sometimes you start down a path and find an obstacle and you just can’t leave it alone until you solve it.

Tom-
I’m not sure what the command would be but I can run some tests if you’ll help me out. I can’t tell exactly what you’re sending now to move the directory currently. It’s been a while since I’ve done much with ftp commands but a little nudge should clear things up. Here is the page I found on proftpd supported commands:
ProFTPD supported commands

I’ll start checking into the proftpd.conf file to see if there are any items that could be changed there to allow better compatibility and maybe turn on some tracing.

Server

• FOG Version: Running Version 1.3.5
  SVN Revision: 6067
• OS: Ubuntu 14.04 LTS

Client

• Service Version: N/A
• OS:

Description

So I have read the wiki entry on Troublshooting FTP and the posts and wiki on using FreeNAS with FOG. The last part of the FreeNAS wiki describes how the rename does not work and you have to manually move the image from dev to the actual image folder.
Using FOG with FreeNAS
Troublshooting FTP

The files are uploaded and then stuck in the dev folder. I looked into the problem from the FreeNAS side of things since I did not see much on here about it. I am running FreeNAS-9.10-STABLE. This appears in the log (xferlog)

Apr  4 12:02:09 FreeNAS01 proftpd[76187]: 127.0.0.1 (10.132.7.25[10.132.7.25]) - FTP session opened.
Apr  4 12:02:09 FreeNAS01 proftpd[76187]: 127.0.0.1 (10.132.7.25[10.132.7.25]) - USER FOG: Login successful.
Apr  4 12:02:09 FreeNAS01 proftpd[76187]: 127.0.0.1 (10.132.7.25[10.132.7.25]) - warning: cannot copy source '/images/dev/004045363e48': Is a directory
Apr  4 12:02:09 FreeNAS01 proftpd[76187]: 127.0.0.1 (10.132.7.25[10.132.7.25]) - FTP session closed.

So it looks like fog wants to move the whole directory but the ftp server in FreeNAS (proftpd) does not support that. If that is the case, is this the missing link that would allow someone to make fog work with FreeNAS - changing the ftp commands that move the files from dev?

Laptop model is Itronix XR-1
We successfully imaged these with our old Fog 0.32 installation. After replacing that with a fresh 1.2.0 Fog installation, we have found that these no longer will boot correctly. Other laptops and PCs are working well with the new Fog server.

I took a video of the boot process to troubleshoot this and can offer the following:
Onboard PXE Boot agent shows as “Argon PXE Boot Agent v2.00 (BIOS Integrated)”
It gets DHCP options OK and connects to the TFTP service.
It shows “iPXE initialising devices…ok” followed by “iPXE 1.0.0+ (3a02)” banner and list of features. Then:
[CODE]Configuring (net0 <MAC addr>)… ok
/default.ipxe… ok
[URL]http://<fog[/URL] server>/fog/service/ipxe/boot.php… ok
[URL]http://<fog[/URL] server>/fog/service/ipxe/bg.png… ok[/CODE]

That is the last successful statement. The screen clears and shows an error message about I/O error:
[CODE]Could not configure console: Input/output error (http://ipxe.org/1d8c2139)[/CODE]
which according to ipxe.org is a vesa frame buffer problem. That makes sense since the next thing should be for the menu to display. It is not yet to the point of trying to load a kernel, is it?

We tried the solution from the knowledgebase for non-PXE compatible cards using the boot cd from etherboot.org but got the same result.

I tried changing the DHCP option 67 to point back to different boot files other than undionly.kpxe but no luck. The closest I came to success was using a pxelinux.0.old that I found in the tftpboot directory but had no pxelinux.cfg to tell it what to do next.

I am trying to work through some of the other things on the wiki but many of them are relevant to the older Fog versions using the pxelinux.0

We hopefully won’t have these older laptops much longer but I guess I will have to spend a little more time trying to troubleshoot this. Can I just add a pxelinux.cfg file somewhere and segregate these few machines with their separate DHCP option to boot pxelinux.0 instead of undionly.pxe or is there something else that I could try?

Thanks for the correction, Tom. I had seen a reference to what was used but could not remember off hand.

The second laptop is working much better to pull an image and I am breathing a little easier now. Would still like to know about the questions I raised.

Are the logs / results from partimage available anywhere? Is the next version of fog .33 more aware of problems like this or can it be added at some point down the road?

There are a couple of points I am trying to address in this post so please bear with me. I am running fog .32 on ubutnu 11.04.

I am trying to upload a Win7 image from one of our laptops. I thought I had captured this image previously but what was on the fog server was corrupt and now I think I know why. The previous image was done from a different laptop which I do not have right now. I am having to try to redo this image from a second laptop. I watched this upload closer and saw partway through the main partition that there were several read errors after a few minutes. The image process then went on to the next partition and seemed to complete normally but I know there were errors.

This is my first point. Why don’t I get notification that there was an error during the process? Is there a log to look at somewhere that would have a record of these errors that are being shown durning the process?

So I went back into Windows and scheduled a complete chkdsk of drive c which was the partition that failed. It found some bad blocks in 1 file and repaired the file (according to chkdsk). Free space was checked and found no errors. The drive was defragged.

Feeleing that I had found and fixed the problem, I started another updload. Same problem but much later into the image. I had plenty of space in the /images folder but decided to increase the space anyway and see if a fresh boot of the fog server and more space would help. (fog is running on vmware esxi / vsphere 4 - no problems expanding the partition).

Fresh boot and new upload - same problem. DRDY error, problem reading /dev/sda3.
Is the imaging util (partclone?) more susceptible to errors than chkdsk? Could a different kernel image make a difference?

[edit to add - I have found another laptop that I can hopefully use to recover an image but would like to find out about these issues still]

Thanks for the quick reply. The wired / wireless was the initial problem until I approved the pending MAC. After approving the pending MAC I did get a couple of entries written to the database for the laptop over the wireless connection. I can see in the fog.log that it is using the MAC of the wireless adapter and finding the host entry. The problem is in the login history that is supposed to be kept for upload if the computer is offline.

From [url]http://www.fogproject.org/wiki/index.php/Managing_FOG#Functions_and_Operation[/url]
[QUOTE]User Tracker
This module attempts to track user access to the host computer by the Windows user name. It attempts to track logins and logoffs as well as well as the state of the computer at service startup. The service will even attempt to track users when they are not on the network by writing all entries to a journal file, then replying the journal the next time the client is on the network.
There are no configuration settings for this module.[/QUOTE]

Where is the journal file kept? If it is not being created, how do I troubleshoot? Why did it not upload when I did connect since I now know that other entries were created once I was online?

According to the wiki, the user tracker is supposed to write login / logoff data to a journal if the computer is offline and then upload this journal to the fog server when it comes online. I was trying to troubleshoot this with Windows 7 client this morning since I was not getting many entries in the logs. I would get local administrator and our tech staff logged when the laptops were imaged but not much after that.

I discovered the pending MAC entries for the wireless cards on the laptops and approved those. I looked at the entries in the c:\fog.log file and there were some errors but they seemed to go away after I applied the pending MAC. I still could not get entries in the login history. I tried rebooting the laptop and loging in and out.

I finally did a restart of the fog service after logging in and got an entry in the login history for service start and my username. It did not write any past history from the journal that is supposed to be kept for offline entries. I then did a shutodown on the laptop and the servier showed the entry in login history for my user logging off.

Can anyone help me with troubleshooting the lack of history?
Running fog 0.32 on Ubuntu