Bug 37682 - Kernel mis-detects size/position of partition created with Seagate DiscWizard (OnTrack Disk Manager)
Summary: Kernel mis-detects size/position of partition created with Seagate DiscWizard...
Status: RESOLVED DOCUMENTED
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jens Axboe
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-16 17:31 UTC by Mark
Modified: 2012-08-24 14:43 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.38
Tree: Mainline
Regression: No


Attachments
First 136 sectors of disk (17.60 KB, application/octet-stream)
2011-06-16 17:31 UTC, Mark
Details

Description Mark 2011-06-16 17:31:01 UTC
Created attachment 62332 [details]
First 136 sectors of disk

Hi,

The kernel partition table scanning code appears to have a problem with partitions created by Seagate DiscWizard (a version of Ontrack Disk Manager).

I came across a 20GB Seagate drive which was installed in a machine running Windows 95. It was formatted using DiscWizard to have a single FAT32 partition. The 20GB drive was a secondary drive. However, the system probably booted from it to load the OnTrack code, which then booted the OS from the primary drive.

dmesg output on connecting the drive (via an IDE-USB converter):
 sd 10:0:0:0: [sdd] 39102336 512-byte logical blocks: (20.0 GB/18.6 GiB)
 sd 10:0:0:0: [sdd] Write Protect is off
 sd 10:0:0:0: [sdd] Mode Sense: 00 38 00 00
 sd 10:0:0:0: [sdd] Asking for cache data failed
 sd 10:0:0:0: [sdd] Assuming drive cache: write through
 sd 10:0:0:0: [sdd] Asking for cache data failed
 sd 10:0:0:0: [sdd] Assuming drive cache: write through
 sdd: sdd1[DM]

# blockdev --getsize /dev/sdd1
16434486

A partition is detected; sdd1[DM] appears in dmesg output. However its apparent size is too small; 7.37GB instead of ~20GB. So attempting to mount /dev/sdd1 fails.

The partition actually starts at sector 126. I was able to mount it manually by doing something like:
# mount -o ro,loop,offset=64512 -t vfat /dev/sdd /mnt/disk

The "disktype" program makes the same mistake as the kernel:
# disktype /dev/sdd

--- /dev/sdd
Block device, size 18.65 GiB (20020396032 bytes)
DOS/MBR partition map
Partition 1: 7.837 GiB (8414456832 bytes, 16434486 sectors from 9, bootable)
  Type 0x54 (OnTrackDM6)


If I copy some data from the start of the actual partition to a temporary file and run disktype on that:
# disktype tempfile

--- tempfile
Regular file, size 255.9 MiB (268370944 bytes)
Windows 95/98/ME boot loader
FAT32 file system (hints score 5 of 5)
  Volume size 18.64 GiB (20010500096 bytes, 1221344 clusters of 16 KiB)
  Volume name "DSK2_VOL1"


In case it helps to diagnose the problem, I have attached the first 0x11000 bytes of this disk.
Comment 1 Andrew Morton 2011-06-17 21:31:10 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu, 16 Jun 2011 17:31:02 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=37682
> 
>            Summary: Kernel mis-detects size/position of partition created
>                     with Seagate DiscWizard (OnTrack Disk Manager)

Hey, nice bug report!

There isn't really anyone who maintains that part of the kernel, but
with the info you've provided, pretty much any willing person could fix
this up.  So let's toss it out there and see?

