Target partition size is smaller than source

[g.chanaud]

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]

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]

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

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

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]

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]

# 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]

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

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]

@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