C: with windows 7 partition erased with all data

Bug #985080 reported by djhell
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Image Writer
Fix Released
Critical
Tobin Davis

Bug Description

After writing some IMG to a USB device, ImageWriter stopped work putting an error like:
"unable to release volume"
I tried rebooting and tada... The IMG was burned on my C drive, so I lose all my data.
I'm sure C was not in the selectable drives, but this happened.

D.

Revision history for this message
djhell (hellismyhouse) wrote :

sorry, I used version 0.6 on windows 7 professional.

D.

Tobin Davis (gruemaster)
Changed in win32-image-writer:
importance: Undecided → Critical
Revision history for this message
Jeff B (skydiver38) wrote :

I don't really know what to say about this - ImageWriter ignores all drives that are not on the USB bus, unless they report themselves as "removable". As any system disk is "fixed" and NOT on the USB bus, I can't see how this would have happened.

Revision history for this message
djhell (hellismyhouse) wrote :

I know. But I'm also sure my C drive was flashed :D

I'm testing now the 0.5 with some fixes from 0.6 on a virtual machine without problems. I'm pretty sure that was an 1 on million case. Some kind of memory fault, after many and many USB burned perfectly.
I was trying burning on a Floppy (removable usb) catching errors for serious tests, after this, I was getting:
"unable to release volume" error.
I decided to reboot, and crap happened.

Hope this helps.
D.

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

I have thus far been unsuccessful in reproducing this issue. It is theoretically possible that you may have hit a memory leak corruption issue, as there is a memory leak in the app. This would only affect repetitive uses (which appears to be your case). I'm reducing the importance from Critical to High and re-uploading the 0.6 zip files with a warning. I would like to see some more testing.

I will also be releasing 0.7 here very soon that fixes the currently known memory leaks.

Changed in win32-image-writer:
importance: Critical → High
Revision history for this message
Tobin Davis (gruemaster) wrote :

Marking this as incomplete due to the lack of reproducibility. If someone is able to reproduce this issue, please change it from incomplete to confirmed, and I will try to focus more time on it.

Changed in win32-image-writer:
status: New → Incomplete
Revision history for this message
dragon788 (dragon788) wrote :

Just an anecdotal experience, but I built a computer for my dad a few years ago with an MSI motherboard, and its SATA HDD shows up as a removable drive in the Windows Device Manager and the Removable Devices menu. Perhaps this was a similar case where the motherboard or driver incorrectly presented the drive as a removable drive.

Revision history for this message
keV (eklunko) wrote :

I'm not sure but may it be related with AHCI enabled? AHCI allows to use advanced SATA features such as hot swapping and NCQ.

http://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface

I have AHCI enabled in BIOS so when I click "Safely remove" icon in system tray area (windows 7 prof.) the list contains my SATA hard disks as well as USB devices (and I actually can disconnect hard disk in case it is not used).

Revision history for this message
Akos (falconium) wrote :

I haven't used your app yet, but I regged in to tell you that my SSD shows up as removable:
- Eject SATA SanDisk SDSSDX12 SCSI Disk Device

Let me know if I can help you somehow with your investigation.

Revision history for this message
jacoscaz (jacoscaz) wrote :

