Deleted file/folder, broke file copy

  1. 9 months ago
    Edited 9 months ago by vbourke

    I haven't had time to tinker with the clonedeploy server lately, haven't even had the time to do the update until this thing started happening. Out of nowhere, it looks like the UUIDs are shifted sda number down when processing the file copy, so nothing gets copied. Here's what I mean:

    sda1 has a uuid of 74623DC7623D8F3C, but during the file copy phase, it spits out this:

    { "Compression": "lz4", "EfiBootLoader": "", "FileSystem": "ntfs", "Guid": "", "ImageType": "Block", "Number": "2", "PartcloneFileSystem": "ntfs", "Prefix": null, "Type": "primary", "Uuid": "125441FE5441E4D7", "VolumeGroup": null }

    and doesn't actually copy anything. Then when sda2 goes, which has a uuid of 125441FE5441E4D7, it spits out this and doesn't copy any files:

    { "Compression": "lz4", "EfiBootLoader": "", "FileSystem": "ntfs", "Guid": "", "ImageType": "Block", "Number": "3", "PartcloneFileSystem": "ntfs", "Prefix": null, "Type": "primary", "Uuid": "D274A9B774A99EAB", "VolumeGroup": null }

    Then sda3 has no output during the file copy phase. What makes it even stranger, is in the very beginning before it says "** Starting Image Download For /dev/sda1 **", it says this:

    file_copy_schema: profileId=29

    { "Compression": "lz4", "EfiBootLoader": "", "FileSystem": "ntfs", "Guid": "", "ImageType": "Block", "Number": "1", "PartcloneFileSystem": "ntfs", "Prefix": null, "Type": "primary", "Uuid": "74623DC7623D8F3C", "VolumeGroup": null }

    Was happening on 1.2.1 as well as 1.3.3 after I upgraded. I'd imagine its not copying files because its trying to copy to a UUID that hasn't been setup yet, but what would cause this?

    Looks like a bug. A file/folder was probably deleted while it was still assigned to a profile. Deleting a file/folder should also remove any assignments in the image profile but looks like that's not happening. Based on the table output you sent me. This should take care of it.

    mysql -uroot -p clonedeploy --execute "delete from image_profile_files_folders where file_folder_id in (1,2,3,4,5,6,11,32);"

    You may want to backup the db first.

  2. clonedeploy

    12 Feb 2018 Administrator

    I don't think this is related to the file copy issue, this info has to do with imaging. If you put them in order then the uuids seem to match. You said before it says starting image download for /dev/sda1 it says:

    { "Compression": "lz4", "EfiBootLoader": "", "FileSystem": "ntfs", "Guid": "", "ImageType": "Block", "Number": "1", "PartcloneFileSystem": "ntfs", "Prefix": null, "Type": "primary", "Uuid": "74623DC7623D8F3C", "VolumeGroup": null }

    Followed by

    { "Compression": "lz4", "EfiBootLoader": "", "FileSystem": "ntfs", "Guid": "", "ImageType": "Block", "Number": "2", "PartcloneFileSystem": "ntfs", "Prefix": null, "Type": "primary", "Uuid": "125441FE5441E4D7", "VolumeGroup": null }

    and finally

    { "Compression": "lz4", "EfiBootLoader": "", "FileSystem": "ntfs", "Guid": "", "ImageType": "Block", "Number": "3", "PartcloneFileSystem": "ntfs", "Prefix": null, "Type": "primary", "Uuid": "D274A9B774A99EAB", "VolumeGroup": null }

    If you follow this order each partiton number matches the uuid. So I suspect something else is happening.
    Can you attach the entire deploy log?

  3. Maybe I wasn't explaining it right. Either way, the file copy stopped working for some reason out of the blue. Nothing was changed as far as I'm aware.

  4. clonedeploy

    12 Feb 2018 Administrator

    According to the log it's not finding anything defined in the image profile to copy. Can you post a screenshot of the filecopy settings for whatever profileid is 29?

  5. There's a lot more. But it's across all of the profiles, I tried deploying other machines under other profiles and it says the same thing.

  6. clonedeploy

    12 Feb 2018 Administrator

    Ok, I don't see anything odd. Lets try to add some extra logging.
    Admin->Core Scripts->Select lie_deploy from the drop down
    Find this line:

    file_copy_schema=$($curlAuth --data "profileId=$profile_id" "${web}GetFileCopySchema" $curlEnd)

    Then right below it add:

    log "File Copy Schema: $file_copy_schema"

    Click update

    Final result should look like:

    if [ "$file_copy" = "True" ]; then
        log "file_copy_schema: profileId=$profile_id"
    	 file_copy_schema=$($curlAuth --data "profileId=$profile_id" "${web}GetFileCopySchema" $curlEnd)
    	 log "File Copy Schema: $file_copy_schema"
      fi

    Deploy the image again, and attach the new log.

  7. clonedeploy

    12 Feb 2018 Administrator

    Could you also export your files_folders table?

    mysql -uroot -p clonedeploy --execute "select * from files_folders;" > files_output.log
  8. Looks promising

  9. clonedeploy

    12 Feb 2018 Administrator Answer
    Edited 9 months ago by clonedeploy

    Looks like a bug. A file/folder was probably deleted while it was still assigned to a profile. Deleting a file/folder should also remove any assignments in the image profile but looks like that's not happening. Based on the table output you sent me. This should take care of it.

    mysql -uroot -p clonedeploy --execute "delete from image_profile_files_folders where file_folder_id in (1,2,3,4,5,6,11,32);"

    You may want to backup the db first.

  10. Edited 9 months ago by vbourke

    Yeah, there was a piece of software that we didn't need anymore, so I removed it. That was like 4 weeks ago though. Looks like that did it, thanks for your help!

 

or Sign Up to reply!