Win32 Disk Imager Creates an .IMG file that is too big to restore to identical media

Bug #912259 reported by Dennis Jackson
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Image Writer
New
Undecided
Unassigned

Bug Description

I used a SanDisk 4GB microSD card to create an Android (CyanogenMod 7.1) external boot card for a Nook Color. For backup purposes, I used Win32 Disk Imager (either v.3 or v.4, installed on a Windows Vista SP2 computer) to capture the image to a file, as the program permits. As a test, I then tried to restore that image, using Win32 Disk Imager, to another identical, new SanDisk 4GB microSD card. I get an error message telling me that there's not enough space on the new card. I then used a partition manager to unallocate some space on the source microSD card, figuring this would reduce the captured image size. I recaptured the image and tried again - same results. Windows reports that the captured image file size was not reduced on the second attempt, despite unallocating some space on the source microSD card. I then formatted the target microSD card using SDFormatter, and repeated the experiment; same results. Windows reports the captured image file as 3.79 GB in size; Windows also reports the size of a freshly-formatted 4GB microSD card as 3.68 GB. Obviously, the captured image is too large to fit on the target microSD card, but I am at a loss to determine why Win32 Disk Imager captures an image that then cannot be restored onto an identical microSD card, especially if there is unallocated space on the source microSD card!

I looked at the partitions of the source microSD card after going through the process of installing CyanogenMod to it. The image installer for this process, which must be done on the Nook Color, creates a mixed microSD card structure that contains the following:

Partition Type Size
1 FAT32 415.71 MB
2 EXT4 462.81 MB
3 EXT4 964.84 MB
4 FAT32 all remaining space

Reported Total Size: 3.79 GB

So, I can see where the image size of the image that Win32 Disk Imager creates comes from, but the target (blank) microSD card needs to be formatted to get a drive letter for use with your program, and the maximum size that I can seem to get with any microSD card formatting program that I'm aware of (including Windows) is 3.68 GB! While common sense tells me that I should be able to restore an image to an identical microSD card for backup and restore purposes, it appears that your program does not permit that, either due to error or by design.

Revision history for this message
Tobin Davis (gruemaster) wrote :

win32-image-writer works with the raw device for reading & writing, so partition sizes should be irrelevant. I'll look into the issue with not enough space.

Part of the problem is figuring out how big the raw device is (in Windows). I can do this easily in linux, but that doesn't help here.

Revision history for this message
Magnus Karlsson (u-magnds-b) wrote :

See Bug #932321: getNumberOfSectors() returns incorrect number

The program is using an incorrect way to figure out the raw device size. The correct way is to ask for the partition size of the raw disk rather than trying to use the disk geometry information (like cylinders, tracks/cylinder, sectors/track) to figure out the device size since those numbers are just made up by windows to give an approximation of the disk size. There is no size information on the SD card about "cylinders" or "tracks" etc, just the raw block count (1 block = 512 bytes = 1 "sector").

Revision history for this message
Dennis Jackson (dennis-m-jackson) wrote : Re: [Bug 912259] Re: Win32 Disk Imager Creates an .IMG file that is toobig to restore to identical media
Download full text (5.8 KiB)

Magnus -

     Thanks for the information update! Obviously, the author(s) of the
program focused on hard disk technology as their target environment, rather
than considering the expanded number of other types of storage devices - an
understandable situation. My temporary workaround is to use v.1 of the
program - it does not do the size check for available space on the target SD
card that versions .3 and above do. If you use a partition manager to
de-allocate some space on the SD card (I use the difference between what
Win32 Disk Imager reports as the image size and what Windows reports as the
capacity of the device, plus a little extra), and then capture the image,
the resulting image captured still reports the same size as I reported
previously (too large for an identical SD card), but v.1 of the program
happily writes the image to that SD card until it runs out of space. Since
that "lost" part of the image has no meaning, what is not written doesn't
matter. So far, that seems to be working for me when capturing and image
from an SD card and writing that image back to an identically-sized SD card
as a backup. Obviously not the perfect solution, but it works in that
particular set of circumstances.

     There's a very active community to create an Android CyanogenMod
external boot card for the Nook Color; Win32 Disk Imager is one of the
recommended tools used in the process of creating the card, and there are a
lot of problems reported when trying to make a backup SD card image that can
be written to an identically-sized SD card once the image building process
is complete. You can write the Win32 Disk Imager image to a larger-sized
card, of course, but that workaround is more expensive, and if you create an
image for a 32GB SD card (the maximum size card that the Nook Color will
accommodate), you're out of luck backing it up unless you use the workaround
I described above.

     Again, thanks for your attention to this issue and your efforts! I'll
post the information (crediting you, of course) and the workaround to the
various forums that support the Nook 2 Android CyanogenMod process.

Regards,
Dennis

----- Original Message -----
From: "Magnus Karlsson" <email address hidden>
To: <email address hidden>
Sent: Wednesday, February 15, 2012 10:45 AM
Subject: [Bug 912259] Re: Win32 Disk Imager Creates an .IMG file that is
toobig to restore to identical media