I registered just to report the very same thing happening to me not more than 5 minutes ago. I have 3 HDDs, AHCI enabled and all 3 show up in the "safely remove" dialog. My D:/ drive (which wasn't even on the list) just got flashed instead of the selected F:/ drive. This happened on the very first use of the app. Platform is Win7 x64, version is 0.6. I believe I'll keep on swearing for the next 2 hours, then proceed to build a shrine to my beloved Dropbox.

I suggest re-opening and setting this to critical.

Changed in win32-image-writer:
status: Incomplete → Confirmed
Revision history for this message
djhell (hellismyhouse) wrote :

Sad to know someone else lost all data.
I'm still using 0.5.

Revision history for this message
StarkWiz (starkwiz) wrote :

Just would like to add, that this doesn't seem to happen on Windows 8 Pro.
I have 4 HDD's connected on AHCI out of which, 1 is eSATA.
And I was able to write an image to a microSD card.

Revision history for this message
Soulflare3 (rsnowflake94) wrote :

Tested this with Lime and a 4GB USB stick. Using Windows 7 Home Premium 64-bit. Had no trouble and image was written successfully to the USB drive. When I opened the program the only drive option was the USB stick.

Revision history for this message
KBez (kbez) wrote :

Dear all,
I would like to confirm one more incident of this bug.
The OS is MS Windows 7 Ultimate 32-bit, the version of Image Writer may be the last one or the previous one - not sure anymore!
The application has been used on the same laptop several times in the past without issues.
This time:
we attached a usb fdd
we formatted the diskette
we tried to write the img file from http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5072894
we got an error (didn't write it down)
we repeat the process
and on reboot the horrifying message invalid system disk etc.!

I will try to reproduce the issue and report back with any updates.
Thanks for your attention.
Kind regards.

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

Ok, I will try to investigate this some more. No guarantees, as I am a Linux developer, not a Windows developer. And hardware access is very limited.

Revision history for this message
Garry Sachse (garrysharon) wrote :

After reading this problum I thought that maybe the motherboard has AHCI enabled in the bios, on some motherboards a drive on AHCI shows up as a removerable drive, to see if it does in windows 7 have a look at the place where you usally remove pendrives from {bottom right of screen near the clock there is a triangle pointing up, click this) usally you cant remove system drives maybe this is the trouble?

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

I don't have a system available to me at this time that produces this issue, or could produce this issue (assuming it is only newer hardware).

I am going to try to see if I can mask the drive list in the program a little better and hopefully have something that will alleviate this issue in the next release.

In the mean time, if you have a system that this can be reproduced on, please add detailed info on your system to this bug (make, model, OS version, etc).

Changed in win32-image-writer:
status: Confirmed → Incomplete
Revision history for this message
jacoscaz (jacoscaz) wrote :

It just happened again. My C:\ drive (primary hdd, ahci enabled) just got flashed instead of the F:\ drive (usb key). This time I was using image-writer in a sandbox-like computer, hoping for the bug to come up so that I could maybe give you some pointers. The only common thing between the two episodes is enabled ahci. This time, it happened during the 5th flashing and hit the primary (os) harddrive instead of the data harddrive.

Revision history for this message
jacoscaz (jacoscaz) wrote :

Sorry, forgot some info: I'm using Windows 7 Professional X64 on an Asus P7-something motherboard + i7 processor. I have 3 hdds and they all turn up in the "safely remove" dialog. I had only one usb key connected to the machine when it happened. It had never happened before on this specific machine.

Revision history for this message
Garry Sachse (garrysharon) wrote :

I am shure that you will find that AHCI is the trouble maybe the only way to stop it being an issue is to not allow the program any access to the SATA bus.

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

To anyone that has seen this issue, please try this exe and see if it still has an issue (or breaks everything else). If it works, great. If not, kittens may die.

Changed in win32-image-writer:
assignee: nobody → Tobin Davis (gruemaster)
Revision history for this message
djhell (hellismyhouse) wrote :

I've just seen that my HD is SATA AHCI.
Computer info: HP Series 7300 elite.
It is sad to see that this happened to all this guys after me.
D.

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

I have committed a potential fix. Please test the attached exe by saving it to the directory that you unzipped the 0.6 release to. I need to know the results of this before too long, as I am working to push the next big release (lots of surprises).

Changed in win32-image-writer:
status: Incomplete → Fix Committed
Revision history for this message
lee (citlee) wrote :

Hi,

I have a Windows 7 64bit machine with AHCI mode enabled (my C: and D: drives show as removable devices). I have never run win32diskimager on this machine before. I've just tried the EXE from #22 and it worked fine - in the drive selection list, it only showed the SD card I had attached via a media reader. All works fine, image (latest raspbian) was written entirely without incident.

Thanks!

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

Excellent! Glad someone could test it as I have not been able to reproduce this error.

Revision history for this message
djhell (hellismyhouse) wrote :

I can't try. The incident happened on this computer (@ work) and I don't want to retry and lose 6 hours to restore all :P
Sorry :)

Revision history for this message
mattltm (matt-hknftjnl78lwtr23g) wrote :

Registered to post results. Sorry for the info but I thought the more, the better...

Custom build PC
OS: Windows 7 Pro x64
MB: ASUS P6X58D-E
Processor: i7 950
Ram: 24G DDR3 Corsair Vengance
HD: OCZ Vertex 3 SSD (SATA 3)
AHCI: Enabled

The OCZ SSD is the main system drive (C:) and shows up as a removable drive. I have the option to eject it from the taskbar USB notification icon (not that I would want to!)

Using the .exe posted in #22, the program does not show the C: drive as an option. It does show the removable USB3 HDD that I have plugged in and also the 16GB Sandisk SD card that I have plugged in.

The program performs as expected and write an image to the SD card correctly. The program did not overwrite the C: drive and performed correctly.

Hope that helps.

Matt

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

Great! Two confirmed fixed reports. Glad to hear them.

I still am unable to reproduce this here, and I have tried on several multiple work systems (not the actual writing, just the detection). None of my test systems show the C drive as removable, and all are sata (2 had SSDs).

Revision history for this message
Oil (oil) wrote :

I've just tried the EXE from #22 and my F-Secure did not like it. I am running Finnish version of it so I don't know what the message would be in English. I ques it might be something like: "Aplication blocked. DeepGuard has blocked a potentially harmful application to start. Application is: DiskImag. Rating: harmful".

With version 0.6 F-Secure don't complain anything, but I have not yet dared to write anything to SD with it.

Oil

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

Oil, this is a separate problem. Can you file a new bug for this?

Not sure what I can do to change it either. Could possibly be a permissions thing, don't know.

Revision history for this message
denixx baykin (denixx-baykin) wrote :

I have an OCZ Vertex 4 SSD, connected to SATA3 port which is HotPlug-enabled. Will try a #22 .exe and report to you. :)
Just only make a backup with Acronis... google translate says that our proverb can be translated as "better safe than sorry". :)

