@oliviert82 OK so the question is what is in the 4th physical partition on that hard drive. FOS is reporting the structure is incorrect. If you take a similar system and try to capture it do you get the same error?
My idea is that this hard drive has a problem in its partition layout. The operating system doesn’t appear to have an issue with it, but when its cloned partclone isn’t happy.
If you are running FOG 1.1.2, my recommendation is to update/upgrade to FOG 1.4.4. 1.1.2 is over 4 years old and doesn’t support any modern hardware, uefi, gpt disks, and basically Windows 10 at all. This is only my opinion, but the developers are working hard to get FOG 1.5.0 released, there may be little motivation to go back and review the older FOG code for bugs.
Beyond that, it really helps if you can post a clear picture of the error taken with a mobile. This will help understand the context of your error.
@sebastian-roth That reminds me, there are the iPXE kernels with a 10 second delay. I don’t know what conditions these were created for. Do you remember? I just checked and they are still in FOG 1.4.4 in the /tftpboot/10secdelay directory.
I think its important to find out why this condition exists in the networking infrastructure. Its not normal or expected, but if all options fail, these iPXE kernels may be the solution.
You may need to do a debug deploy and single step through deployment process to see if you can capture the error why the partitions won’t expand.
You may also want to download the latest inits (manually) and install them in your fog server. The devs patch the inits last week to solve a specific issue with disk expansion.
wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32
@krassus you can also review the settings that were selected when FOG was installed. The file is /opt/fog/.fogsettings file. The . is suppose to be there in front of fogsettings.
Also you need to ensure that these settings are correct since when you upgrade fog, the installer will use the settings in this file.
@crixx The x360 was released in early Apr 2017.
FOG does rely on other FOSS projects that make FOG possible. One important one is iPXE. Those guys in the iPXE project are really good and are constantly changing / upgrading the iPXE kernel as new hardware is released.
I would expect one or both things to happen here.
So I see this (snp.efi) as a stop gap measure until one of the two are updated.
@krassus Did you answer yes to install isc-dhcp server? If not you would issue this command prompt
sudo systemctl disable isc-dhcp-server
sudo systemctl stop isc-dhcp-server
@krassus The white screen means that something is going wrong with FOG program code. FOG uses the apache web server to host the FOG site. Any time apache runs into an error message it logs it in the apache error log. To view the last few lines in the apache error log you would use the following command tail /var/log/apache2/error.log Its possible that the name of the apache error log is not error.log, but error_log (I’m a rhel guy not ubuntu so I can’t be precise).
OK then I would surely review that fog enemy document and then post the tail of the apache error log if the white screen doesn’t get fixed.
Then you ‘might’ consider updating your version of FOG to the latest 1.4.4. The 1.3.0 RC9 is really old. But lets fix what you have right now then worry about upgrading later.
It would really be helpful to know what version of FOG you installed.
Was this a new install or just one day it broke?
Since you have Ubuntu 16.04 you might want to review this document: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy
Lastly, if you continue to get a white screen, this means that the php program is having issues. Please review (tail) the apache error log in /var/log/apache2 and post the results.
@triso Ok then if you already have a isc-dhcp server before fog then do not install the fog dhcp server.
To configure your current dhcp server the FOG Wiki is a great place to start: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1 Example #1 is the perfect settings you will need. In your subnet section add the class directives as seen in example #1 as well as the next server directive. That should be the IP address of your fog server. That is it.
@oliviert82 Ok no problem. I’m in the USA but I am usually on until I go to bed. I would scan this target computer to see if windows can find the flaw on partition #4.
@oliviert82 The above is a different error. The above error is saying there is a problem with the 4th partition in that it can’t read the last sector of partition 4.
@oliviert82 Ok that changes how we look at this. At first I got the impression you were trying to capture a server that has raid configured. Then I noticed your OS type is 9 (Win10) which I think is strange.
Ok now we know its a Dell Desktop and you are trying to do a capture of that device. We might think that this hard drive (in target computer) has some flaws in it. I see it has 4 partitions this is a bit abnormal for a windows 10 system. Is this an OEM created hard drive with a recovery partition? If you run check disk on all disks does it find a problem?
@jle I don’t know the cisco switches, but typically you turn on rstp globally and then each port you can define as rstp or stp, or turn of stp on that port alone.
I don’t think anyone on the forums is a cisco network engineer to help. You might get a better quality answer if you post on the Spiceworks Community.
But since the d-link is keeping the cisco from seeing the network link, wink as the target computer pxe boots, I’m almost 100% positive its a spanning tree issue with the port.
@oliviert82 I’m asking about the computer that printed the error in the picture. Tell us a bit more about that.
Hello Olivier welcome to the FOG forums.
First can we collect a bit of background information on this computer?
Who manufacturers it and what model is it?
Do you know the raid adapter used in this target computer?
We may need to enable a kernel parameter mdraid=yes (I think that’s it).
I think the next steps (after data collection) is to configure a new capture task. This time we will select the option to debug this task. That will tell the pxe booting client to not run the deployment script right away, but drop us to a linux command prompt so that we can run some diagnostic commands.
But first lets get some details so we know what we are talking about.
Just so I’m clear, the 440s pxe boot just fine to the FOG iPXE boot menu is that correct.
But the problem comes when the timeout on the iPXE menu reaches 0 it doesn’t boot from the hard drive? It tries to just pxe boot again, like the target computer just rebooted and never loads from the hard drive?
If this is true, then your exit mode from FOG is not set correctly. 90% of the time SANBOOT works great for locating the hard drive. Other times not so good. What I would do is change the bios exit mode from one system to the other FOG exit modes to see if it can locate the hard drive.
The other option is if you don’t need unattended imaging, you can always set the format to be usb,ssd and then when you want to image (you have to be in front of the computer) but boot the computer and press the F12 key to get the boot menu. From there you can pick network boot.
You can also leave the target computers in uefi mode if you just disable secure boot and then send the uefi kernel [ipxe.efi] to the target computer. But of course you must have a uefi based system image to deploy to that target computer.
@Developers Comment please on the 1.5 GUI?