FOG 1.3.5 RC 11
-
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)
-
@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.
-
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.
-
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!
-
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” -
@Tom-Elliott My capture is running well now, thanks for your magic
-
@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 -
@george1421 Hello, thanks for your answer, Sorry, I change the path and I foget to copy postinitscripts.
-
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.xzYou 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 -
@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
-
@URfog I’m fairly sure this error is fixed in those init. I’ll rebuild just to be sure.
-
Init’s rebuilt on my side.
They are located at the same urls as earlier on.