Revision history for this message
denixx baykin (denixx-baykin) wrote :

Tobin, both writes (with fixed and with unfixed app) was successfull - it does not destroyed my system drive.
My systemdrive is in removable devices - and all is ok.

Revision history for this message
jacoscaz (jacoscaz) wrote :

Fixed app seems to be working fine. No mis-targeted disks in 10+ flashes (mostly on AHCI-enabled machines).

Revision history for this message
deepak tripathy (dtrip) wrote :

Hi,
I had to sign up to report this issue. Long story.

All the users those faced their partitions wiped out had windows7 machines at work. My story is different.

I have my both the partitions (MBR/Partition tables) etc wiped out (mostly zeroed) from a IBM/Lenovo thinkpad running XP Pro SP3 on a HOME Laptop. This machine has served me nicely for mover 5 years and had never any issues. I was formatting a USB drive for FreeNAS that was not getting formatted. Obviously I had tried few more command-line as well as GUI software of unknown/questionable qualities, so assumed that one of those created this problem, never suspected such from a reputable source.

I had used win32diskimager-binary-0.6.zip on 31st oct 2012. Then completely hopeless, tried to recover all my data and was successful recovering the data. Then I took a Hex editor and opened the drive and to my surprise first few (10?) sectors contain zeroes and most of the reputable recovery programs can not find any traces of a partition.

So, YES, this also happens to XP. If you need further info, please ask me; I still have the 80GB image file and I can pull any sectors if you need.

I am a software developer and would not even dream of writing something such rogue power (& carelessness). Yes, I am being very blunt here, but last 3 days I have been asking myself how difficult it is to put a "is wanted drive/partition same as source drive/partition, then at least prompt the user if he/she wants to copy to the same drive" type of code in software such as DD (yes, this does not have it), phydiskwrite (have not checked it and mostly sure that this also does not have it), and your own (image writer for windows)!!!

In my view it is absolutely inexcusable to not to have such a check and doubly/triply/10 times check if this is not going to self destruct. Some may say this is beta, but my point is should a gadget/tool be able to destroy the host environment without notice?

I still have not found any tool that can find the partition/MBR except me pouring over the hex code and manually mark the partition beginning/end and recreating the MBR so that the thinkpad can boot/re-install.

FYI:
If anybody knows any tools that can recover the MBR/Partition Tables for a multiple partition disk, please please note here. I have to recover my only machine. IBM/Lenovo does not have a solution for this problem.

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

First, let me say we're sorry you lost your partition. I honestly don't know what to tell you as to why this happens. Nothing in the code indicates this should be remotely possible, and I have never been able to reproduce it on any system I have been able to test on. Every system I have tested, the C drive doesn't even show up. None of the non-usb drives show up for that matter.

