No shrink from V1.5.5 until V1.6, deploy error, 100%CPU load in node 1.5.2

[HG12]

Hi,

I know mp12 personally and i have the same problem. But I have a other problem at the beginning from version 1.5.5.

Thas only for your information.
mp12 Apr 20, 2018, 8:13 AM

OS: Ubuntu 14.04
FOG: 1.5.2

My storage node runs several sha512sum processes (for long time now)…

Now my problem:
I clone with fog since 8 years, until Windows 7 i used fog V.0.32, now V1.5.2 without upgrade.
OS: Ubunut 16.04 Core
FOG: 1.5.2 Kernel: 4.15.2 , 1.5.5 Kernel: 5.19.6, 1.6(buggy but for my test no matter) Kernel: 4.19.6
Image: 170GB on one Partition, W10
Clients: Dell Optiplex 9010

I wanted go from V. 1.5.2 to 1.5.5 (official) because the sha512sum error provides 100% CPU load.
The V. 1.5.2 worked fine. The ssd was shriniking to the max occupied size.
At the beginning from V 1.5.5 I have no shrinking.
Here an example:
V1.5.2
d1.fixed_size_partition: empty (no:1)
d1.minimum.partitions: /dev/sda1 : start=2048, size=352892644, type=7, bootable
d1.partition: /dev/sda1 : start=2048, size=976771072, type=7, bootable

And now from beginning V.1.5.5 until 1.6
d1.fixed_size_partition: :1 (not empty)
d1.minimum.partitions: /dev/sda1 : start=2048, size=976771072, type=7, bootable
d1.partition: /dev/sda1 : start=2048, size=976771072, type=7, bootable

I can see it if I start the clone and during cloning.
V1.5.5 until V1.6


V1.5.5 until V1.6 no shrink

V1.5.2


V1.5.2 shrink is correct.

And now my main problem:
I deploy the Image on 126 clients in group with 8 clients and from V1.5.5 until 1.6 the deploy ist broken.
The clients abort the download and the entire group is removed from the database although not all are ready. All clients in the group receive a bad image. If I restart the process, sometimes works, sometimes not. This happens at different stages of progress.
It´s the same with 4 groups or one deploy. Now I clone alle clients as singel image without groups then only 1 clients has a corrupt image and 1 client is removed from the database. The other clients continue to work until the next error, if he comes.

I reinstalled the fog x times. I have it testet in Hyper-V and on physical machines. But the problme with the shrink is the same.

I have installed a storage node V1.5.5.
The storage node is detected in V1.5.2 but not replicated.
The storage node V1.5.2 works, but with 100% CPU load. This is a guest in Hyper-V. The VM-HD has 25% load during the hash. This is not good for the Host-Server. Can I stop the hashing.

I hope you understand my problem und you have an idea.

[Quazz]

Try the latest init files. You need to manually download those from our server. https://fogproject.org/inits/init_32.xz and https://fogproject.org/inits/init.xz

[HG12]

This post is deleted!

[HG12]

@Quazz said in No shrink from V1.5.5 until V1.6, deploy error, 100%CPU load in node 1.5.2:

Try the latest init files. You need to manually download those from our server. https://fogproject.org/inits/init_32.xz and https://fogproject.org/inits/init.xz

I have downlaod the files, but are the same file in my V1.5.5.
I downloaded the fogproject-dev-branch1.5.5.3 for tests but in V1.5.5.3 is the same error with Zstd.
Now I have the used init files from the V1.5.2 put it into V1.5.5.3.
Now the SSD will be shrink with Partclone/ Zstd in V1.5.5.3.
Is the init file not compatible with my optiplex 9010?
At this weekend I will test image.

[Quazz]

@HG12 There were some changes to how to detect which partitions to resize and which not.

It’s supposed to not mark a single partition disk as fixed size, but it appears that’s not really working as expected, but looking over the code I’m unsure as to why.

edit: Ah, think I may have found the problem.

@Sebastian-Roth

https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L462

Why don’t we just test for if [[ $is_fixed -eq 1 ]] like on line https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L439

This would simplify the code and put the logic on the initial fixed size file creation which makes more sense, imo.

[Sebastian Roth]

@Quazz Not exactly sure how you mean to use is_fixed in case of single partition disk?! May I ask you to send a pull request on that so we can elaborate on the code more directly?

[Quazz]

@Sebastian-Roth No, I mean in general, since the logic to extract fixed partitions and handle single partitions is already done in bin/fog.upload which is where the is_fixed variable is based on anyway.

[HG12]

@Quazz
Thanks for helping, I will test it next week. Today is end of working day.
I send feedback.

[Quazz]

@Sebastian-Roth https://github.com/FOGProject/fos/pull/24

@HG12 Hopefully new inits will be available then!

[Quazz]

@HG12 Hey, it’s been a while, is this issue resolved? There are updated inits available (I think) that might have resolved this issue.

[HG12]

@Quazz I´m sorry, I was sick for a long time. Now this day is my first day. I will test it if I have time. But I´m busy with an other project. I hope I can test it next week. Please don´t close this thread. Thanks