Hosts not imaging - HELP

[Junkhacker]

@prestop i’m afraid there really aren’t any other options. if you have a lot of storage available on another computer, you could create a virtual machine to deploy it to (but that’s going to have some headaches involved too). i’m guessing the original drive was 500GB?

[prestop]

@Wayne-Workman
Yes - but there’s a lot of programs and things that I don’t know much about that appear to be in the image. I was hoping to be able to figure it out at some later date.

[Wayne Workman]

@prestop said in Hosts not imaging - HELP:

@Junkhacker
I don’t have any larger disks in this junkpile left behind.

Order one. They are cheap.

[Junkhacker]

or even borrow one. once you just need to recapture the image, you won’t need it permanently.

[prestop]

@Junkhacker I don’t think so - I think it was this machine, it was listed as a tester but I don’t know. All the machines he previously did were these dells with 250G drives. Strange.

[Junkhacker]

@prestop and what are you trying to deploy them to?

[prestop]

@Junkhacker same ones - Dells w/250G HDD. I’m trying a deploy w/debug now

[prestop]

@Junkhacker
So, these disks have 3 parts in them and the last one is too small on the device for the image stored? Does that sound right?

[Junkhacker]

@prestop from the errors you described before, that sounds right. the image size is too large for the disk. it runs out of space at the 3rd partition.

[Junkhacker]

@Junkhacker bare in mind that non-resizable is really strict about size. being smaller by just a tiny amount is enough for it to fail. there aren’t a lot of circumstances where i recommend it over resizeable

[prestop]

@Junkhacker Doesn’t make sense to me - he didn’t have any different computers. What is confusing is that the image on the server is alot smaller than 250G.

[Junkhacker]

@prestop that’s because of 2 things. partclone is file-system aware, and only copies the data in use, and fog compresses it.
however, a non-resizable image is a snapshot of the drive just as it existed on the source computer. when a resizeable image is created, a few more steps are taken before the image is uploaded, like shrinking the partitions down to the size of the data on the drives (plus some buffer space).

[prestop]

@Junkhacker Debug is on the /dev/sda2 now. I guess I find out at the next ENTER.

[prestop]

@Junkhacker
yep…says target partition is too small. I don’t understand that at all.

[Junkhacker]

@prestop if you look in the directory /images/MMHOptiplex7020/ what files do you see?

[prestop]

@Junkhacker
d1.mbr
d1p1.img
d1p2.img
d1p3.img

[Junkhacker]

@prestop oh, right, forgot that we didn’t add the additional files until later and these are from fog 1.2.0.
well, i think it’s obvious what the solution is. you’ll at least temporarily need a bigger drive to recapture this image, or you’re going to have to rebuild this image from scratch. when i say that non-resizable is really strict, i mean exact number of sectors or fewer for destination drive. that means if the source drive was 250Gb and the destination is 249.99GB, it won’t work. there is easily that much variation between drive models of the “same” size.

[prestop]

@Junkhacker does one of these files tell me how big the source drive was?

[Junkhacker]

@prestop not in any easy kind of way, not like an image from trunk would.

[Sebastian Roth]

@prestop I think I already told you that I can tell you the disk size if you upload the d1.mbr file to the forum… Or just run fdisk -l /images/MMHOptiplex7020/d1.mbr and post the full output here…