@vanopy I’m still thinking its a disk error. You may need to boot it back into Windows and run some disk repair utility to see if 1. you can detect the error in the OS and 2. repair the error. The fog suggestion that disk space on the server is the issue is incorrect.

@Sebastian-Roth OK. I just didn’t wait long enough sorry to rattle your cage. Thanks for the help it did the hash just waited a while and it’s working now.

@luis-acacio said in Filesystem check error after capturing W10 image.:

I’ve tried to follow these tutorials but they are missing a lot of information… they’re just awful. Specially the one in the wiki.

I feel as if I may need to clarify something for you. I understand you may be frustrated, but the FOG Project is an open source solution that is not only free and designed/maintained completely by a small group of very intelligent volunteers, but also has top notch support on these forums that rivals paid support contracts.

Admittedly, the wiki is outdated. This is because these few developers are working on continuously improving fog and running a full fledged helpdesk for free, so it is understandable that the knowledge base takes the back burner. I assure you that every issue I have ever posted about in these forums was solved in an appropriate time-frame.

I don’t speak for the project and the only way I am involved in it is solely as a user, but I hope you now have some insight into the reasons behind the shortcomings of the wiki and I hope your issue is resolved soon and to your liking.

Thanks for the suggestions, George, that sounds reasonable. I’ll do some testing on that when I get a moment! 🙂

@george1421
nothing for grep BUT I started to read messages…
FIGURE IT OUT
My raid controller is the problem. I don’t have two m.2 and I have two sata. The controller managed all 3 drives. Because the raid controller said it only has one raid AND that is it in fogs logs. windows knows how to deal with it because the drivers were load in during install.

I turn off raid mode and rebooted. Found all 3 drives. Now because of my setup, I am going to unplug those sata drives from the board. upload the image. THEN Grab a new one and restore with raid off. Then plug the drives back in. Should just work.

@kafluke You’d want to checkout dev-branch.

Working is more or less a stand in for Alpha RC’s now.

Dev-branch is a bug fix branch

@russel0901 Well lets dig a little deeper into what the pxe booting client is being told. Please follow the instructions here to create a network capture of the pxe booting process. This tcpdump command will only collect pxe booting traffic. Please run the commands and then upload the pcap to a file sharing site (google drive, one drive, etc.) and post the link here or IM myself or Sebastian the link so we can take a look at what the pxe booting client is being told.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Your amazing! That worked! Thanks so much! and the quick response
#FOG4LIFE
until next time.

@Solo509 Best if you take a picture of the exact error on screen and post here.

From what you wrote so far I would imagine that iPXE is not having the right driver for your USB-to-Ethernet or USB-C adapter. Which iPXE binary do you use? undionly.kpxe, ipxe.efi, snponly.efi, intel.kpxe, realtek.kpxe?? Take a look at /tftpboot/ on your FOG server to see all the different ones you can try.

@Sebastian-Roth I am now, as what I expected is the case.

@Sebastian-Roth Okay so I just did a complete fresh install on a brand new server. Dev version 1.5.5.3. Absolutely no logs for me to look at inside the log viewer. Weird.

@Sebastian-Roth Thanks for your reply. Interesting to know, how FOG is starting up. As mentioned before, I think the issue was, that DHCP-Server couldn’t hand out a dynamic IP. So one of the last two requests seem to request with the wrong MAC address, as my DHCP has fixed reservations for the right MAC and should have delivered the right IP. Anyhow, as also mentioned before, the bug (or feature) is not occuring anymore as i freed up some space for dynamic hand out. So sorry, but I can’t provide additional Screenshots/Informations…

@Franklyn I am not sure I get the point of verifying the images right after the transfer as image replication is a constant loop that does a check and re-transfer (if size and or checksum don’t match) of all the image files.

Which versions of FOG do you run on the master and the storage nodes? Is it all surely 1.5.5???

Just for the notes: I pushed a fix for populating the “Working with node” column properly. But still I don’t think this is causing @TheDiskDrive’s issue. Please post a picture of the error you see and we should be able to help.

@Sebastian-Roth said in Issues after changing server IP:

Hint: I think the great changeIP script does not handle dnsmasq config changes as this is not a standard setup.

Correct, it doesn’t.

@george1421 @Sebastian-Roth

Thanks both for your help, I managed to get rid of the second IP address and the server is now multi-casting to 2 laptops.

@plegrand said in Multicast very slow:

Then there is 2 sessions running (test and test2) and all the target computers have about 1.15GB/min rate

Just so I’m clear on this. When you were able to get 4 computers imaging your transfer rate was 1.15GB/min? That’s still 19MB/sec. You are still above the 100Mb/s theoretical limit.

All the computers have 2 partitions and strangely the first partition is slower than the second : about 700MB/min rate

I can explain this. The number is based on an incorrect calculation. The issue is that first partition is pretty small, like 500MB. It transfers so fast that the speed numbers get skewed. The second partition is typically the contents of the 😄 drive. You can see this if you look at the disk manager in Windows. Look at the size of the first partition.

I might need to explain how image multicasting works. There is one computer (FOG Server) that is sending the image out. As each multicast client boots up it checks in with the multicast sender through a discovery process. The muticast sender (FOG Server) configures the multicast sender service to wait for X number of clients to check in before going, or after the first client checks in wait for XX seconds before going even if not all have checked in. Once the multicast stream starts, no other late clients can check in (they are blocked). So in the image stream the FOG server sends out the first block of data then stops. It waits for every multicast receiver (target computers) to respond with “OK!”. The FOG server will not send the next block until it hears “OK!” from every client. If something happens and one client didn’t get the block correctly it will send “Retrans” back to the FOG server and the fog server will resend that block back to the client computer (while the others sit and wait until everyone replies with “OK!”. This is why we say multicasting can only go as fast as the slowest computer in the multicast stream. Consider you have 4, 8-core desktops all with SSD drives and one with a Penitum-4 and a slow HDD. If you imaged them all in one stream the 8 core systems would image at the rate the Penitum-4 system can write data to its slow HDD. If you have a system with a failing hard drive if the block transferred to it’s checksum doesn’t match the checksum of the block on the disk it will send a “Retrans” command back to the FOG server while the other clients wait. The point is when everything works it works well, when you have one bad actor everyone suffers.

@Guillaume-IT As well take a look at the Storage Node definition while you are in the web UI and make sure to correct the interface information there.

@virtualdxs Definitely will make it into the official build as soon as I find a bit more time to properly fix this.

@Sebastian-Roth Great !!! Thank you again.