Target partition size is smaller than source

contewit · Jun 16, 2015, 6:30 PM

Hello again,

I’ve progressed beyond making images and have moved to testing out the deployment aspect. I attempted to deploy the image a different laptop (but identically configured - even purchased at the same time), but on the first partition partclone fails with an error

Target paritition size (41 MB) is smaller than source (42 MB).  Use option -C to disable size checking(Dangerous).

Debugging assistance welcome! Where do i look to try and solve this, or what information do you need to help debug?

Thanks!

Edit: This deployment was done using latest trunk (3563); images were crated with 3540

Tom Elliott · Jun 17, 2015, 12:57 AM

What’s the output, from FOG Server of the images d1.original.partitions and d2.original.partitions?

contewit · Jun 17, 2015, 1:13 AM

$ cat d1.original.partitions
label: dos
label-id: 0x552e1400
device: /dev/sda
unit: sectors

/dev/sda1 : start=          63, size=       80262, type=de
/dev/sda2 : start=       81920, size=    20423324, type=7, bootable
/dev/sda3 : start=    24686592, size=   952084480, type=7

I don’t have a d2.original.partitions file.

Wayne Workman · Jun 17, 2015, 2:55 AM

Your partition table looks to be in order, I am assuming that the big partition is 24.7 gig ?

Maybe run fixparts on the destination drive? to do that, you’d do a debug download and run ‘fixparts’ from CLI.

contewit · Jun 18, 2015, 3:51 PM

On the original disk, the partitions are 41.1MB, 10.5GB, and 487GB, respectively along sda[123].

On the fog server, the .img files are 79k, 8.2G, and 17G, respectively.

contewit · Jun 18, 2015, 4:43 PM

Also, for reference; minimum partitions:

$  cat d1.minimum.partitions
label: dos
label-id: 0x552e1400
device: /dev/sda
unit: sectors

/dev/sda1 : start=        63, size=     80262,  type=de
/dev/sda2 : start=     81920, size=  20423324,  type=7, bootable
/dev/sda3 : start=  24686592, size=  88663008,  type=7

contewit · Jun 22, 2015, 3:55 PM

Any other thoughts or ideas to try and help debug this?

g.chanaud · Jun 23, 2015, 10:30 AM

Is it the same problem as i described here ?
https://forums.fogproject.org/topic/5165/partition-size-too-little-with-a-single-disk-resizable-image-svn-3537

Can you compare your d1.minimum.partitions with the output of a

fdisk /dev/sda -lu

Tom Elliott · Jun 23, 2015, 10:54 AM

@g.chanaud I could be wrong, but the d1.minimum.partitions and d1.original.partitions are both displayed here.

What I do notice, both of these forums are working from an image with a start sector of 63.

What’s most interesting to me, is the fdisk shown size, vs. the d1.minimum.partitions size are two different numbers.

In contewit’s particular case, it’s down by one meg.

g.chanaud · Jun 23, 2015, 1:14 PM

Hi Tom,

the OP showed both d1.minimum.partitions and d1.original.partitions but not the output of the real partitions size created by the scripts, as it could be shown with a fdisk, that’s why i asked him to post the output, to compare theory VS reality, to be sure it’s the same problem.
As we can see the first partition is a dell Utility partition (type de) like in my case. Maybe this is a particular dell behavior…

Tom Elliott · Jun 23, 2015, 1:33 PM

I’m nearly certain it’s specific to Dells at this point. I have others who’ve told me they have seen similar problems and fixed the problem by doing a full reinstall.

I’m not requesting you do this as I’d much rather have an imaging system that just works regardless of the layout of a disk.

ch3i · Jun 23, 2015, 1:37 PM

@Tom-Elliott said:

I’m nearly certain it’s specific to Dells at this point. I have others who’ve told me they have seen similar problems and fixed the problem by doing a full reinstall.

I’m not requesting you do this as I’d much rather have an imaging system that just works regardless of the layout of a disk.

Manufacturers installations >> crap lol

Wayne Workman · Jun 23, 2015, 5:47 PM

@Tom-Elliott said:

I’m nearly certain it’s specific to Dells at this point. I have others who’ve told me they have seen similar problems and fixed the problem by doing a full reinstall.

I’m not requesting you do this as I’d much rather have an imaging system that just works regardless of the layout of a disk.

Just adding to your hunch… I was dealing with this exact same error at another location this morning and yesterday afternoon.

It’s on Dell 7010s.

A little information… the image is not a scratch image, it had three partitions. System reserved, recovery, and the primary Windows partition.

The image had been uploaded and downloaded several times in the last two-ish years through Norton GHOST.

MORE info - these Dells came with a custom image installed on them at the processing center before they were shipped to us. I don’t know what methods the processing center uses to clone HDDs.

Building an image from scratch does fix the issue… and I really dislike re-using old images, but it was sorta necessary in this special case. We still don’t have it figured out. We removed the recovery partition, fixed the MBR to boot windows properly, and it still bombs out when restoring.

I’ve also tried RAW… no dice.

Wayne Workman · Jun 23, 2015, 6:01 PM

Think I found something on it…

The Dell-specific Ctrl+F11 process is supposed to completely automate the restoration process, returning the hard disk to the state it was in when Dell shipped the computer. However, overwriting the MBR by using a boot manager, using the commands “fixmbr” or “fdisk /mbr”, installing from a Windows installation CD, and assorted other tasks a user might do will inadvertantly break Ctrl+F11, rendering the system unable to boot the DSR partition. Furthermore, changing the partitioning by adding, deleting, or resizing partitions will cause DSRcheck to fail, so even if Ctrl+F11 works, the restore process will abort without attempting to restore the Ghost image.

These may include, but are not limited to, using cloning/imaging products like Symantec Ghost, PowerQuest Drive Image, Acronis True Image, TeraByte Image or BootIt-NG, and others.

http://www.goodells.net/dellrestore/fixes.shtml

Seems like a good starting place for solving this…

Wayne Workman · Jun 23, 2015, 6:07 PM

Oh, to make it clear what the problem is, this dell specific Ctrl+F11 recovery thing is causing a mismatch in MBR size.

Of course, a scratch image works fine though.

contewit · Jun 23, 2015, 6:15 PM

# fdisk /dev/sda -lu

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x552e1400

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63       80324       40131   de  Dell Utility
Partition 1 does not start on physical sector boundary.
/dev/sda2   *       81920    20505243    10211662    7  HPFS/NTFS/exFAT
/dev/sda3        24686592   976771071   476042240    7  HPFS/NTFS/exFAT

Wayne Workman · Jun 23, 2015, 6:25 PM

@Developers is there anything we can do to manually make the imaging process make the MBR bigger by one meg? Can we swap around the figures in d1.minimum.partitions ?

contewit · Jun 25, 2015, 5:39 PM

Is there a debug process where I can show/record the commands that are being executed on the imaged machine? It would make it easier to debug the script.

Thanks.

Wayne Workman · Jun 25, 2015, 10:00 PM

@contewit You might not need to worry about it. I’m currently in the process of getting one of these broke Dell images to Tom, and he’s going to mess around with it.

For the commands being executed, I don’t think there is any method to “show” them… However, if you look into the several scripts that are used, they all have variables. Those begin with $ signs.

You can echo the contents of variables like this:

echo $VariableNameIsCaseSensitive

Check this out, too: http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-5.html

Target partition size is smaller than source

167

12.0k

17.3k

155.1k