Image capture issues
-
I am running FOG 1.5.6 on Ubuntu 18.04. I am trying to capture an image of an HP SFF EliteDesk, with an AMD processor, running Windows 10 pro. When I PXE boot I can do the full register/Inventory. Then on the console I can create a task to capture the image. The problem is when I try to reboot the host machine and attempt to capture said image. It stops at Reading Partition Tables and wont go any further. I have tried setting the image on the console to single partition resizable and multi-partition not resizeable and get the same result.
Any help would be greatly appreciated.
As I side note, I have been able to capture a windows 10 image from an Intel based machine.
-
We had the exact same issue with a very similar model of machine, specifically in our case an HP EliteDesk 705 G4 Mini. Same behaviour as OP with respect to image capture. Image deployment would also error out but we would at least get an error message, specifically
nvme nvme0: failed to set APST feature (-19)
One of the guys here ran into this before with his own machine, he fixed it here by adding the following to the kernel arguments of the host in the web console:
nvme_core.default_ps_max_latency_us=200
I guess there’s a known issue with APST and nvme drives, we grabbed the info from here: https://askubuntu.com/questions/1099048/18-04-and-18-10-fail-to-boot-nvme0-failed-to-set-apst-feature-19
-
@jlthompsonpsd I am fairly sure this is not a Intel vs. AMD issue. It’s simply that the disk/disk controller is not being recognized on the AMD platform.
Is it set to RAID or AHCI in the BIOS/UEFI setup?
Please take a picture of the error you get on screen and post here.
-
I have not been able to find in the BIOS where I can make those kinds of changes.
There are no error messages to forward. It just hangs indefinitely at Reading Partition tables.
-
@jlthompsonpsd said in Image capture issues:
There are no error messages to forward. It just hangs indefinitely at Reading Partition tables.
How long have you waited?
Please schedule a fresh task for this host but this time tick the check box for debug! Boot up the client, hit ENTER twice to get to the shell. Now run the following command to find out which disk is being recognized:
lsblk
Now with that run the following commands as well to see which one is the one that hangs:
udevadm settle blockdev --rereadpt /dev/... lsblk -I 3,8,9,179,202,253,259 -lpno KNAME,TYPE /dev/...
For the
blockdev
command you need to put in the correct disk device name that you got from the initiallsblk
. Maybe it’s/dev/sda
or/dev/nvme0n1
or … -
We had the exact same issue with a very similar model of machine, specifically in our case an HP EliteDesk 705 G4 Mini. Same behaviour as OP with respect to image capture. Image deployment would also error out but we would at least get an error message, specifically
nvme nvme0: failed to set APST feature (-19)
One of the guys here ran into this before with his own machine, he fixed it here by adding the following to the kernel arguments of the host in the web console:
nvme_core.default_ps_max_latency_us=200
I guess there’s a known issue with APST and nvme drives, we grabbed the info from here: https://askubuntu.com/questions/1099048/18-04-and-18-10-fail-to-boot-nvme0-failed-to-set-apst-feature-19
-
@Chris-J Interesting, that appears to be a bug on Samsung SSDs, perhaps there are firmware updates that resolve it by now.
-
@Sebastian-Roth Do you see any risk to add this into FOS’s sysconfig? The question I would have is what is the default and what are the risks to shorten the latency to
nvme_core.default_ps_max_latency_us=200
Searching the kernel paths I see the default set to this
default_ps_max_latency_us = 100000;
As set in drivers/nvme/host/core.c
-OR-
should this setting just be set as a host specific kernel parameter? I can make a case either way. I just don’t know if there are any negative impacts on systems where this isn’t a problem. -
@george1421 Trying to read up on this topic I figured that this is not new. Samsung itself has been involved since March 2017!! But seems like this is still the case even with newer kernel versions and other Samsung drives: https://bugzilla.redhat.com/show_bug.cgi?id=1624611
As far as I understand it the lower you set the value of
default_ps_max_latency_us
the more power is consumed. Not sure if we want to set this by default for everyone.@jlthompsonpsd Can you please post the exact machine model you have as well as run
smartctl -i /dev/nvme0
in a debug capture task console and post a picture of the output here?