@processor said:

Hi Sebastien, I just did the test again and put the new ini files create the FTP error and put back the original 1.5.5 ini file correct it.

So are you saying that using the 1.5.6 inits is causing the FTP issue but using the 1.5.5 inits you don’t get the FTP error but the UUID issue?!??!

Well we changed the FTP username from fog to fogproject from 1.5.5 to 1.5.6 but that is not hardcoded in the inits and shouldn’t cause this issue I think. You might still try updating to 1.5.6 to see if that fixes the problem.

@Whitespire-tech I remember we had an issue with some special character that was never resolved: https://forums.fogproject.org/topic/12407/active-direcory-join-fail-bad-password-1-5-4

@salted_cashews Would you be keen to test new init files (manual download of inits and possibly kernel binaries) if I provide those for you? Should find enough time by the end of this week.

@salted_cashews No, we have not included this patch to FOG yet. This is new to me as well. Just stumbled upon this when looking for a solution.

A new version (1.5.6) was released a couple of days ago but as you see we are always on the edge of trying to solve all the issues that arise. So new releases will come… You need to know that we don’t have a strict release schedule. We are a very small team of developers and sometimes there is very little time while we have a bit more at other times. So sometimes there might be a new release in just two weeks and sometimes it takes months.

@scosta Thinking a bit more about it I am wondering if you did resize the partitions on your master at some point. I am not sure but possibly this could lead to the situation we see with different partition start information.

Please schedule a debug capture task and when you get to the shell run sfdisk -d /dev/sda and gdisk -l /dev/sda - take a picture and post here.

@scosta Thanks for uploading the files. I wouldn’t have had a chance without those. Turns out the partition start sector information is different in d1.partitions versus what we see in d1.mbr. I still have no idea how that can happen. It doesn’t match any logic I have come across so far. It’s not a 4k block size thing and I have no idea what’s going on - not yet.

But I have a quick fix for you. Get a good hex editor and a copy of your d1.mbr file (keep a copy of the original somewhere just in case). Open it and go down a few lines till you get to position 07A0. Should look like this:

00000780   A2 A0 D0 EB  E5 B9 33 44  87 C0 68 B6  B7 26 99 C7  ......3D..h..&..
00000790   18 46 DC CB  86 67 E9 11  97 EA F8 22  01 FA 30 3B  .F...g....."..0;
000007A0   00 02 D0 0E  00 00 00 00  F7 FC 9E 0F  00 00 00 00  ................

Simply change the hex numbers in the last line (07A0

00000780   A2 A0 D0 EB  E5 B9 33 44  87 C0 68 B6  B7 26 99 C7  ......3D..h..&..
00000790   18 46 DC CB  86 67 E9 11  97 EA F8 22  01 FA 30 3B  .F...g....."..0;
000007A0   00 96 8E 07  00 00 00 00  F7 90 5D 08  00 00 00 00  ..........].....

Save the file and put into your image directory on the FOG server as /images/W10_SEMSIS_MULTI_1.01/d1.mbr. Now try to deploy again. Should work.

I know this sounds really strange and I am fairly sure we’ll find out why this has happened. But for the time being I hope you can get this fixed as simple as described above to be able to deploy this image again.

@Valer We updated rEFInd to a newer version with FOG 1.5.6. That might have broken the chainload boot on your HP machines. But we also have an older version in the same directory. Run the following commands on your FOG server to see if that fixes your issue:

sudo su -
cd /var/www/html/fog/service/ipxe
mv refind_x64.efi refind_x64.efi.orig
mv refind.efi refind_x64.efi

Now try to boot your HP workstation again and see if it still freezes.

Hint: Those commands only work for FOG 1.5.6 and maybe later but NOT earlier versions of FOG!

@Florent said in Power Management - Day of week usage differ from cron:

It’s possible to push it to the next release ?

We’ll definitely include that fix into the next fog-client release. Right now I can’t tell you when that will be. Our main client developer is very busy and I won’t be able to push out a new release without him.

@khalid As explained in the other topic I think you are asking too much from FOG which actually is a disk imaging software but not some kind of software deployment!

