| === Guest180 is now known as ogra | ||
| lag | bug 695274 | 07:35 |
|---|---|---|
| ubot2 | Launchpad bug 695274 in linux (Ubuntu) "WARNING: at /build/buildd/linux-2.6.35/net/sched/sch_generic.c:258 dev_watchdog+0x1fd/0x210() (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/695274 | 07:35 |
| trapicki | I've a problem with partition sizes and kernel reported disk size. Partitions seem to extend beyond the end of the disk. | 12:07 |
| trapicki | Kernel is 2.6.35-24-generic. Seems like Linux calculates the disk size too small. The partition is NTFS and works fine on Windows XP and Windows 7. | 12:09 |
| trapicki | Anyone an idea about the disk size/capacity problem? I read the Large Disk HOWTO (a little old, anyway), and there seem to have been issues with disk capacity and reported C/H/S . My disk is attached via USB, no idea how capacity is calculated for USB mass storage. | 14:49 |
| czr | trapicki, capacity is "calculated" by the device reporting it in LBA sectors. | 14:51 |
| czr | trapicki, how large is the device? | 14:51 |
| trapicki | Hello czr! The drive is 2TB, more like 1.83 TiB. | 14:52 |
| czr | what does blockdev --getsize /dev/sdX report? | 14:52 |
| trapicki | # blockdev --getsize /dev/sdh | 14:52 |
| trapicki | 3907024896 | 14:52 |
| czr | right. that's just shy above 2TB | 14:53 |
| czr | which shouldn't cause a problem at all. | 14:53 |
| czr | can you use pastebin and put the contents of fdisk -l -u /dev/sdh there? | 14:54 |
| czr | also, prepend to that the contents of : grep sdh /proc/partitions | 14:54 |
| * czr runs for a smoke meanwhile, brb | 14:55 | |
| czr | trapicki, you still here? | 14:58 |
| trapicki | czr: see http://pastebin.com/ww7QARuk | 14:59 |
| czr | hmm. that is severely broken | 15:00 |
| trapicki | I found quite some reports of that problem with disks not ending at a cylinder. See http://ubuntuforums.org/archive/index.php/t-1603349.html Comment srs5694 | 15:01 |
| trapicki | October 28th, 2010, 11:39 PM | 15:01 |
| trapicki | Is there any way to find out where the calculation went wrong? | 15:02 |
| czr | yes. the partition table looks really suspect | 15:02 |
| czr | what did you use to create it? | 15:02 |
| czr | good news is that the kernel detects the disk size correctly, so it's not a driver problem | 15:03 |
| trapicki | The drive was shipped with this partition by WD. Works fine on WinXP and Win7. | 15:03 |
| czr | however, when it starts parsing the partitions, it will get into trouble very quickly, resulting in incorrect /proc/partitions, and hence, completely incorrect view of the disk | 15:03 |
| trapicki | Of course, a partition stretching beyond the end of the disk is not sane. | 15:04 |
| czr | let me dig around a bit | 15:04 |
| trapicki | I checked the partition table, is MBR, no GPT. | 15:04 |
| czr | trapicki, right. pastebin the following: 1) sudo parted, 2) unit s 3) print | 15:08 |
| czr | parted is interactive, so enter 2 and 3 as commands | 15:08 |
| czr | I remembered there was a tool just to dump the "semiraw" contents of partition table, but rememberd that I had to write the tool myself some years back (can't find it now).. | 15:09 |
| trapicki | # parted /dev/sdh | 15:10 |
| trapicki | GNU Parted 2.3 | 15:10 |
| trapicki | Using /dev/sdh | 15:10 |
| trapicki | Welcome to GNU Parted! Type 'help' to view a list of commands. | 15:10 |
| trapicki | (parted) unit s | 15:10 |
| trapicki | (parted) print | 15:10 |
| trapicki | Error: Can't have a partition outside the disk! | 15:10 |
| trapicki | (parted) | 15:10 |
| trapicki | Sorry. | 15:10 |
| czr | heh. ok then. | 15:12 |
| trapicki | czr, you said the kernel detected the size correctly. But when the partitions are scanned, the partition size is truncated: | 15:12 |
| czr | seems that the WD comes with broken partition table | 15:12 |
| czr | yes. I said the kernel detected the disk size correctly. | 15:12 |
| trapicki | [ 4.373991] sd 6:0:0:0: [sdh] Assuming drive cache: write through | 15:12 |
| trapicki | [ 4.373996] sdh: sdh1 | 15:12 |
| trapicki | [ 4.389915] sdh: p1 size 3907027120 extends beyond EOD, enabling native capac | 15:12 |
| czr | no need to paste here | 15:12 |
| czr | I read your pastebin from earlier | 15:12 |
| czr | http://community.wdc.com/t5/Other-Externals/2TB-WD-Elements-HD-can-t-reformat/td-p/37535 | 15:12 |
| czr | seems like a common issue | 15:12 |
| czr | the fact that it happens to work in windows is not really of interest. the fact that people have to remove the volume and recreate it in order to make a filesystem (in windows) does signal that it's not really an issue in how linux works. | 15:13 |
| czr | so. linux does the right thing, even if it's not the same thing as your windows. | 15:14 |
| trapicki | I really do not want to repartition the drive. Lots of stuff on it, and as it's one of the biggest currently available, its not that easy to backup. Given the table is right and the capacity is reported wron | 15:15 |
| czr | the table is not right. | 15:15 |
| trapicki | is there any way to find out which steps are taken to calculate the drive capacity? | 15:16 |
| czr | now, if you're really desperate, you could make a dm mapping (for example with kpartx tools) and manually set the start and ending sectors for the dm volume slice. | 15:16 |
| czr | which you could then attempt to mount | 15:16 |
| czr | trapicki, here are the steps: http://lxr.linux.no/linux+v2.6.36/fs/partitions/msdos.c#L432 | 15:18 |
| trapicki | I guess the drive size is queried via usb mass storage directly from the drive, right? | 15:19 |
| trapicki | Thanks for the hint btw. | 15:19 |
| czr | yes | 15:21 |
| czr | the drive size is detected correctly | 15:21 |
| czr | but let me think a bit. you're using 32-bit host, right? | 15:21 |
| trapicki | no, 64bit. Linux corvusmons 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux | 15:22 |
| czr | hmm. yes. the partition doesn't actually run off that much off the disk | 15:24 |
| czr | fdisk has internal issues when doing the -l, which is why the values are whacked there | 15:24 |
| czr | so, the fact that the kernel will clip the partition sizes to end at the disk end would mean that some ntfs structures at the end of the disk wouldn't be accessible | 15:25 |
| czr | and there's really no good way around that if you plan to use the ntfs in anyway | 15:25 |
| czr | even the kpartx trick won't work | 15:25 |
| czr | so, I'm out of help here. the issue isn't in linux. the issue is with the incorrect partition table contents, and probably also ntfs boot device descriptor. windows works around it (but will probably eventually stop working), linux refuses to work around it, since it's just wrong. | 15:26 |
| trapicki | ntfs would not mount, it accesses the end of the disk soon, and boils out with errors about anavailable sectors. I would ignore the missing sectors, ntfs isn't :-( | 15:26 |
| czr | dump the data somewhere in windows, then recreate the partition and then you're done. | 15:26 |
| trapicki | :-(, but ok, seems the way to go. | 15:27 |
| czr | yes. you could try using ntfsfix to fix the filesystem itself, but it's very likely that you'll just break it even more. so don't do it. | 15:27 |
| czr | WD is evil. | 15:27 |
| czr | for selling such crap. | 15:27 |
| trapicki | Maybe some windows partition tool will resize the fs and the partition. | 15:28 |
| trapicki | yes, really crappy. | 15:28 |
| trapicki | Thanks for your help. | 15:30 |
| trapicki | Finally traced the USB traffic, and it reported 3907024895 LBA with 512 bytes/block. So the partition table is definitely wrong. | 16:18 |
| === yofel_ is now known as yofel | ||
| === doko__ is now known as doko | ||
| === _LibertyZero is now known as LibertyZero | ||
| === Quintasan_ is now known as Quintasan | ||
| apw | xclaesse, that bug already affects the current development release which is natty | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!