As to this program being written with "rogue power (& carelessness)", please try to understand that this tool was originally created by Linux users to be able to boot/install ubuntu on netbook computers that do not have cd drives. The documentation on the system calls used came directly from msdn, with examples. And we all know how reliable Windows is.

As to your mbr/partition table, it is possible to fix, using open source tools (try running a system rescue cd - they're free). If only the MBR was affected, windows can easily repair it with "fdisk /mbr <drive>" from a command prompt.

If you are a developer, please feel free to upload patches. As I said, I am a Linux developer, maintaining this in my sparse free time (which includes trying to learn Windows idiosyncrasies).

Revision history for this message
deepak tripathy (dtrip) wrote :

Hi Tobin,
Thanks for being so understanding and not bouncing back. After I sent this message I proof read this and felt that the hapless tone was not conveyed properly, rather my message seemed like angry and menacing. I apologize for this.

I am writing this from my work PC and am scared to open the app and retrace the steps that I had taken, so can nto be of much help. I will check this after I rebuild my laptop. I was desperate as my NAS was down due to a irratic UPS, that made the subversion repository that the NAS hosts is not available and I have couple of personal code projects and on top of this the laptop crashed, and I sort of really panicked.

I take your point about windows, and been there and done that with MSDN. Actually my MBR is toast as well as partition tables and possibly the backup copies are also toast, so testdisk could not find anything. I found some unknown tool that recovered all my data from both partitions but find no way to recover any of the partitions. But the good news is I found a July backup of the windows partition and a separate tool found the service partition, so I will try to sequence them manually and see if the thinkpad boots/goes to recovery mode. In the worst case manually working on the hex code and working on that, but it is a completely different ball game. Once I am recovered I will try to download your source and find if there is a bug for my issues, may be I can do a partch then.

But thanks for the heads up and I apologize for my tone, which was not intended.

Deepak.

Revision history for this message
Tobin Davis (gruemaster) wrote : Re: [Bug 985080] Re: C: with windows 7 partition erased with all data

On Wed, 2012-11-07 at 03:39 +0000, deepak tripathy wrote:
> But thanks for the heads up and I apologize for my tone, which was not
> intended.

Not a problem, and I fully understand your frustration. I have to deal
with these types of issues every day at work (not due to my programming,
other people's code).

BTW: The latest source is now on
http://sourceforge.net/projects/win32diskimager. The entire project is
moving over there, as it is a more friendly site, I have more control
over every aspect (like translations - launchpad only works with gtk
type of translations, not QT), and it can handle more source code
management options (currently using GIT, but SVN and CVS are options).

Hope you get up and running soon, and as always, any help is welcome.
--
--

Tobin Davis

The disks are getting full; purge a file today.

Revision history for this message
djhell (hellismyhouse) wrote :

I just want to tell you, as I wrote on my very first post, that my C drive was NOT in the list. I was formatting a drive USB (H:) and a USB floppy (A:)
I never saw C: in the combobox but win32 wrote on C: the img file!!!
I'm writing this because you are saying that you never saw C: in your combobox and you can't reproduce the bug, but the problem is not this =)

Daniele

Revision history for this message
Nathan Revo (nrevo) wrote :

Just a thought. I was flashing disks on my system and noticed the drives didn't appear to get re-enumerated after ejecting/inserting disks. Is it possible that ejecting a disk would cause the program to internally map to the wrong disks?

Just an idea. I saw this behavior while trying to burn both a new FreeNAS 8 usb image and a raspberry pi SD card.

Revision history for this message
Eli (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvkbcvq9spp6z3w5j1m33k06tlsfszeuscyt241has-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze67n1wneepmidnuwnde1rqcbpgdf70gtqq2x9thj5tlcsac12) wrote :

Hi,

I'd like to suggest a possible reason for this issue.

Let's look at MainWindow::on_bWrite_clicked():

To me it seems like the root of the problem is the fact that volumeID and deviceID are taken from the Combo Box' data.

My reasoning goes like this: There is no chance in the world that volumeID points to C:, because locking would fail. On the other hand, if deviceID happens to be zero because the GUI toolkit messed up, then locking and umounting of the correct device will succeed, but the the raw device to write to will be chosen as PhysicalDrive0 by getHandleOnDevice(), which happens to be C: on most computers, I suppose.

So this is quite consistent with sporadic cases where people had C: written to, even though nothing suspicious happened before.

What I would warmly suggest, is to get the deviceID from the volumeID after the locking, and not rely on a GUI toolkit to cache that piece of precious information. The GUI toolkit shouldn't be trusted for anything.

Also, it could make sense to add a warning message box saying "you're about to write on disk E: having X MB of space", so that it's pretty obvious when it's not a small USB stick or so. Or even make a wilder warning if the disk space goes above, say, 256 GB (raising the number as time goes by).

I hope this helps.
   Eli

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

I don't think that is the issue, but I will try to look into it further. The function used to populate the gui drive selction list is a win32api call, not a QT call.

The workflow is essentially, initialize the list in the dropbox with with an empty list, use GetLogicalDrives to populate a temporary list, run each drive through checkDriveType(defined in disk.cpp), drives that pass this test are added to the list. Windows uses a simple bitmask to identify logical drives (a: = 1, b: = 2, c: = 3, etc). Part of the checkDriveType function is to check the physical device that contains the logical drive name to see if it is removable (which is our main criteria).

It is possible that the memory for the drive list is getting clobbered during hot plug events or some other memory leak issue. Whenever a usb device (not just a drive) is plugged in, Windows sends out a notice to all registered apps that are monitoring the usb bus (ours is registered with the Win32API calls in mainwindow.cpp::winEvent).

The criteria for a device to be included in the list is:
  1) Removeable (or fixed but on a removeable bus, i.e. usb external drives, but NOT sata)
  2) It can be opened for read/write operations (the program sucessfully creates a read/write handle to the raw device).
  3) There is physical media in the device (usb multicard readers will register deviceIDs for each slot, populated or not).

