Image failed to restore and exited with exit code 1

[Sebastian Roth]

@melvinpaz Definitely worth a try.

[Tom Elliott]

@Sebastian-Roth @melvinpaz I don’t think changing the compression type is going to fix anything. If anything, it would make it worse as the “whole” image is compressed using the same mechanisms. E.G. d1p1.img is compressed just the same as d1p2.img. As this is failing on d1p2 (after partially running through) this leads me to believe changing the compression method will make things a bit worse.

[melvinpaz]

Thank you for your feedback
You will have a compression mode solution to propose to me to work or do tests to continue using a raspberry or do I have to change my hardware?

Currently I am doing a test without compression. I’ll get back to you as soon as it’s over.

[melvinpaz]

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

[Sebastian Roth]

@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.partitions and d1.fixed_size_partitions here in the forums. You find those on your FOG server in /images/SalledeFormation02/.

[melvinpaz]

Hello @Sebastian-Roth

You will find below the requested screenshots.

---

---

[Sebastian Roth]

@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]

Hello @Sebastian-Roth

Here is the screenshot

Thank you for your help.

[Sebastian Roth]

@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?

[melvinpaz]

Hello @Sebastian-Roth

The problem wouldn’t come from the choice of partition at boot time?
I ask the question so you never know

Thank you for your help

[Sebastian Roth]

@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 setting sda3 as 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/sda

Not within the fdisk tool use the command a to flag a partition as bootable. It will ask you which partition it should set as bootable. Use 3 I’d suggest. Then use the command w to write the changes and when you are back to the shell type reboot and cancel the debug task in the FOG web UI.

[melvinpaz]

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

[Sebastian Roth]

@george1421 Any idea on this?

[george1421]

@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

1. 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).
2. 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.
3. 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 top show for system stats?
4. It could be the target hardware (also not mentioned). Since its capturing and deploying we can rule out any pxe boot issues.
5. 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?
6. Is FOG doing something to the source or destination disk format before/after capture to cause it to be unbootable?
7. 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.

[Sebastian Roth]

@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!

[melvinpaz]

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