Can not format drive after writing a Chrome OS image #759

Closed
pbatard opened this Issue May 19, 2016 · 3 comments

Comments

Projects
None yet
1 participant
@pbatard
Owner

pbatard commented May 19, 2016

After writing http://chromium.arnoldthebat.co.uk/weekly/Cx86OS-20160515010101.img.7z in DD Image mode, it seems impossible to get the drive reformatted in Rufus (or anything Windows for that matter - Even Disk Management on Windows 10 produces an error when trying to delete one of the many GPT partitions this Chrome OS creates).

Even if you try to zap a drive (Alt-Z) you get an error:

Rufus version: 2.9.934
Windows version: Windows 10 64-bit (Build 10586)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02~beta3
System locale ID: 0x0809
Will use default UI locale 0x0809
Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
Using autorun.inf label for drive F: '16GB'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1946, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x0095E9AF
Drive has a Windows 7 Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Size: 14.9 GB (16012894208 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes
Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
Using autorun.inf label for drive F: '16GB'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1946, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x0095E9AF
Drive has a Windows 7 Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Size: 14.9 GB (16012894208 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes
Scanning image...
ISO analysis:
  'C:\Downloads\Cx86OS-20160515010101.img' doesn't look like an ISO image
Disk image analysis:
  Image has an unknown Master Boot Record
  Image is a bootable disk image
Using image: Cx86OS-20160515010101.img

Format operation started
Requesting disk access...
Opened drive \\.\PHYSICALDRIVE7 for write access
Will use 'F:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Windows 7 Master Boot Record
Drive has a FAT32 FreeDOS Partition Boot Record
Deleting partitions...
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Writing Image...
Remounted \\?\Volume{3c9ea97e-83a5-11e5-8487-fcaa14e7bd8e}\ on F:\

Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
1 device found
No volume information for drive 0x87
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1946, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 12
Disk GUID: {F5759492-0EA3-3143-9E38-15C96D6EC50D}
Max parts: 128, Start Offset: 17408, Usable = 16013908480 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'STATE'
  ID: {F3F51390-9356-584F-BA9F-36B67622D3DA}
  Size: 1.2 GB (1275068416 bytes)
  Start Sector: 4481024, Attributes: 0x0000000000000000
Partition 2:
  Type: {FE3A2A5D-4F32-41A7-B725-ACCC3285A309}
  Name: 'KERN-A'
  ID: {F4F40520-1564-374C-9376-5B2614F5B142}
  Size: 16 MB (16777216 bytes)
  Start Sector: 20480, Attributes: 0x01FF000000000000
Partition 3:
  Type: {3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC}
  Name: 'ROOT-A'
  ID: {7036A10C-2065-9943-9BDC-96DD403D6723}
  Size: 2 GB (2147483648 bytes)
  Start Sector: 286720, Attributes: 0x0000000000000000
Partition 4:
  Type: {FE3A2A5D-4F32-41A7-B725-ACCC3285A309}
  Name: 'KERN-B'
  ID: {441A1637-06F7-004F-93BD-7F3B3CFE9FA0}
  Size: 16 MB (16777216 bytes)
  Start Sector: 53248, Attributes: 0x0000000000000000
Partition 5:
  Type: {3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC}
  Name: 'ROOT-B'
  ID: {214F66CB-3076-C24F-B50A-9F859D8813AB}
  Size: 2 MB (2097152 bytes)
  Start Sector: 282624, Attributes: 0x0000000000000000
Partition 6:
  Type: {FE3A2A5D-4F32-41A7-B725-ACCC3285A309}
  Name: 'KERN-C'
  ID: {3626499D-5CA2-5E45-8217-6221105722F9}
  Size: 512 bytes (512 bytes)
  Start Sector: 16448, Attributes: 0x0000000000000000
Partition 7:
  Type: {3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC}
  Name: 'ROOT-C'
  ID: {E133CB48-7F38-8E4A-97BE-506B5BDC0996}
  Size: 512 bytes (512 bytes)
  Start Sector: 16449, Attributes: 0x0000000000000000
Partition 8:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'OEM'
  ID: {5F9A95C3-F468-E843-B46F-BC8B6207DC00}
  Size: 16 MB (16777216 bytes)
  Start Sector: 86016, Attributes: 0x0000000000000000
Partition 9:
  Type: {2E0A753D-9E48-43B0-8337-B15192CB1B5E}
  Name: 'reserved'
  ID: {946E9B6B-3F13-EB44-A7AF-C44D03FC775C}
  Size: 512 bytes (512 bytes)
  Start Sector: 16450, Attributes: 0x0000000000000000
Partition 10:
  Type: {2E0A753D-9E48-43B0-8337-B15192CB1B5E}
  Name: 'reserved'
  ID: {FC6515E9-5B35-C940-A4D4-ED9C87F0188A}
  Size: 512 bytes (512 bytes)
  Start Sector: 16451, Attributes: 0x0000000000000000
Partition 11:
  Type: {CAB6E88E-ABF3-4102-A07A-D4BB9BE3C1D3}
  Name: 'RWFW'
  ID: {24FCFBA3-CEF7-704C-90BE-8F9BE249F1ED}
  Size: 8 MB (8388608 bytes)
  Start Sector: 64, Attributes: 0x0000000000000000
Partition 12:
  Type: {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}
  Name: 'EFI-SYSTEM'
  ID: {F0CB8B5E-F373-6643-BB2E-AD9CD8BABBDA}
  Size: 16 MB (16777216 bytes)
  Start Sector: 249856, Attributes: 0x0000000000000000

Format operation started
Requesting disk access...
Opened drive \\.\PHYSICALDRIVE7 for write access
Will use 'F:' as volume mountpoint
Deleting partitions...
Zeroing drive...
write error: [0x00000001] Incorrect function.
  RETRYING...
write error: [0x00000001] Incorrect function.
  RETRYING...
write error: [0x00000001] Incorrect function.

Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
1 device found
No volume information for drive 0x87
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1946, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x00000001
Drive does not have an x86 Master Boot Record
Partition 1:
  Type: Small FAT16 (0x04)
  Size: 14.9 GB (16013942784 bytes)
  Start Sector: 0, Boot: No, Recognized: Yes

The only option to recover the drive seems to be to reformat it in Linux... 😭

I believe this is a Microsoft issue (no application I tried seems to be able to write the drive), but it still would be nice to have some kind of workaround if achievable...

@pbatard pbatard self-assigned this May 19, 2016

@pbatard pbatard changed the title from Can not drive after writing a Chrome OS image to Can not format drive after writing a Chrome OS image May 19, 2016

@pbatard

This comment has been minimized.

Show comment
Hide comment
@pbatard

pbatard May 20, 2016

Owner

Further investigation seems to indicate that the problems only arise after Rufus tries to clean the drive that got the ChromeOS image. If you use something else to repartition/reformat the drive after that first image write (e.g. Windows' diskpartclean), then you are able to write to the drive without issues.

We may have to investigate more closely how the clean command of diskpart works (or what Win32DiskImager does before writing sectors, as it can also rewrite that image repeatedly), and perform something similar in Rufus.

Owner

pbatard commented May 20, 2016

Further investigation seems to indicate that the problems only arise after Rufus tries to clean the drive that got the ChromeOS image. If you use something else to repartition/reformat the drive after that first image write (e.g. Windows' diskpartclean), then you are able to write to the drive without issues.

We may have to investigate more closely how the clean command of diskpart works (or what Win32DiskImager does before writing sectors, as it can also rewrite that image repeatedly), and perform something similar in Rufus.

@pbatard

This comment has been minimized.

Show comment
Hide comment
@pbatard

pbatard May 20, 2016

Owner

Spoke too soon. Even using Win32DiskImager alone with the ChromeOS image, and against a fully zeroed USB drive seems to be enough to make diskpart's clean command fail:

DISKPART> sele disk 7

Disk 7 is now the selected disk.

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB  1024 KB        *
  Disk 5    Online         1853 GB      0 B        *
  Disk 6    Online         1853 GB      0 B        *
* Disk 7    Online           14 GB    11 GB        *

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 0    Unknown              8 MB    32 KB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             16 MB    10 MB
  Partition 0    Unknown             16 MB    26 MB
  Partition 0    Primary             16 MB    42 MB
  Partition 0    System              16 MB   122 MB
  Partition 0    Unknown           2048 KB   138 MB
  Partition 0    Unknown           2048 MB   140 MB
  Partition 1    Primary           1216 MB  2188 MB

DISKPART> clean

DiskPart has encountered an error: Incorrect function.
See the System Event Log for more information.

DISKPART>

So this is really not related to anything specific Rufus does, though it appears Win32DiskImager fares a bit better, in that it is still able to write an image on the drive even after the failure above...

So one possible workaround would be to write the MBR or GPT partition tables with zeroes, in sector mode, as Win32DiskImager does, before we attempt any further cleanup operations.

Owner

pbatard commented May 20, 2016

Spoke too soon. Even using Win32DiskImager alone with the ChromeOS image, and against a fully zeroed USB drive seems to be enough to make diskpart's clean command fail:

DISKPART> sele disk 7

Disk 7 is now the selected disk.

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB  1024 KB        *
  Disk 5    Online         1853 GB      0 B        *
  Disk 6    Online         1853 GB      0 B        *
* Disk 7    Online           14 GB    11 GB        *

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 0    Unknown              8 MB    32 KB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             512 B     8 MB
  Partition 0    Unknown             16 MB    10 MB
  Partition 0    Unknown             16 MB    26 MB
  Partition 0    Primary             16 MB    42 MB
  Partition 0    System              16 MB   122 MB
  Partition 0    Unknown           2048 KB   138 MB
  Partition 0    Unknown           2048 MB   140 MB
  Partition 1    Primary           1216 MB  2188 MB

DISKPART> clean

DiskPart has encountered an error: Incorrect function.
See the System Event Log for more information.

DISKPART>

So this is really not related to anything specific Rufus does, though it appears Win32DiskImager fares a bit better, in that it is still able to write an image on the drive even after the failure above...

So one possible workaround would be to write the MBR or GPT partition tables with zeroes, in sector mode, as Win32DiskImager does, before we attempt any further cleanup operations.

@pbatard pbatard added this to the 2.10 milestone May 21, 2016

@pbatard

This comment has been minimized.

Show comment
Hide comment
@pbatard

pbatard May 21, 2016

Owner

Well, the real workaround here is NOT to call IOCTL_DISK_CREATE_DISK first, as we currently do (which is what diskpart's clean calls behind the scenes), but instead erase the MBR/GPT/PBR sectors first, and then call IOCTL_DISK_CREATE_DISK.

This is the root of the issue really: Microsoft's IOCTL_DISK_CREATE_DISK is not enough to actually clean a disk, as can be be shown with a sector editor (it leaves way too many partitions artefacts behind), so one must perform some more comprehensive cleaning beforehand.

I have now applied this workaround, which will be in Rufus 2.10, and it seems to provide good results with the ChromeOS images (you can now perform all of Rufus regular operations on a drive where such an image has been applied, without encountering write errors).

Sadly however, this will not help people who already issued an IOCTL_DISK_CREATE_DISK call (through Rufus or another application) on their drives, as there does not seem to exist any other solution to recover these but to clean/reformat them on a different OS such as Linux...

Owner

pbatard commented May 21, 2016

Well, the real workaround here is NOT to call IOCTL_DISK_CREATE_DISK first, as we currently do (which is what diskpart's clean calls behind the scenes), but instead erase the MBR/GPT/PBR sectors first, and then call IOCTL_DISK_CREATE_DISK.

This is the root of the issue really: Microsoft's IOCTL_DISK_CREATE_DISK is not enough to actually clean a disk, as can be be shown with a sector editor (it leaves way too many partitions artefacts behind), so one must perform some more comprehensive cleaning beforehand.

I have now applied this workaround, which will be in Rufus 2.10, and it seems to provide good results with the ChromeOS images (you can now perform all of Rufus regular operations on a drive where such an image has been applied, without encountering write errors).

Sadly however, this will not help people who already issued an IOCTL_DISK_CREATE_DISK call (through Rufus or another application) on their drives, as there does not seem to exist any other solution to recover these but to clean/reformat them on a different OS such as Linux...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment