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



  • 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:
    0_1453494149557_IMG_0439.JPG
    Any help will be apreciated.
    tks.


  • Senior Developer

    @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.



  • 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.


  • Moderator

    @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?


  • Senior Developer

    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.



  • @Tom-Elliott
    Returns only sda.


  • Senior Developer

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



  • @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


  • Senior Developer

    @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.



  • @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.


  • Senior Developer

    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
    

  • Moderator

    @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.


Log in to reply
 

462
Online

38710
Users

10539
Topics

99781
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.