Posts made by Middle

@nrg The following is based on using Fog 1.5.7 master branch on CentOS.

Are you using the updated init_partclone.xz? Here’s the link:

https://drive.google.com/open?id=1u_HuN5NSpzb7YmQBAsrzDELteNmlWUWU

You need to copy this to /var/www/html/fog/service/ipxe and then run chown apache:apache init_partclone.xz to update file permissions.

We only have G6 laptops for imaging now, so I made this the default init under Fog Config > Fog Settings > TFTP Server > PXE BOOT IMAGE > enter init_partclone.xz. Alternatively, if you register hosts, you can add it to the host init section for just the G6 laptops.

You then have to edit the file /images/dev/postinitscripts/fog.postinit and add the line nvme set-feature -f 0x0c -v=0 /dev/nvme0

@Quazz That’s great - setting the nvme command in the fog.postinit file and making the init-partclone.xz you created the system wide default means we can now just pxe boot and select deploy image without issues. Huge improvement. Many thanks.

Edit: for clarification, it’s the nvme set-feature -f 0x0c -v=0 /dev/nvme0 command I’m using, not the latency one.

@Quazz We’ve tried that as well but doesn’t help. I think it’s also included in the Dev branch by default now which we’re tried.

@Sebastian-Roth said in Very slow cloning speed on specific model:

@darkxeno @dylan123 @Middle @oleg-knysh Build is done. Anyone keen to test?

sudo -i
cd /var/www/html/fog/service/ipxe
wget https://fogproject.org/kernels/bzImage-4.9.51
wget https://fogproject.org/inits/init-4.9.x.xz
chown apache:apache bzImage-4.9.51 init-4.9.x.xz

Sorry for the late update. This didn’t change anything I’m afraid. I’ve been a little reluctant in updating during testing as the results I’ve had have been very inconsistent. I can’t explain it, but the first deployment of the day works without issues - it’s happened too many times now to be a coincidence.

I’ve currently changed back to the master branch to clean-up the server of the test kernels/inits we’ve been using. The only consistent deploy I can get is using the init_partclone.xy that @Quazz posted on the 5th Dec, entering debug mode and running the following:

nvme set-feature -f 0x0c -v=0 /dev/nvme0

This works every time. The average transfer speed is around 3GB/min, rather than >10GB/min that I get from the master branch build when it randomly works, but that’s good enough for us as the result is consistent and the image is small anyway.

This is google drive link Quazz provided for the init: https://drive.google.com/open?id=1u_HuN5NSpzb7YmQBAsrzDELteNmlWUWU

I’ve had a look at the post init script option to see if I can automate this rather than entering debug, but I’m not really sure what I’m doing here.

@Sebastian-Roth said in Very slow cloning speed on specific model:

Can you please check if you actually have the exact same disk model?

Just checked, the disk is different. It’s Micron M.2 NVMe Gen3 x4 Model: MTFDHBA256TCK and the HP part number: L36057-001.

I’ll give Acronis a try this morning.

By removing the disk and adding to a HP 840 G5, we can image without issues (I think Duncan had this as well).

Unfortunately, nvme_core.default_ps_max_latency_us=0 hasn’t worked for me. I’ve tried both setting this manually via Host Kernel Argument using the default 1.5.7 kernel and updating to the latest dev-branch which seems to include it by default. Both result in slow transfer on an HP Elitebook 840 G6 (latest December BIOS).

Disabling APST using the init_partclone.xz and debug command that @Quazz posted gets an average transfer speed around 2.5GB/min which is a usable improvement. Is there a way to automate/improve this rather than entering debug mode each time to disable APST?

I haven’t been able to get the bzImage-4.9.51 and init-4.9.x.xz combo to work either (kernel panic with just bzImage-4.9.51 and partclone errors with both of them).

@DeRo93 We didn’t get the issue fixed but ran out of G6 laptops to test with. We’re expecting the next batch of 50 on Tuesday so I expect to be more active on here next week.

@Quazz No change I’m afraid with the pcie_aspm args (slow transfer rate). I didn’t spot any errors like we get with the latency one, however I do receive ‘is an unknown key’ when trying to add in debug mode. I’ve tired with both the 5.1.16 and 4.19.64 kernels.

Incidentally, if I have a kernel args set and I use debug mode, it always seems to stop at the ‘Restoring Partition Tables (GPT)’ section. Running a normal deploy at least moves onto the Partclone screen and eventually to a slow transfer rate.

I’ve also installed the Sept 27th HP BIOS and Firmware pack. I’m still looking for a firmware update specifically for the disk.

@george1421 Back in the office and just tried this. We get unknown key for the latency parameter.

grep nvme doesn’t return the value either and running fog gets stuck at the ‘Restoring Partition Tables (GPT)’ section, so didn’t get as far as Partclone. Note we’re using Kernel 5.1.16.

Thanks for helping out.

@george1421 sysctl exists and returns results. Using sysctl -a | more we still don’t see anything that’s setting the latency parameter.

@george1421 entered debug and the nvme_core parameter doesn’t appear to be set.

We’re getting the same slow deployment speeds when deploying images to HP Elitebook 840 Gen 6 laptops. All other laptops are fine. Before the deploy starts (at very slow speeds), it will hang at the initial Partclone screen for 10 - 15 mins.

@Sebastian-Roth & @george1421 - Below is a photo of the the ‘not a valid identifier’ error we see. It will also hang at this stage from time-to-time.

Below is the setting applied to the host in Fog.

We’re running CentOS 7.6 with Fog v1.5.7.4 and Kernel 5.1.16. I’ve tried with and without nvme_core.default_ps_max_latency_us=5500 set as the Host Kernel Arguments and Partclone 0.3.12 which @Quazz provided in another post.

The disks appear to be Toshiba NVMe kbg30zmv256g.

All suggestions welcome and happy to provide anymore info that might help troubleshoot.

@oleg-knysh has this continued to work for you? We have a very similar issue with the HP EliteBook 840 G6 laptops but running Fog 1.5.7.2 with Partclone 0.3.12 didn’t help us. All other laptops (Lenovos or 840 G5) work 100% of the time, but out of a batch of 20, only 2 G6 laptops imaged successfully - the rest hang on the initial partclone section or the image deploy is very slow. Hardware and BIOS are the same.

@Tom-Elliott said in Export and Import Images from different Fog servers:

1.3 rcs and trunk brought the capability to import and export elements individually where anything prior did not. So if you’re exporting or importing from one 1.3 to another you should be fine. In 1.2.0 and earlier only db export and host exports where available. 1.0.0 brought the db export capability which 0.32 and earlier did not have thus possibility.

Hopefully this helps define what you’re asking about.

Thanks Tom, exporting / importing the csv image list and using WinSCP to transfer the image files is working with 1.3 RC.

Just checking, is it possible to export an image captured by one Fog server and then import it into a different Fog server? Both will have the same version (1.3) and be completely isolated from each other with different config (IP, hostname etc).

Asking as a review of a (very) old version of Fog said it wasn’t possible.

Thanks.