Failure during image deployment.

[Wayne Workman]

@Tom-Elliott Sourceforge is undergoing scheduled maintenance. Their site said 40 minutes.

[drc0nc]

@Tom-Elliott Thank you very much. testing now

[wyssaj01]

@drc0nc

I’m seeing the same error here at the bottom of the screen about No osid passed. I’ll test the fix and update shortly.

Mod edited.

[drc0nc]

@Tom-Elliott new issues with a deployment.

[wyssaj01]

Imaging now works for me again. Thanks for the quick fix!

[drc0nc]

This post is deleted!

[davisadamj01]

@Tom-Elliott

Ran installer again and the problem is resolved. Thanks much for the quick fix.

[Wayne Workman]

@drc0nc How about you?

[drc0nc]

@Wayne-Workman passed the no osid. but I’m currently having issues with partitions. tom is currently helping me on it. still stuck on the performRestore.

[Tom Elliott]

@drc0nc Fixed through teamviewer YAY!.

I’ve released the code and updated the init’s

Please update and hopefully all these issues will now be fixed.

[Fernando Gietz]

Hi,

I updated the version to 6237 and with images which have one disk, this version works fine but if the image has two disks, no.

The files in the server are:

[Fernando Gietz]

I have updated the version to cloud 6339, and when I try to upload a multidisk image, the upload process fails when the first partition of the second disk.

First disk: Windows7

d1.partitions 
label: dos
label-id: 0x42e8d3f9
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      159744, type=7, bootable
/dev/sda2 : start=      161792, size=   234278912, type=7

Second disk: windows7

d2.partitions 
label: dos
label-id: 0x000b6c36
device: /dev/sdb
unit: sectors

/dev/sdb1 : start=        2048, size=   312494080, type=7

Files in /images/dev/MAC/

-rw-r--r-- 1 root root    1048576 feb 19 19:20 d1.mbr
-rw-r--r-- 1 root root    8820297 feb 19 19:20 d1p1.img
-rw-r--r-- 1 root root 5167660345 feb 19 19:27 d1p2.img
-rw-r--r-- 1 root root        190 feb 19 19:20 d1.partitions
-rw-r--r-- 1 root root    1048576 feb 19 19:27 d2.mbr
-rw-r--r-- 1 root root         20 feb 19 19:27 d2p1.img.000
-rw-r--r-- 1 root root        122 feb 19 19:27 d2.partitions

The first disk uploads well, but when the parclone tries to upload the first partition of the second disk, it crashs.

Failed to complete upload (savePartition)
Args passed: /dev/sdb1 2 /images/0025b3149ac6 all

[Sebastian Roth]

@Fernando-Gietz Wow, partclone actually crashed?? From the directory listing it really looks like it - d2p1.img.000 would be moved to d2p1.img after partclone has finished properly. Any error you see when partclone closes?? Maybe the second disk is gonna die soon?

[Tom Elliott]

@Fernando-Gietz maybe free space?

[Fernando Gietz]

Curously the upload and download of image of two disks worked well.

You can see my report in:
https://forums.fogproject.org/topic/6473/possible-bug-when-you-upload-the-image-from-a-second-disk-5844

But now, crashed completely I will try to upgrade to the last version

[Fernando Gietz]

After a complex update process

Now the problem is the partclone, doesn’t detect well the partition type.

 more 0025b3149ac6/d2.partitions 
label: dos
label-id: 0x000b6c36
device: /dev/sdb
unit: sectors

/dev/sdb1 : start=        2048, size=   312494080, type=7

[Sebastian Roth]

@Fernando-Gietz Before update partclone crashed on sdb1 and now we see ‘ntfs mount error’. I really wonder what’s wrong with this disk/partition/filesystem…???

Asking google for this error I only found something about encrypted data. Is your second disk encrypted?? https://sourceforge.net/p/clonezilla/feature-requests/40/

Edit: Tried filesystem check on sdb1??

[Fernando Gietz]

Ok. Actually works fine with the version 6371. The second disk filesystem was corrupted

No, my second disks was not encrypted.

[Wayne Workman]

@Fernando-Gietz said:

The second disk filesystem was corrupted

I’d estimate that 5 to 10 percent of imaging issues encountered are due to a bad HDD.

[Sebastian Roth]

@Wayne-Workman said:

I’d estimate that 5 to 10 percent of imaging issues encountered are due to a bad HDD.

Yeah right! We’ve seen this “quiet often” lately… Good to know that it wasn’t FOG doing something wrong.

So all issues here seam fixed now… solving this!