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.
(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.
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
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
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
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
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.