Image failed to restore and exited with exit code 1
-
Hey @Tom-Elliott, @Sebastian-Roth
This does not work despite the fact that the image is well deployed
I tried the “partclone uncompressed” function and I reach the end of the process but when I restart the Windows computer does not start I have a flashing white bar in the upper left corner of my screen despite the image being well deployed in the hard disk. As if windows doesn’t start.In the bios we are well in AHCI and Legacy for the boot of windows. I also tried in UEFI impossible to start
All signals are on Done
-
@melvinpaz Is the PC you captured the image from in UEFI or legacy BIOS mode?
The image capture I’m trying to deploy was basically on a 3.5 hard disk and now I’ve put everything on SSDs.
Just reread your initial post and found this. Possibly this is playing a role in the issue you see now (window blinking cursor). Is this image set to resizable? Can you please post the contents of the text files
d1.partitions,d1.minimum.partitionsandd1.fixed_size_partitionshere in the forums. You find those on your FOG server in/images/SalledeFormation02/. -
-
@melvinpaz The partition layout looks fine from my point of view. Partition sda1 and sda2 are marked as fixed size but sda3 is resizable. As well sda2 is marked as bootable and should be so on deploy.
Please try the following. Go to the FOG web UI and schedule a new deploy task for your machine but this time tick the checkbox for debug mode. Boot up the client and when you get to the shell run
fdisk -l, take a picture and post here. I am looking for the “Sector size (logical/physical)” information. -
-
@melvinpaz Ok, definitely not a sector size issue either.
Anyone else got an idea why it would hang on the blinking cursor after a successful deploy?
-
Hello @Sebastian-Roth
The problem wouldn’t come from the choice of partition at boot time?
I ask the question so you never knowThank you for your help
-
@melvinpaz said in Image failed to restore and exited with exit code 1:
The problem wouldn’t come from the choice of partition at boot time?
What exactly do you mean by that?? In the pictures and other information you posted we see that
sda2(hidden WinPE partition) is set as bootable. I have wondered about this but as we see this in the capture information as well I didn’t really bother. But you might be right. Try settingsda3as bootable and see if that fixes the blinking cursor issue on boot.Are you familiar with the tools to use to do that? You can do it using the FOS environment. Schedule a debug job for the client that has the issue and boot it up. When you get to the shell run
fdisk /dev/sdaNot within the
fdisktool use the commandato flag a partition as bootable. It will ask you which partition it should set as bootable. Use3I’d suggest. Then use the commandwto write the changes and when you are back to the shell typerebootand cancel the debug task in the FOG web UI. -
Hello @Sebastian-Roth
I just tried it and the problem remains the same impossible to launch windows, blinking and still present.
If a person has a lead, I’m a taker. If you need more information, do not hesitate to contact me. So I put it back on sda2
We look forward to hearing from you soon.
Thank you for your help -
@george1421 Any idea on this?
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth Sorry for the delay I wanted some quite time to be able to read the entire thread where I could focus.
So reading through this… I’m trying to build a truth table in my head and at this point there isn’t enough data to make heads or tails of the issue.
As I see it the issue could be
- The fog server running on the Pi. (I’m running it on a Pi3 at home under raspbian and FOG captures and deploys correctly. The only caveat here is I’m running FOG 1.4.4 on my Pi).
- It could be FOG 1.5.5 in combination with the Pi OS. I see the OP hadn’t mentioned what OS is being run on the Pi.
- It could be available memory or disk space (probably not). Since its blowing up on the pigz compression and that’s stream based it could be available ram. What does
topshow for system stats? - It could be the target hardware (also not mentioned). Since its capturing and deploying we can rule out any pxe boot issues.
- It could be the image itself. Is the OP capturing and deploying to the same (exact) hardware or one of the same model? If it was captured from a uefi system is it being deployed to a uefi based system? You can’t mix and match firmware (bios) types. If the OP boots with a windows 10 install CD and goes into rescue mode can the boot issue be fixed?
- Is FOG doing something to the source or destination disk format before/after capture to cause it to be unbootable?
- Was the windows image sysprep’d before image capture or was the system just shutdown, captured and then deployed to new hardware?
As you can see I have a lot of questions that may lead to windows not booting. I would think if the uefi firmware found the uefi boot file in the right location it should do a bit more than just having a cursor in the upper corner.
-
@george1421 Thanks heaps for looking into this and bringing up the points you have.
From my point of view I wouldn’t think it can be an issue of Pi being used as a FOG server. If it does deploy the image well (no errors) then it shouldn’t matter where FOG is running, really. It’s FOS on the client that does the capture/deploy and that is exactly the same no matter what Linux OS or hardware you use to run FOG server. Just my idea of it.
The other questions are great! @melvinpaz Can you please elaborate on those!
-
Thank you for your feedback,
I do all the tests at the end of the week and I’ll give you a feedback at that time. I won’t have the equipment available until