@ErwinBullen Ok, thanks for the update. So I definitely went down the wrong track assuming this was only on one machine.

Is it always sda2 failing as seen in the two pictures? Maybe it’s some kind of network (driver) issue?! Just blindly guessing here.

@salted_cashews As far as I can see the partition layout looks fine. Don’t think there is anything wrong with it - at least not something obvious.

So we are back to the point where you tried to manually extract d1p3.img and that failed with “Read error (39) : premature end”. Asking the search engine of choice we get some interesting bug report here pointing to a fix that was pushed only a month ago. Not exactly sure but to me it sounds like this could be it. @Tom-Elliott @Junkhacker what do you think?

@Florent Thanks for letting us know. You are right there. From https://www.quartz-scheduler.net/documentation/quartz-3.x/tutorial/crontriggers.html I figured that the scheduler we use is just a little different than the usual CRON syntax:

… Days-of-Week can be specified as vaules between 1 and 7 (1 = Sunday) …

I just pushed a fix to github and compiled a new Modules.dll. Download it, rename to Modules.dll and place in C:\Program Files (x86)\FOG directory (might as well rename the original file instead of overwriting it).

@Pi0tR Nice find! It’s interesting it states “Invalid TCP packet for current connection state” as this is the first packet (only SYN flag) of a TCP three way handshake and therefore surely the connection does not exist yet.

@ErwinBullen That’s interesting. The compressed image file seems to de-compress just fine. Not what I expected.

The error does not appear all the time. Sometimes (rare) it succeeds

From my point of view this sounds like a hardware issue. Please to RAM checks (memtest) and see if it finds any error on this particular client!

I expect the client/host to be the trouble maker here and not the storage node.

@Pi0tR Retransmission as seen in the wireshark screenshot usually happens when a previous packet (number 182 in your case) is not being answered by the other end. The client seems to send a proper TCP SYN packet to 172.16.2.50 destination port 80 (HTTP). Looks fine. But there is no response which should be a TCP packet with 172.16.2.50 - port 80 as source and 172.16.20.10 - port 20449 as destination.

So either the routing is not setup properly - which I doubt because TFTP seems to work. Or the firewall/router in between is simply dropping the HTTP (port 80) packets for some reason. Talk to your network people.

If you are still sure this is not a firewall issue then please boot up the client machine 172.16.20.10 to its normal operating system from disk and try accessing the URL http://172.16.2.50/fog/service/ipxe/boot.php from that machine. I guess it won’t work.

@khalid No problem at all. Just me trying to keep things a bit tidy here. Don’t worry.

@khalid said in unable to install with snapin:

this is an .exe file that runs perfectly on my local machine with just a simple … next next

You need to make this a so called silent install that can run without user interaction!

Here find some hints on the command line options you can use: https://installer.netbeans.org/docs/cli_options.html and http://wiki.netbeans.org/NetBeansInstallerTipsAndTricks#Simple_silent_installation_with_customization

@SPaceSkillz1 Do you run the installer as root (sudo su - instead of sudo ./installfog.sh)?

Post the last 20 lines of the error log you find in fogproject/bin/error_logs/fog_error_1.5.5.log!

By the way, 1.5.6 was released a couple of days ago. Do you have a good reason to still use 1.5.5?

@khalid FOG is more a image deployment software solution. I think there are other solutions around that can do those particular tasks way better.

Moving this to general questions as this is not a FOG problem.

@Pi0tR said in http connection timed out:

im trying to connect to server from another VLAN (another subnet)
fog-srv IP 172.16.2.50/24
host IP 172.16.20.x/24 - dhcp is on a fog-srv

Please explain this a bit more. Which IP address/subnet does the machine receive from the DHCP server when it does the PXE boot and fails with “Connection timed out”?

I am still wondering if there is a firewall causing that?! From what we see in the picture the client boots via PXE gets and IP from the DHCP and is also able to load default.ipxe file from 172.16.2.50 (obviously your FOG server) without any problem. From my point of view this means that DHCP and routing are working just fine.