After the SVN update, there is now a new option for placing a plain-text password that will auto-encrypt. The problem was, my encrypted password before the update was placed in the new plain-text field. I just repopulated a new encrypted PW, placed it in the legacy field and that did the trick.

Cheers!
Tim

@giolnl said:

I made some tests with a “forced” configuration (meaning I actually bypassed the GUI of OMV) and everything worked

Not forced, simply a manual configuration. 🙂

The OS doesn’t care what the GUI says. The OS is going to read the /etc/exports file for exports, that’s how it works. 🙂

@Junkhacker I had multiple hard drives I was trying to image at once and once this issue started popping up I actually did switch to re sizable but it was still having that issue strangely.

IMHO this was not related to permissions as you see that pretty much all files and directories already had 777 mask.

Please help us with some more information about your system. FOG version, disk layout, operating system(s) on the client, image type (resizeable?)

This command might help you finding out what kernels you have:

$ file /var/www/fog/service/ipxe/bzImage* /var/www/fog/service/ipxe/bzImage: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:44 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA /var/www/fog/service/ipxe/bzImage32: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:56 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA

This output is on a 1.2.0 test install on my laptop. So I guess 1.2.0 came with 3.15.6

@Wayne-Workman

Model: Whitebox ASrock MB, Core i5 CPU
Winodws 7 Sp1 x64
MBR
Image: I installed from a Microsoft SA Win7sp1x64 downloaded ISO.
When I hit DEL BIOS starts in UEFI Setup Utility.
The SSD was operating in AHCI mode. The new HDD is the same.

@sudburr

I’m not taking images for distribution. I install a machine, install the OS, and install that particular users software. I then take an image of the machine in case there’s a virus or hard drive crash. I haven’t gotten to distributions yet, although that is my next step.

@Tom-Elliott OK. This makes sense. Thank you for the info!

Verified that it is working. Thanks Tom!

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

Particularly, kernel updates use the FOG_TFTP_FTP_USERNAME and FOG_TFTP_FTP_PASSWORD fields. Check that these match the linux username and password you use for the fog server. Most times this is “fog” and a random password (in 1.2.0 was 6 digits).

@Uncle-Frank SWEET! It was the firewall. I’m now able to boot into Fog. Thank you very very much!!!

I have solved this thread because as @Junkhacker stated, this is fixed in the dev builds as I am not using gzip compression on the page at all any more. If you are worried about the display, please update to Dev.

@Wayne-Workman - FOG 1.2.0 running on Ubuntu 12.04 LTS. The drive did fail during normal operation - i.e. after running for several days, it got suddenly disconnected, I’m almost sure it’s a hardware issue (either the drive itself or the SATA controller). After reboot it mounts normally and the images resync on the other node.

Well, there is a lot of guesswork involved as we are not sitting in front of the machine. But you could help us to help you by capturing a packet dump on your FOG server. Fire up this on your server tcpdump -i eth0 -w pxeboot.pcap udp and let it sit there while you are getting up that machine causing the issue. As soon as you see the error hit CTRL+C to stop tcpdump and upload the PCAP-file to the forum here.

@EAHarvey said:

@Wayne-Workman So you’re talking about when i initially upload the image correct?

Not really. I’m talking about you creating your own task type. To be honest I’ve not used this plugin yet, but I’m fairly sure it’s possible to do what I’ve described.

@hlcstudy I’d say - dont delete any of the images manually.

The web interface can delete files via FTP for you. You have to click on the actual image you want to delete first. then on the left in it’s menu, at the bottom, you’ll see “Delete”. You also have to check a checkbox to confirm you want to delete the image AND it’s data.

Errors (or warnings as the case is here) does not mean anything in particular. I’m adding checking to return if the value is true, and throwing an error if the value is false. If the error is thrown, it also returns false. My guess is this is specific to when you’re inserting, or updating, and entry and this is why you’re seeing this error. I’ve added, as I stated earlier, a better check mechanism so it will simply return if the value is true and not attempt iterating over a boolean value.

4806 Should have this ready and working for you.

@tecnomuzik Your suspicion with the 5 minute upload along with @Uncle-Frank 's is correct. It normally takes two to five times longer to upload an image - depending on compression settings.

Best would be to hook the client to a hub and capture traffic from there.

Second best if you can capture TFTP-DHCP and FOG-server at the same time. I should be able to “synchronize” those two dump files by looking at the broadcast packets.

And as a quick try you might just capture on the TFTP-DHCP server. Hopefully I am able to make the missing packets up myself.

Useful tcpdump options:

-i eth0 capture interface, change to suit your needs -w outfile.pcap write packets to PCAP file (you won’t see the packets while capturing!) As last parameter you can add capture filters but this is quite tricky when it comes to PXE boot and DHCP (several different protocols and ports). You can simply use udp as a filter or not port 22 to keep your SSH session out of the way. Sometimes host x.x.x.x is also great but not in this case here.