FOG 1.3.5 RC 11

[Tom Elliott]

Figured out the problem.

This is because of 4k disks. I won’t go into the specifics, but I can try to show the math that equates out exactly what was happening:.

I was taking the size, making it a multiple of 1024:

9637387 * 1024 = 9868684288

On a 512 block disk (normal sized from long ago) The math than goes:
9868684288 / 512 = 19274774

Then we align it as needed (no need to show that work here).

On a 4096 block disk (4k) the math was being presented as:
9868684288 / 4096 = 2409346.75

Now if you make that number an int, you can immediately see it EXACTLY equals the number sectors trying to be copied.

Take that 2409346 and multiple it by 512 and you get about 1.2 GB of disk.

I’ve taken correction action on this and hope this will no longer be present.

As always, please re-run the installer and this capture issue (which appears to me to be only related to 4k disks) should be fixed.

[Tom Elliott]

Oh, and here’s the size that the (bad) was returning:

1233585536

In otherwords, 1 gb, 233 mb, 585 kb, 536b (or 1.2 GB)

[george1421]

@Tom-Elliott said in FOG 1.3.5 RC 11:

Figured out the problem.

This is because of 4k disks.

Ugh, 4kn drives… nuff said.

I would your legacy code will work for 512e drives since they are being presented externally as 512n drives but internally they are 4k.

[Tom Elliott]

I will, however, add that the “boot” partition issue you’re describing.

FOG does not resize partitions that have a label containing reserved, or recovery.

If the label isn’t there, it’s shouldn’t hurt anything to be resized. I don’t think the “non-boot” issue was due to this resizing anyway, now that I’m aware of the CHUNK_SIZE problem. If anything, it was this chunk_size issue that was causing the boot problems to begin with.

[fogschut]

I was indeed running on a 4k drive, those things are so common now I did not even think about mentioning it

The capture job worked correct now and the image was properly recognized as NTFS and a Block Size of 4096 bytes rather than raw and 512 bytes. I was able to restore the image without any problems.

It seems you solved the problem, thanks for your hard work!

[jc35]

Hello,
I test in debug mode, when I launch “fgo” and I have a message “* Running post init scripts…/bin/fog: line 20: fog.postinit: No such file or directory”

[URfog]

@Tom-Elliott My capture is running well now, thanks for your magic

[george1421]

@jc35 said in FOG 1.3.5 RC 11:

Hello,
I test in debug mode, when I launch “fgo” and I have a message “* Running post init scripts…/bin/fog: line 20: fog.postinit: No such file or directory”

Will you confirm that the following directory exits: /images/dev/postinitscripts

[jc35]

@george1421 Hello, thanks for your answer, Sorry, I change the path and I foget to copy postinitscripts.

[Tom Elliott]

All those that were having issues in the past (or those at least willing), would you mind downloading the init’s I’m working on? I’m trying to maintain a proper “alignment” system so a 4k disk would actually be working on 4k sectors as is “expected” to ensure performance and usability.

My hope, now, is I’ve figured out where the issues were present. This should, from what I can tell, only impact capture tasks, so if you can install and test a simple upload (If it fails you ahve not lost your now working image)? You could do this with another image definition too I suppose.

I just am hoping i’m converting the sector sizes as according to the disks now.

The init’s are currently located at:

http://mastacontrola.com/init.xz
http://mastacontrola.com/init_32.xz

You can temporarily replace the init’s with something like:

mv /var/www/fog/service/ipxe/init{,_back}.xz
mv /var/www/fog/service/ipxe/init_32{,_back}.xz
wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

[URfog]

@Tom-Elliott
I’ve done a new capture just to test with your new inits, it does, but shows one error:

• Resizing partition /dev/sda1…awk: fatal: cannot file ‘-v’ for reading (No such file or directory)

Probably a mistype in the script

Regards

[Tom Elliott]

@URfog I’m fairly sure this error is fixed in those init. I’ll rebuild just to be sure.

[Tom Elliott]

Init’s rebuilt on my side.

They are located at the same urls as earlier on.