Flashing Fog images From classic distro

[mm Ekimia]

@george1421 HI

Yes we could use some clonezilla , but Fog has a major advantage : it automatically resize the Root partition allowing use to restore on any disk size.

I know this would be pretty simple to script, I though mpaybe someone has done it before.

[george1421]

@mm-Ekimia Just thinking out loud.

If I understand the situation correctly, you want to image 20 disks in some kind of batch using a single computer?

You could do this with FOG and pxe booting if your drives were connected to your target computer using an external sata dock. You would have a single host registered in FOG and have the primary disk setup to point to the SATA dock. You would pxe boot the target computer (or use usb boot) and then still pick quick image to deploy the image to the hard drive connected in the sata dock.

[mm Ekimia]

@george1421 Can you maybe point me to the source code on teh client side that handles the restoring of the image ?

I could then rewrite a GUI that does the same as Fog. thanks

Maybe over here ? https://github.com/FOGProject/fog-imager/blob/master/scripts/fog.deploy ?

[mm Ekimia]

@george1421 Yes You are absolutly right but this would still be slow :

Let’s say the machine will have sda as fog target disk.

20 times I will have to :

1- Delete the Host
2- Quick register
3- Host reboots ( close to 3 minutes here ) - Change the disk on sda
4- Flash Time over network.

on the other side, I I had my ownclient , I could just plug on eSata ( or USB) , click flash , next etc…

[george1421]

@mm-Ekimia Its a bit easier than that.

You would take a single host with a sata dock. Inside the FOG Engine (linux OS that deploys images) the sata dock might have a /dev/sdc definition.

0. Register the host (once) and then manually change the primary disk to /dev/sdc

1. Insert new hard drive in the sata dock

2. PXE boot the deployment computer

3. Select quick image (assuming you are using FOG 1.3.x)

4. Image is deployed to the target hard drive (on /dev/sdc)

5. power down the target deployment server

6. Repeat the process at step 1

[mm Ekimia]

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

[george1421]

@mm-Ekimia No would have to power off and pxe boot each time. But the booting process is very quick about 10 seconds. Plus you don’t want to just unplug a disk from linux bad things will happen.

You will also want to use sata over usb since its referenced differently in linux as a different device.

[mm Ekimia]

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

@mm-Ekimia I can honestly say, in 5 minutes I can setup a computer on the bench, pxe boot a target computer, deploy an image, power it off and setup the next computer for imaging (I may have fudged the time just a minute or two, but pxe booting into FOS is about 20 seconds at the most). My total push time is about 3.5 minutes for a 10GB reference image.

Understand I’m using FOG 1.3.0RC14 for imaging and the developers have made huge improvements in speed and new hardware support since the 1.2.0 days. I can’t understand the 5 minute to partclone start. That IS almost my entire unitcast image deployment process.

[mm Ekimia]

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

[mm Ekimia]

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

[Wayne Workman]

You might want to look into just scripting a very old Unix program called dd to do this job.
You could connect as many disks as you want to one computer, as long as one is a reference disk, and then just script dd to copy from the source disk to all destination disks simultaneously. This would probably be something you’d want to run overnight as it would take quite a long time.

[mm Ekimia]

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

[Wayne Workman]

@mm-Ekimia In the 6 days that have passed, you could have already had this project done by just imaging one drive at a time in the actual computer it belongs in. Even with Norton Ghost, I’ve imaged 30 HDDs in a day that I had to physically remove from incompatible Laptops - image - and then re-install. And that was with handling all my other responsibilities and phone calls too.

Who cares if it takes 5 minutes for your “powerful skylake laptops” to pxe boot? FOG is free and open source and developed by volunteers, and supported by volunteers - and they don’t ask for a dime in return.

In the 5 minutes it takes one of your “powerful skylake laptops” to pxe boot, I would have another 10 hooked up by then and also waiting to pxe boot.

[Tom Elliott]

@mm-Ekimia I’m confused what you’re trying to replicate.

While I understand you may not want to wait 5 minutes, it seems a bit extraordinary to be working so hard to come up with a FOG like solution that doesn’t involve actually use FOG as it was intended. All this time to image 20 HDD’s would’ve taken about an hour worth of time including the 5 minute pxe boot time if you simply just grabbed a few extra laptops, registered and then tasked them.

Of note with this, it sounds like these Skylake laptops are attempting to boot VIA UEFI? UEFI booting is supported with FOG but as far as the implementation as handled from the NIC itself is outside of “FOG’s” realm of control. If it’s taking UEFI NIC booting 5 minutes, why not just tell the BIOS to boot nic in legacy mode? (Of which I’m pretty sure will NOT take 5 minutes to boot).

Now here’s where I’m confused about why you need to create, essentially, a FOG like solution on your side.

You don’t want to wait the 5 minutes of booting into the NIC. This is the ONLY reason, as far as I can see, as to why you don’t want to just use FOG as it was intended. Now we’ve been a week at this with back and forth information. When you initially made the posting asking for assistance, if you had installed FOG, had 5 of these laptops, inserted an HDD into each one, booted the system through PXE and telling that system to image. Run this 4 times, you’d have all 20 HDD’s complete within about an hour (give or take a little).

If you had 20 laptops all at once, you’d probably be done in about 30 minutes to an hour if you ran it through a multicast task.

I don’t know what the end goal is. I think FOG is perfectly capable of imaging these disks regardless of how long PXE takes to load up. You’d have been done by now if you had just waited the extra 5 minutes or so per system.