It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.

[Basavarajnc]

@compman Dear Sir (compman),

I am New Comer to this… But One Thing is that Clear: I Love Linux and This Kind of Stuffs ( One more Important is that: Fog Server is Part of My Life. I am so Happy about this Fog Server).

possible to use its new –long option : Where this option Comes Up ?

Compression level -19 : is it your recommendations ? am I Correct Sir?

Downside: it requires a fairly recent version of zstd >> Is it This Version of zstd-v1.3.4+) required to have Best Result — Is it Correct Sir,

Actually I have Fog-1.5.4 Version(It is latest Version). So it means that zstd also Latest One - Am I correct?

Please Kindly to rectify about What assumption I have made or written is Correct?

Heartily Thank You,

Basavaraj From India,

[george1421]

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

But One thing… I observed that… capturing Image process is Slow (Approx… 800 MB to 830 MB/Minute) Before It was 3GB to 4GB/Minute… It is Because of Changing the Kernel Version??

This would be interesting to know, if changing the kernel between 4.15.2 and 4.18.x has an impact on transfer speeds if the only thing that changes is the kernel. If you are willing to help us test this concept it would be appreciated.

You can manually download the FOG kernels from here: https://fogproject.org/kernels/

1. Download Kernel.TomElliott.4.18.3.64 kernal and save as bzImage4183.
2. Now transfer bzImage4183 to the fog server using winscp or pscp utilties into the following path: /var/www/html/fog/service/ipxe
3. Go into the host definition in the fog gui to the same host that gave you 800MB/s transfer rates.
4. Add the following to the Host Kernel field: bzImage4183
5. Now schedule a deployment.
6. Monitor the transfer rates.

I also have to say that 800MB/min is suspiciously close to the theoretical max transfer speeds of 100MB/s (not 1GbE) network speeds.

[george1421]

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

possible to use its new –long option : Where this option Comes Up ?\

That is a feature the developers would need to add because it requires an adjustment to the php code. You can do this if you understand php programming.

Downside: it requires a fairly recent version of zstd >> Is it This Version of zstd-v1.3.4+) required to have Best Result — Is it Correct Sir,

I might suspect that zstd in FOG is not the latest, because FOG uses buildroot to create FOS (the linux OS that runs on the target computer). If buildroot from February 2018 has zstd 1.3.4 then so does FOS.

[Basavarajnc]

@george1421 Dear Sir,

Definitely I will do Help Without Second Thought to test this Concept…

I need little Time for making changes to …

Little confusion in below Section 2 and 5

-2. transfer means copying the bzImage4183 To This /var/www/html/fog/service/ipxe … is it Correct way of understanding myselft?

-5. Now Scedule a deployment -->> Sir, it is Not During Deployment Of Image…

It is the time of Capturing Image From Client… (It took 800MB/s Transfer Rates).

Thanking You Sir,

Basavaraj From India,

[george1421]

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

-2. transfer means copying

Yes trasfer == copy == move however you get the file to that directory.

-5. Now Scedule a deployment

I have seen capture as low as 800MB/min depending on your compression setting and the performance specifications of your target computer. The target computer’s CPU is used heavily during image capture to compress the hard drive image before its sent to the fog server. If you have a slow target computer, with an old CPU, or slow hard drive, or too high image compression will cause slow capture speeds. But for image deployment to same computer it should be faster.

[Sebastian Roth]

@Nicolas-T @phil-dosi @Basavarajnc @compman @Tywyn Good news to all of you, we have figured out what is causing the slowness and fixed it. It’s been a longer story [ref] - thanks again to @Quazz for doing lots of testing and finding very helpful stuff to figure this out!

As we have not had enough time to push for a new release yet you can simply update to the latest kernel and inits like this:

sudo -i
cd /var/www/fog/service/ipxe
mv bzImage bzImage.orig
wget https://fogproject.org/kernels/bzImage
mv bzImage32 bzImage32.orig
wget https://fogproject.org/kernels/bzImage32
mv init.xz init.xz.orig
wget https://fogproject.org/inits/init.xz
mv init_32.xz init_32.xz.orig
wget https://fogproject.org/inits/init_32.xz

[Basavarajnc]

This post is deleted!

[george1421]

@Basavarajnc Please follow Sebastian’s instructions to solve your slow partition creation issue. He found the root of the problem. Please confirm its fixed on your system so the developers can mark this issue as closed.

[Basavarajnc]

@george1421 said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

But One thing… I observed that… capturing Image process is Slow (Approx… 800 MB to 830 MB/Minute) Before It was 3GB to 4GB/Minute… It is Because of Changing the Kernel Version??

This would be interesting to know, if changing the kernel between 4.15.2 and 4.18.x has an impact on transfer speeds if the only thing that changes is the kernel. If you are willing to help us test this concept it would be appreciated.

You can manually download the FOG kernels from here: https://fogproject.org/kernels/

1. Download Kernel.TomElliott.4.18.3.64 kernal and save as bzImage4183.
2. Now transfer bzImage4183 to the fog server using winscp or pscp utilties into the following path: /var/www/html/fog/service/ipxe
3. Go into the host definition in the fog gui to the same host that gave you 800MB/s transfer rates.
4. Add the following to the Host Kernel field: bzImage4183
5. Now schedule a deployment.
6. Monitor the transfer rates.

I also have to say that 800MB/min is suspiciously close to the theoretical max transfer speeds of 100MB/s (not 1GbE) network speeds.

Dear sir(george1421),
1 Downloaded the Kernel.TomElliot.4.18.3.64 Kernal and Renamed it to bzImage4183. Taken that file In Pendrive and Copied it in Fog Server Machine in the Following Path-> /var/www/html/fog/service/ipxe

I went into Host Definition in the FOG GUI to the Same Host …
Added the File “bzImage4183” by Writing**(manually Written)** in the Field of Host Kernel… and then Updated Successfully by clicking Update Button in Make Changes? Field.

5. I scheduled a Deployment for Same Image Which captured from same Computer at Rate of 800mb/s During Capture.

6. I monitored the Transfer Rates At Rate of Transfer Speed is 7.5 GB to 8.2 Gb while deploying the Image…

Now My Question is … Manually Written the file ->“bzImage4183” in the Host Kernel Field… is it Correct Sir?

Thereafter, I updated by using Update Button in the Make Changes? Field… is it Correct Sir?

It is for my Satisfaction and Confirmation myself.
My Intention is …What you asked Questions should be matched with What I understood …

Honestly Thankful to you Sir,![alt text]
Basavaraj From India,

[george1421]

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

Now My Question is … Manually Written the file ->“bzImage4183” in the Host Kernel Field… is it Correct Sir?
Thereafter, I updated by using Update Button in the Make Changes? Field… is it Correct Sir?

1. Yes this is correct. This field allows you to assign a specific kernel to a specific host. That is the design of FOG.
2. No this is not correct. You have hard defined for that host it will only use bzImage4183. The main and updatable kernel is called bzImage. When the next version of FOG is released (1.5.5) it will only update bzImage. The host where you statically defined bzImage4183 will continue to us that kernel forever.

Also Sebastian’s fix also requires you to update the init.xz files to completely eliminate the delay during disk format creation. So both the kernel (bzImage) and the virtual hard drive (init.xz) need to be updated to correct this problem.