>            Product: IO/Storage
>            Version: 2.5
>     Kernel Version: 2.6.38
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Block Layer
>         AssignedTo: axboe@kernel.dk
>         ReportedBy: markk@clara.co.uk
>         Regression: No
> 
> 
> Created an attachment (id=62332)
>  --> (https://bugzilla.kernel.org/attachment.cgi?id=62332)
> First 136 sectors of disk
> 
> Hi,
> 
> The kernel partition table scanning code appears to have a problem with
> partitions created by Seagate DiscWizard (a version of Ontrack Disk Manager).
> 
> I came across a 20GB Seagate drive which was installed in a machine running
> Windows 95. It was formatted using DiscWizard to have a single FAT32
> partition.
> The 20GB drive was a secondary drive. However, the system probably booted
> from
> it to load the OnTrack code, which then booted the OS from the primary drive.
> 
> dmesg output on connecting the drive (via an IDE-USB converter):
>  sd 10:0:0:0: [sdd] 39102336 512-byte logical blocks: (20.0 GB/18.6 GiB)
>  sd 10:0:0:0: [sdd] Write Protect is off
>  sd 10:0:0:0: [sdd] Mode Sense: 00 38 00 00
>  sd 10:0:0:0: [sdd] Asking for cache data failed
>  sd 10:0:0:0: [sdd] Assuming drive cache: write through
>  sd 10:0:0:0: [sdd] Asking for cache data failed
>  sd 10:0:0:0: [sdd] Assuming drive cache: write through
>  sdd: sdd1[DM]
> 
> # blockdev --getsize /dev/sdd1
> 16434486
> 
> A partition is detected; sdd1[DM] appears in dmesg output. However its
> apparent
> size is too small; 7.37GB instead of ~20GB. So attempting to mount /dev/sdd1
> fails.
> 
> The partition actually starts at sector 126. I was able to mount it manually
> by
> doing something like:
> # mount -o ro,loop,offset=64512 -t vfat /dev/sdd /mnt/disk
> 
> The "disktype" program makes the same mistake as the kernel:
> # disktype /dev/sdd
> 
> --- /dev/sdd
> Block device, size 18.65 GiB (20020396032 bytes)
> DOS/MBR partition map
> Partition 1: 7.837 GiB (8414456832 bytes, 16434486 sectors from 9, bootable)
>   Type 0x54 (OnTrackDM6)
> 
> 
> If I copy some data from the start of the actual partition to a temporary
> file
> and run disktype on that:
> # disktype tempfile
> 
> --- tempfile
> Regular file, size 255.9 MiB (268370944 bytes)
> Windows 95/98/ME boot loader
> FAT32 file system (hints score 5 of 5)
>   Volume size 18.64 GiB (20010500096 bytes, 1221344 clusters of 16 KiB)
>   Volume name "DSK2_VOL1"
> 
> 
> In case it helps to diagnose the problem, I have attached the first 0x11000
> bytes of this disk.
Comment 2 Paul Bolle 2011-06-18 01:33:00 UTC
On Fri, 2011-06-17 at 14:31 -0700, Andrew Morton wrote:
> > In case it helps to diagnose the problem, I have attached the first 0x11000
> > bytes of this disk.

0) $ /sbin/sfdisk -l First_0x11000_bytes.bin 
Disk First_0x11000_bytes.bin: cannot get geometry

Disk First_0x11000_bytes.bin: 0 cylinders, 255 heads, 63 sectors/track
detected Disk Manager - unable to handle that
 First_0x11000_bytes.bin: unrecognized partition table type
No partitions found

1) $ dd if=First_0x11000_bytes.bin of=First_0x9200_bytes.bin bs=512 skip=63
73+0 records in
73+0 records out
37376 bytes (37 kB) copied, 0.0224746 s, 1.7 MB/s

2) $ /sbin/sfdisk -l -uS First_0x9200_bytes.bin 
Disk First_0x9200_bytes.bin: cannot get geometry

Disk First_0x9200_bytes.bin: 0 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
First_0x9200_bytes.bin1   *        63  39102209   39102147   c  W95 FAT32 (LBA)
		end: (c,h,s) expected (1023,254,63) found (385,254,63)
First_0x9200_bytes.bin2             0         -          0   0  Empty
First_0x9200_bytes.bin3             0         -          0   0  Empty
First_0x9200_bytes.bin4             0         -          0   0  Empty

39102147 seems to be close to what the reporter expects to see.

3) Some searches suggest there used to be a "hda=remap63" boot option
for this, ie OnTrack Disk Manager, but I can't find it grepping the
source nor could I find the commit(s) that removed it.


Paul Bolle
Comment 3 Paul Bolle 2011-06-18 01:33:26 UTC
On Sat, 2011-06-18 at 03:01 +0200, Paul Bolle wrote:
> nor could I find the commit(s) that removed it.

That was 232595eaff951e96cabe5e85fed35f66b72ff51e ("ide: remove
obsoleted "hdx=" kernel parameters"), which was applied in the v2.6.27
cycle.


Paul Bolle
Comment 4 Mark 2011-06-18 09:33:16 UTC
Hi,

Paul Bolle wrote:
> On Sat, 2011-06-18 at 03:01 +0200, Paul Bolle wrote:
>> nor could I find the commit(s) that removed it.
>
> That was 232595eaff951e96cabe5e85fed35f66b72ff51e ("ide: remove
> obsoleted "hdx=" kernel parameters"), which was applied in the v2.6.27
> cycle.

Was the feature which that commit removed specific to ide devices? That
is, would it have not applied for a drive connected via a USB/Firewire
bridge?

Ideally the kernel partition-scanning code would be fixed to handle these
strange partitions. As a temporary measure, it might be best to print a
warning and not create the incorrect block device.

E.g. user might think "I'll back up this partition"
  dd if=/dev/sdc1 of=partition.bin
or "I'll wipe this partition before disposing of the disk"
  dd if=/dev/zero of=/dev/sdc1.
Neither has the desired effect.


Mark
Comment 5 Paul Bolle 2011-06-18 10:38:51 UTC
On Sat, 2011-06-18 at 09:51 +0100, markk@clara.co.uk wrote:
> Paul Bolle wrote:
> > That was 232595eaff951e96cabe5e85fed35f66b72ff51e ("ide: remove
> > obsoleted "hdx=" kernel parameters"), which was applied in the v2.6.27
> > cycle.
> 
> Was the feature which that commit removed specific to ide devices? That
> is, would it have not applied for a drive connected via a USB/Firewire
> bridge?

I have no clue. I'd guess it wouldn't. For instance, a drive connected
using USB uses the SCSI layer, doesn't it? That wasn't different a few
years ago.

> Ideally the kernel partition-scanning code would be fixed to handle these
> strange partitions. As a temporary measure, it might be best to print a
> warning and not create the incorrect block device.
> 
> E.g. user might think "I'll back up this partition"
>   dd if=/dev/sdc1 of=partition.bin
> or "I'll wipe this partition before disposing of the disk"
>   dd if=/dev/zero of=/dev/sdc1.
> Neither has the desired effect.

Digging further into this I found commit d708c40d ("ide: mark
"hdx=remap" and "hdx=remap63" kernel parameters as obsoleted"). The
commit message reads:
    Mark "hdx=remap" and "hdx=remap63" kernel parameters as obsoleted
    (they are layering violation and should be dealt with in the same
    way as done by libata - device-mapper should be used instead).

Perhaps this means one is expected to use dmsetup(8) for this. I have
never configured device-mapper at that level by hand. man 8 dmsetup is
over 300 lines of (new for me) information. Without a disk like yours at
hand, it's hard to say whether device-mapper allows to do stuff like
this (ie, remapping an entire drive by 63 sectors) by hand.

Of course, for your particular drive it might be easier to just dd the
actual partition (so skipping 63 sectors) into new file (a 20G image) on
another drive. That image should be loop mountable. If that's correct
you could then do with the drive as you please. Given its age, it may be
wise to, say, shred(1) its corresponding device and drop the drive at
your local recycling site.


Paul Bolle
Comment 6 Arnd Bergmann 2011-06-18 15:19:06 UTC
On Saturday 18 June 2011 12:38:21 Paul Bolle wrote:
> Perhaps this means one is expected to use dmsetup(8) for this. I have
> never configured device-mapper at that level by hand. man 8 dmsetup is
> over 300 lines of (new for me) information. Without a disk like yours at
> hand, it's hard to say whether device-mapper allows to do stuff like
> this (ie, remapping an entire drive by 63 sectors) by hand.
> 
> Of course, for your particular drive it might be easier to just dd the
> actual partition (so skipping 63 sectors) into new file (a 20G image) on
> another drive. That image should be loop mountable. If that's correct
> you could then do with the drive as you please. Given its age, it may be
> wise to, say, shred(1) its corresponding device and drop the drive at
> your local recycling site.

You can also create a "correct" partition table to replace the old
one and directly point to the FAT partition:

# fdisk -c -u -C2435 -H255 -S 63 /dev/sdX

Command (m for help): p

Disk /dev/sdX: 0 MB, 0 bytes
255 heads, 63 sectors/track, 2434 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/sdX   *           9    16434494     8217243   54  OnTrackDM6

Command (m for help): d
Selected partition 1

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (1-39118274, default 1): ?
First sector (1-39118274, default 1): 126
Last sector, +sectors or +size{K,M,G} (126-39118274, default 39118274): +39102147

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

Command (m for help): a
Partition number (1-4): 1

Command (m for help): p

Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/sdX   *         126    39102273    19551074    c  W95 FAT32 (LBA)


Command (m for help): w
The partition table has been altered!


WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.

Note You need to log in before you can comment on or make changes to this bug.