New: Kernel mis-detects size/position of partition created with Seagate DiscWizard (OnTrack Disk Manager)
A message that is not in the archive (sent off-list or not yet received): [email protected]/
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 4 lines · On Thu, 16 Jun 2011 17:31:02 GMT [email protected] 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?
Quoted 74 lines
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: [email protected] ReportedBy: [email protected] Regression: NoCreated an attachment (id=62332)
--> (https://bugzilla.kernel.org/attachment.cgi?id=62332)
First 136 sectors of diskHi,
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 16434486A 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/sdd1fails.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/diskThe "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)
Type0x54(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
0x11000bytes of this disk.
Quoted 2 lines · Andrew Morton
Quoted 2 lines
In case it helps to diagnose the problem, I have attached the first
0x11000bytes 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
Quoted 1 line · Paul Bolle
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,
Quoted 6 lines · Paul Bolle
Quoted 1 line · Paul Bolle
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
Quoted 8 lines · On Sat, 2011-06-18 at 09:51 +0100, [email protected] wrote:
Quoted 3 lines · Paul Bolle
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.
Quoted 9 lines
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
Quoted 6 lines · 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.
Quoted 6 lines
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.