Posts made by mm Ekimia

Just a note , I had the same problem ( SATA to NVME ) with CloneZilla , had to fiddle with Windows liveUSB BCD to update the Boot manager

Thanks,

TO help the previous image ( W10 1809 like this one ) can be flashed to NVME and SATA without problems.

I also think that this is a naming convention problem

Hi,

it seems we did not have this problem before 1.5.7 :

• Capturing on a 250G Sata SSD
• Restoring on a 1 To NVME

Fail to boot with the blue smiley screen.

Is this a scenario where windows cannot boot usually or something on what fog is doing when restoring ?

thanks

@Sebastian-Roth Thanks We’ll wait 1.5.6 as it’s non-blocking

Actually it happen also with Linux image so it’s more about the nvme aspect I guess …

Many thanks , won’t the init be updated when I will upgrade FOG to latest version ?

that would be simpler

Hi,

This is not a critical issue as the imaged disk seems to work.

We are using Fog 1.5.0 with W10 1809 images built from a NVME disk and restored on NVME disk

Each time we restore the image , we get a "fail to restore disk GUID " on the first partition as you can see :

Hi ,

just to say that I deployed the same Image to a new SATA disk and the 3rd partition (Swap) had a fixed size as Expected.

So I guess that was a mistake on my side.

Problem solved !

Forget my last post

So yes fixed partitions was initialized with :1:3

So it seems that the third partition (swap here) should not be resized proportionnaly as I understood.

@tom-elliott said in Organizations Using FOG:
Organization Name: EKIMIA company
Location (Optional) : Marseille , France
Approximate Number of systems: more than 500 systems shipped to customers using FOG
How long: Since Mid 2015.

Thanks tom , You mean trunk would fix this ?

You mean Trunk would detect automatically Fixed size the swap partition ?

Even when a SATA captured ( sda3 ) is restored on a PCIE devices ( /dev/nvme1n1p3 )

it was working perfectly when the partition scheme was Legacy but with EFI scheme it seems to behave differently

Hello , even if it was 4 years ago I answer my thread because we now use 1.5.0 which works great .

I can now restore a Full EFI Layout ( EFI + Root + Swap) ( However I restore on a BIOS legacy machine as Booting UEFI PXe is still not setup correctly on my side)

But Now When I deploy image to a Twice Bigger disk ( either SATA or PCIE ) I get :

• EFI partition : 512 MB same size
• Root partition ext4 : Twice Bigger ( proportionnaly)
• Swap Partition : Twice Bigger

Then I wonder if I could avoid that the Swap is twice Bigger ? Because when drive will be 4 times bigger , that will be a Big swap.

Thanks

Upgrade worked perfectly ! Great. thanks

Thanks , doing it right now , fingers crossed

Hello , I have a 1.3.0 running.

Do you advise to go through 1.3.1 …1.4.0…to 1.5.0 for upgrading ?

Or running the upgrade using the 1.5.0 directly could work ?

Thanks

@Wayne-Workman : dd is not the right tool for this job ( restoring to disk from 120gB to 1 TB )

FInally I found exactly what I need here :

https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/package/fog/scripts/bin/fog.download

I need now to replicate those steps in a desktop gui to be compliant with fog images.

I can’t understand the 5 minute to partclone start. That IS almost my entire unitcast image deployment process.

Those minutes are lost after “loading initrd” when rebooted in image flashing task

@george1421 Very good info ! Seems like upgrading to 1.3.0 RC is needed on our side.

@george1421

On our powerful skylake laptops , Booting Fog for a restore task can take up to 5 minutes before partclone starts.

This is the part we want to avoid.

DO you think this time is for caching the image ? or the kernel wait for something ?

@george1421 thanks , Yes I’m on 1.2.0 , quick image was already on 1.2.0 I guess ?

Then I could call quick image 20 times with rebooting ?

So yes you are right , with a Hotplug Sata ( or USB3) and the quick image function this could be quite quick.