In all 3 cases, we rely on OS function calls to return valid data. Having said that, we do use mingw for the api calls (QT handles the GUI environment only). It is possible that this is exposing a bug in mingw, but it is also possible that this is exposing a bug in Windows (we don't have the development resources to really deep dive into this ourselves - we're mainly Linux programmers).

What I really need is someone that can reproduce this and can actively dedicate a system to help debug it without worrying about data loss. I have been unable to reproduce this in my limited test environment (and I have spent hours trying).

In

Revision history for this message
Eli (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvkbcvq9spp6z3w5j1m33k06tlsfszeuscyt241has-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze67n1wneepmidnuwnde1rqcbpgdf70gtqq2x9thj5tlcsac12) wrote :

It looks like I haven't communicated my point well: The fact that C: was wiped *must* be a result of an inconsistency between volumeID and deviceID in on_bWrite_clicked(). Had the case been that C: was in the combo box, and it was chosen, the outcome would have been an attempt to lock C:, which would fail right away, because there are obviously open files in C:. The Windows API is very clear about that if files are opened in a volume, it can't be locked. And we all know from personal experience how stubborn Windows is about this.

So let's leave the thought of how C: went into the combo box: It was never there. You made sure it would never get there, and the victims above say it was never there.

The only way this accident could have happened was that volumeID was correct but deviceID wasn't. Why that happened is an interesting issue, but hardly very helpful.

But since this utility is actively used, I would suggest a simple sanity check, if you like. Re-acquire the deviceID just before using it, verify that it isn't zero (and that it matches the one given from the GUI). Maybe re-affirm the drive the user is about to write to. And if the impossible happens (deviceID is wrong), open a dialog box asking the user to report this issue. With a lot of debug info to copy-paste.

So my suggestion is an ugly hack in the code, yes, but it should never surface if I'm wrong about this. It's just some extra assertion code, if you like. But if this happens to be the case, a hard disk was just saved.

I doubt that you'll be able to reproduce the scenario. I would put my money on a very certain combination of DLLs to make this go off. Instead, I suggest that simple field test: If someone says "I got that scary dialog box" there's something to work with. If noone says anything, just remove that hack after a while.

   Eli

Tobin Davis (gruemaster)
Changed in win32-image-writer:
status: Fix Committed → In Progress
Revision history for this message
jimbo1qaz (jimbo1qaz) wrote :

So is this bug still present in WIndows release 0.6?
Is there any build with dhe dialog box sanity check yet?

Revision history for this message
Austin Farmer (mapler-austin) wrote :

Hello, I m wondering what version would be the most safe for my computer. The computer i am using is Windows 7 and i am copying a .img file to a SD card for a Raspberry Pi. What version (0.7, 06, 0.5) would be the safest for doing this. After reading this post about this bug i am very cautious. PLEASE HELP ME, I DON'T WANT MY DATA LOST ;(

