Error Uploading image - Failed to read back partitions (runPartprobe)

[Thiago]

I’m trying to upload a new image on a new fog server installed on Debian 8.
My fog svn version is r4699, cloud 6064.
My image settings are
OS: Linux (but the system is dual boot, mbr)
Single Disk - Resizable - (1)
Partition: Everything
The computer has only one disk, and stop on this error:

Any help will be apreciated.
tks.

[Wayne Workman]

@Thiago This may not apply to the new upload scripts, but previously, dual boot systems had better luck with non-resizable type images. And even then, there was a lot of difficulty.

[Tom Elliott]

The best guess I can have with this. That image looks like it’s from an upload, which is expected, but the partition has NOTHING on it.

I don’t know if this really is the case, but it certainly feels like it is.

If you can get the client into a debug task, what’s the output when you run:

source /usr/share/fog/lib/funcs.sh
getHardDisk
runPartprobe "$hd"

I suspect it will fail as well, and if that is the case, what’s the output (after that) of:

udevadm settle
blockdev --rereadpt $hd

[Thiago]

@Wayne-Workman said:

@Thiago This may not apply to the new upload scripts, but previously, dual boot systems had better luck with non-resizable type images. And even then, there was a lot of difficulty.

In 1.2 version, it always worked, and the disk resizable too. I will try using non-resizable, thanks for the tip,

@Tom-Elliott said:

The best guess I can have with this. That image looks like it’s from an upload, which is expected, but the partition has NOTHING on it.

There are 4 primary partitions, (winre, C:, swap, /) and its works in 1.2. (tested now).

@Tom-Elliott said:
If you can get the client into a debug task, what’s the output when you run:

i´ll try it but now is out of working hours…
“I will be back” with my results.
Thanks a lot again to all fog team/community.

[Tom Elliott]

@Thiago through working with others experiencing similar issues at the runPartprobe stage, I learned this was because a partition of the disk being rescanned was still mounted somewhere. I’ve added a few checks to umount the potential issues and made many more improvements, I think, to the init scripts. With any luck we can solve this thread when tested again. Thank you.

[Thiago]

@Tom-Elliott
update and no success runnning upload task directly. It returns with the same error.
In debug task, running commands that you listed:
getHardDisk -> after this, echo $hd returns “sda”
runPartprobe -> the same error, and logout, so i have to source funcs.sh again an rerun getHardDisk.
udevadm settle -> returns 0 when echo $?
blockdev --rereadpt $hd -> returns: blockdev: cannot open sda: No such file or directory

[Tom Elliott]

@Thiago What is the exact output of echo “$hd” after sourcing? It should NOT only be “sda” but rather “/dev/sda”

[Thiago]

@Tom-Elliott
Returns only sda.

[Tom Elliott]

Found that this system, through teamviewer, had the Host Primary Device labeled literally as ‘sda’ rather than a full path, or an automated picked up path.

This should be fixed as well now by simply removing the field, or using the full device descriptor.

[george1421]

@Tom-Elliott That’s really strange.

Really just thinking out loud here: Was/Is this a one off situation or something you need to trap so that it doesn’t happen in the future? Also is there an embedded script that could be run to display conditions like this when run from the debug console?

[Thiago]

Thank you Tom. It’s my fault…
When i edited host definition,did not pay attention to host primary disk.
Sorry for taking your time. (others too)
Thanks a lot.

[Tom Elliott]

@Thiago It’s all good. Don’t feel like you did anything wrong. It’s why we asked the questions we did, and now we know why the problem occurred, and it made me ensure the code base was good to go too.