See Bug #932321: getNumberOfSectors() returns incorrect number

The program is using an incorrect way to figure out the raw device size.
The correct way is to ask for the partition size of the raw disk rather
than trying to use the disk geometry information (like cylinders,
tracks/cylinder, sectors/track) to figure out the device size since
those numbers are just made up by windows to give an approximation of
the disk size. There is no size information on the SD card about
"cylinders" or "tracks" etc, just the raw block count (1 block = 512
bytes = 1 "sector").

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/912259

Title:
  Win32 Disk Imager Creates an .IMG file tha...

Read more...

Revision history for this message
Tobin Davis (gruemaster) wrote :

Dennis (and everyone else following this), The problem is not that anyone focused on hard drives when writing this code. The original developer and myself are Linux developers. This code was originally written to help with installing Jaunty Netbook Remix on netbooks w/o cd. The image was designed to be flashed directly to usb. At the time, there wasn't an easy way to do this in Windows.

The original program was released from concept to working over a weekend. It took a lot of research on Microsoft's devnet to get the functions we have. To be honest, I have not been able to reproduce the errors everyone is seeing, and I test on a multitude of SD/uSD/CF/USB flash devices on XP and Windows 7 (this and taxes are the only reasons I still have Windows).

As we go forward, most of the recent features/fixes have come from outside developers (many thanks to them). The original author has been off on other long term projects, but will try to pick up again this year. In the meantime, I try to pull in changes, test, and release. This fix has now been pulled into my tree. As soon as I do a build & test here, I will push rev .5 (hopefully this week).

Revision history for this message
Dennis Jackson (dennis-m-jackson) wrote :
Download full text (4.7 KiB)

Hello -

     I just finished testing Win32 Disk Imager v.5 in reference to this
issue. Results are identical to what I initially reported when I opened
this trouble ticket - Win32 Disk Imager is creating an image that is too big
to write to identical media. To test, I first successfully captured an
image that I have on a SanDisk 4GB Class 2 SD card. Size of the captured
image was reported by Windows Explorer as 3.79 GB. I formatted an identical
SanDisk 4GB Class 2 SD card using SD Formatter v3.1, and checked its
capacity in Windows Explorer. Windows Explorer reported the capacity as
3.68GB. I attempted to write the captured image onto the newly formatted SD
card; Win32 Disk Imager failed, reporting that there was not enough space on
the SD card to write the image. This report also affects #932321. As the
results of the latest test were identical to those that I initially
reported, are you sure that the fixes were applied to the latest released
version? There was an issue (reported in #187903) with missing DLL's in the
version of .5 that was initially distributed. Knowing that configuration
management is a tricky business at best, is is possible that the reported
fixes did not make it into the second "release" of v.5? Just checking! If
that's not the case, then the fixes applied to create v.5 to address #912259
(reclassified as a duplicate of #932321) did not solve the issue I reported.

----- Original Message -----
From: "Tobin Davis" <email address hidden>
To: <email address hidden>
Sent: Wednesday, February 15, 2012 11:33 AM
Subject: [Bug 912259] Re: Win32 Disk Imager Creates an .IMG file that is
toobig to restore to identical media

*** This bug is a duplicate of bug 932321 ***
    https://bugs.launchpad.net/bugs/932321

** This bug has been marked a duplicate of bug 932321
   getNumberOfSectors() returns incorrect number

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/912259

Title:
  Win32 Disk Imager Creates an .IMG file that is too big to restore to
  identical media

Status in Image Writer for Windows:
  New

Bug description:
  I used a SanDisk 4GB microSD card to create an Android (CyanogenMod
  7.1) external boot card for a Nook Color. For backup purposes, I used
  Win32 Disk Imager (either v.3 or v.4, installed on a Windows Vista SP2
  computer) to capture the image to a file, as the program permits. As
  a test, I then tried to restore that image, using Win32 Disk Imager,
  to another identical, new SanDisk 4GB microSD card. I get an error
  message telling me that there's not enough space on the new card. I
  then used a partition manager to unallocate some space on the source
  microSD card, figuring this would reduce the captured image size. I
  recaptured the image and tried again - same results. Windows reports
  that the captured image file size was not reduced on the second
  attempt, despite unallocating some space on the source microSD card.
  I then formatted the target microSD card using SDFormatter, and
  repeated the experiment; same results. Windows reports the captured
  image file as 3.79 GB in ...

Read more...

Revision history for this message
Jeff Holverson (jhansx) wrote :

Lots of verbage in the comments. Using a 32 Gb card to create an image I get an image that will not load onto an identical 32 Gb card formatted with SDFormatter as directed on several websites. THe message says the image is too large to fit on the target SD card but that there does not appear to be aby data ad I get and option to go ahead anyway, I do nd the SD will not boot in my RPI.
Why is this still a problem and what do I do to ise it? HO THE F$W% are you guys universally recommended to clone SD cards for RPI if the program doesn't work?
<email address hidden>
KG7TXI
Please contact with a solution or work around.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.