Revision history for this message
Austin Farmer (mapler-austin) wrote :

this is about the comment i posted (above). please contact me at <email address hidden>

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

As I have yet to reproduce this bug, I really can't tell you which version would be the "best". I would recommend pulling the 0.6 binary zip, and then copying the binary in comment #22 over the top. This works for me (and fixes other bugs). I would suggest loading it with no removable devices on your system. If it lists a drive STOP IMMEDIATELY! I would like a screenshot showing the drive listing if possible (use your cell phone if you have to).

Sadly, I lost my build environment and only just got a new Windows 7 build setup working yesterday (I'm mainly a Linux developer). The time I have to spend on this project has been very sparse, but I hope to get another release out very soon. The new build will have updated QT libraries and a few fixes.

Tobin Davis (gruemaster)
Changed in win32-image-writer:
importance: High → Critical
Revision history for this message
valkoun (valkoun) wrote :

As the original poster and Eli both have stated, this problem does not involve listing C: drives in the combo boxes. I second the proposed sanity check, just to be sure that it shouldn't happen on the root drive: https://bugs.launchpad.net/win32-image-writer/+bug/985080/comments/41

Revision history for this message
Roel Van de Paar (roel11) wrote :

Workaround for Raspberry PI owners: http://www.berryterminal.com/doku.php/berryboot

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

RoelV, while that looks like a really nice program, it is Linux based and only works with Raspberry PI (and apparently A10). It doesn't help the current situation, and has no bearing on the current issue. Please do not hijack bug reports on this forum to advertise a different project, unless that project provides a complete solution. Thank you.

Revision history for this message
Roel Van de Paar (roel11) wrote :

Tobin, I am sorry but posting a valid workaround for a subset of users is imho a good contribution and definitely not hijacking a bug. I have no other affiliation with Raspberry then being a single-unit end-user (and a fresh one at that).

Revision history for this message
Paul Neary (pjneary2) wrote :

I would have to concur with RoelV here. The Raspberry Pi site explicitly links to Image Writer for Windows, yet when you get here, there is this critical bug which at the very least gives one pause. Given the popularity of RPi, the "subset" of users is probably quite large. I was able to put the BerryBoot files directly on my SD card (on Windows 8!) and get my RPi going without worrying about trashing my C: drive, which I've sort of grown attached to.

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

Yes, this is considered hijacking of this bug report. Its like standing in a Starbucks and when a user has an issue with the coffee being too hot, telling them there is a Coffee People down the street.

I do agree that your solution is valid for raspberry pi users, but it really belongs on the raspberry pi site, not here. If it doesn't help to root cause this issue, it doesn't belong in this thread. These rules of etiquette were established on Launchpad far before Win32Image Writer was conceived. For more examples of bug etiquette, please do a google search on "bug report etiquette". You will see where I am coming from.

On a good note, I found a system at work that shows drive C as removable, so hopefully I will be able to use it to debug this more. Assuming I have spare time at work of course.

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

To everyone concerned with this bug, I am going to release v0.7 this weekend. I hope that this issue is resolved with this point release, but as I have still not been able to reproduce it on any test systems I have available, I just do not know.

Part of my testing for this included several write tests on a few systems at the local Best Buy (I don't think they like me much anymore). None failed (otherwise I'd likely be posting this from jail).

I want to close this bug for now and not take any new input here. If anyone experiences this bug with the v0.7 release, open a new bug and I promise to look into it as hard as I possibly can. But please make sure you post the release version, the OS version you are (were) running, and additionally the system you were running on (full make & model please so I can look up the system specs).

Thank you.

Changed in win32-image-writer:
status: In Progress → Won't Fix
status: Won't Fix → Incomplete
Revision history for this message
Jon Harris (lardconcepts) wrote :

Thanks Tobin; don't even want to chance 0.6 so looking forward to 0.7.
Very keen to get going with RP, and the dd setup option via linux doesn't seem to work for me (just red light).

Do you think it's likely to be released today?

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

My changelogs indicated I may have a possible fix for this (which was used to generate the attached binary in comment 22. Closing this with the new release.

If this happens again, please open a new bug, along with as much data as you can provide. Note, starting in release v0.7, the version number is on the main window.

Changed in win32-image-writer:
status: Incomplete → Fix Released
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.