Linux on nvme drive: Failed to read back partitions (runPartProbe)

[ismith.hpu]

Also a video format:

[Tom Elliott]

Just to clarify,

I’ve modified the function so that we use the system’s own access to the partition and disk information to retrieve the disk directly.

The function was updated to use this, but I forgot to strip the /dev/ from the passed partition.

This meant that it was looking for the link of:

/sys/class/block/$part which in this case was being translated as /sys/class/block/dev/nvme0n1p1 but the link was found in /sys/class/block/nvme0n1p1

Stripping the /dev/ from the passed partition should fix this, and leave us with a more universal FOS methodology of obtaining the disk from the partition.

Hopefully this helps everybody.

[george1421]

If you could boot this into debug mode and then run the following command lsblk That will tell us what FOS sees for the local block devices.

Also what target hardware (mfg and model) is this?

[ismith.hpu]

@george1421

This is a Dell Aurora7 (R7) desktop with an nvme drive, I have flashed back to this device before and it worked perfectly.

the lsblk command shows the following:

sda - 1TB drive for storage but had ubuntu installed on it before.
nvme0n1 - Ubuntu Boot
nvme0n1p1 - grub I am assuming
nvme0n1p2 - boot partition for Ubuntu 18.04LTS

[Tom Elliott]

As I worked with you on this in a separate instance I know right now you’re running a modified funcs.sh coming from master and injecting it through postinitscripts.

I forgot a small portion of the update to the getDiskFromPartition function that was modified originally.

I’ve add this in.

Please update your postinit funcs.sh with:

wget -O /images/dev/postinitscripts/funcs.sh https://raw.githubusercontent.com/FOGProject/fos/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh

This should fix the disk being returned as null.

Thank you,

[Tom Elliott]

Just to clarify,

I’ve modified the function so that we use the system’s own access to the partition and disk information to retrieve the disk directly.

The function was updated to use this, but I forgot to strip the /dev/ from the passed partition.

This meant that it was looking for the link of:

/sys/class/block/$part which in this case was being translated as /sys/class/block/dev/nvme0n1p1 but the link was found in /sys/class/block/nvme0n1p1

Stripping the /dev/ from the passed partition should fix this, and leave us with a more universal FOS methodology of obtaining the disk from the partition.

Hopefully this helps everybody.

[ismith.hpu]

@Tom-Elliott

I have downloaded it and will try it in the office tomorrow.

[ismith.hpu]

@Tom-Elliott This did resolve the issue.