Posts made by the_duke

@george1421 so could it just be that I need to edit a file that points the /image directory to the other drive? If so, which file do I need to edit?

@george1421 I’m just curious, but why do I need NFS if the storage is local to the fog server? It’s just a 2 TB hard drive installed on the server.

I updated my fog server yesterday. I was on Ubuntu 12.04 and had to do a fresh install of 18.04 and did a fresh install of fog 1.5.8. On my previous setup, I had my OS on a small SSD and my /images was on a 2TB HDD. After I set it up again, the /images folder was on my SSD so I had to move it back to my HDD. The images from my previous fog setup are still on the HDD, but I’m getting the error message "can’t mount /images folder (bin/fog.download). What am I missing?

@Tom-Elliott Yes

@george1421 Ok, figured it out. I didn’t pay close attention to the computer after running chkdsk. It would reboot and try to start, but it would just boot up normal. Tried it on second image and it did actually run the chkdsk on reboot an I was able to capture then. But your right, I couldn’t find much of anything on that error either. When I scanned the drive with chkdsk, I did see an error about incorrect bitmap for a volume so that’s what it was

@george1421 I ran chkdsk and no errors. I also ran diagnostics on the system and no errors. I sysprep’d it and used that shutdown command, still the same error. These are new to us, off lease machines with brand new SSDs installed. So far I’m 0 for 2. I have the same machine with windows 7 installed with HDDs and no problem. I am assuming that I should be using the OS id for windows 10 correct.

What are the file attachment size limits again?

First off it gets through a 900MB partition and just sits there for 5 mins, then it starts to go forward. It goes to reading super block and calculating bit map…please wait…ntfsclone-ng.c: used blocks count mismatch: 8232062 in header, 8232063 from readbitmap.

I haven’t run sysyprep on the machine yet, just wanted to run it through this first incase something messed up and I needed to have a backup. Anybody have any ideas on that error?

@Wayne-Workman Yeah I know, me either…its a SanDisk 64 GB…SDSSDP-064G. I’m assuming it’s one of their first models. We bought them close to 3 years ago.

@Wayne-Workman Ok, with the normal wipe finally completed, the deployment went through with speeds of an average of 5.57 GB/min which is what it should be and only took just over 5 minutes. I wouldn’t have thought the need to wipe it to start with. I figured that we were technically doing that when we were deploying out the image to it, but for some reason with the drive being that full to start with, the drive wasn’t write the image to the disk very fast I guess.

@the_duke Nevermind, it just completed…didn’t remember it normally taking that long to do.

@Wayne-Workman How long should the normal wipe task take? It has been going for an hour and a half now and the screen shows writing zeros to /dev/sda and then a blinking cursor right below it. When I look in the task management in fog web interface, it just says the task is queued.

@Wayne-Workman Will do.

@Wayne-Workman Ok, well I believe that I have found out the problem. These custom built units currently have 64 GB SSD on them. They were getting filled up and what we were trying to do was reimage them and to free up some space. What we probably should have done is at least a normal wipe of the drive and then reimaged the machine. What I tried was taking the HDD out of one of the refurbished units that was going normal speeds and hook it into one of the custom built units and it imaged in 5 minutes. So I am in the process now of doing a normal wipe of a machine and then going to reimage it then and see how it goes. I am expecting it to go much more normal.

@Wayne-Workman ok, I upgraded to trunk and I’m on version 6533. I uploaded my image just to make sure the image was updated with latest settings. The image uploaded in 9 minutes at a rate of 3 GB/min which is very fast. Now after finishing a download to another computer of the same model, it had an average rate of 729.39 MB/min. I had set my compression rate for this image at 7.

@Wayne-Workman well ok, I’ll try that in the morning

@Wayne-Workman Ok, I currently have undionly.kkpxe on dhcp server. I have also tried undionly.kpxe (which was on there originally), ipxe.kkpxe, and ipxe.kpxe. do you have any other suggestions?