Comment 1 Frantisek Dufka (reporter) 2008-02-14 10:54:52 UTC

Created an attachment (id=715) [details]
kernel log after boot showing i/o errors

Comment 2 Frantisek Dufka (reporter) 2008-02-14 10:55:49 UTC

Created an attachment (id=716) [details]
master boot record of internal card saved by dd

Comment 3 Frantisek Dufka (reporter) 2008-02-14 11:16:46 UTC

here is also output of 'df', AFAIK nothing was written there by me, used space
should be just maps and bundled media

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock4            2048      2048         0 100% /mnt/initfs
none                       512        76       436  15% /mnt/initfs/tmp
/dev/mtdblock4          257536    142168    115368  55% /
none                       512        76       436  15% /tmp
none                      1024        12      1012   1% /dev
tmpfs                     1024         0      1024   0% /dev/shm
/dev/mmcblk0p1         1999206    230526   1768680  12% /media/mmc2

the number of blocks - 1999206 is larger that device size in /proc/partitions -
1966080

the same values including dangerous looking messages on bootup here.

Comment 5 Frantisek Dufka (reporter) 2008-02-14 14:47:51 UTC

also found same error here
http://www.internettablettalk.com/forums/showthread.php?t=14364

I can confirm this bug on my device (delivered January 2008), too.

I can see the same problem on my N810.

This might explain some file system corruption problems i've had. 
See also bug #2511

See also Bug 2906.

There looks to be another observation in Bug 2747 Comment #1.

Comment 10 Eero Tamminen 2008-02-29 16:01:39 UTC

*** Bug 2906 has been marked as a duplicate of this bug. ***

Comment 11 Eero Tamminen 2008-02-29 16:14:57 UTC

*** Bug 2511 has been marked as a duplicate of this bug. ***

Same problem here. I first had file-system corruption, then saw "attempt to
access beyond end of device" messages in the dmesg output.

Bug 2802 appears to be a duplicate; although I might have accidentally hijacked
it for a different bug (filesystem corruption even when the partition is
smaller than the device size).

Comment 14 Eero Tamminen 2008-04-08 14:02:44 UTC

*** Bug 2802 has been marked as a duplicate of this bug. ***

Comment 15 Andrew Flegg 2008-04-25 12:14:50 UTC

Bumping the priority. End-users aren't automatically going to reformat it: it
contains the default maps and Navicore data for their locale.

Connecting an N810 to a Windows PC and copying data (say MP3 files) to the
internal SD card until the disk reports full - which should be a supported
operation - results in filesystem corruption.

*Something* needs to be done to correct this problem on all the existing
devices. Possibly in the kernel and whatever exposes it as a USB device to
other systems. Make it a hard-coded hack. Make it /something/. Please.

Re-setting the assignee, since Carlos moved on to other tasks.

Please note that this does not affect the legitimacy of the bug in any way.
It's a purely administrative operation. Sorry for the noise.

Comment 17 Eero Tamminen 2008-06-12 15:53:17 UTC

(In reply to comment #15)
> Bumping the priority. End-users aren't automatically going to reformat it: it
> contains the default maps and Navicore data for their locale.
> 
> Connecting an N810 to a Windows PC and copying data (say MP3 files) to the
> internal SD card until the disk reports full - which should be a supported
> operation - results in filesystem corruption.
> 
> *Something* needs to be done to correct this problem on all the existing
> devices. Possibly in the kernel and whatever exposes it as a USB device to
> other systems. Make it a hard-coded hack. Make it /something/. Please.

But that would require user to reflash their device.  I would assume
users to be even less reluctant to do that than copying card data to PC,
formatting the card and copying the data back...?   System upgrades
& notifications about them are unfortunately only supported in Diablo.


(The size mismatch was of course fixed in the factory as soon as it was
noticed, so the bug could be marked as fixed, but I think it's better to
keep this still open so that users still suffering from the issue can find
it easier.  The bug should concern only relatively small number of devices.)

Comment 18 Andre Klapper 2008-06-16 14:56:15 UTC

downgrading severity and priority as per last comment.

Just as a data point, the N810 I just bought from Amazon had the oversized
partition.  Either they're not selling that well, or the buggy batch wasn't
that small.

Comment 20 Andre Klapper 2009-01-14 16:01:09 UTC

There are a few devices in public having this bug, but I don't expect Nokia to
recall the affected devices. This has not happened yet and hence it will
probably not happen in the future.

So I ask myself: What can be done to get this bug report into a RESOLVED state
instead of having it rotting here?
After the bug was found it was fixed for all later devices produced (as
described by Eero in comment 17).
I'm also going to close this report as FIXED, though this does not make it
vanish or directly help affected users.
Other proposals welcome.

Comment 21 Ryan Abel 2009-01-14 16:19:34 UTC

It's clearly fixed. The code's been patched, the fix has been shipped. Any old
stock remaining in the pipeline is what it is. . . .

Comment 22 Andrew Flegg 2009-01-14 16:36:40 UTC

I still think that there should've been some kind of hack put into one of the
upgrades/SSUs which fixed it at the USB/kernel/... level.

The fact that brand new devices shipping from the factory don't have the
problem is, to be frank, only half the battle.

With a new device on the horizon, and fire sales of N810s approaching (PC World
in the UK has now got them for ~$110), their may be lots of newbies getting
exciting new devices; only to fill them up and have them keel over. They'll
just diss it as "crap", rather than thinking "hmm, perhaps a
reformat/repartition will fix this"

Comment 23 Frantisek Dufka (reporter) 2009-01-14 17:30:03 UTC

(In reply to comment #22)
> I still think that there should've been some kind of hack put into one of the
> upgrades/SSUs which fixed it at the USB/kernel/... level.

Indeed. Either in some system update or as (Windows?) utility which fixes it in
usb storage mode. Basically this can be solved by 1. in place partition and FAT
filesystem resizer or 2. copying data somewhere else and reformatting. Even
just system dialog that informs user about wrong size (sooner than user fills
up the device and finds out his data is gone) with pointer to some explanation
page would be enough.

as for 1. I suppose parted could do it
http://www.gnu.org/software/parted/features.shtml
and there is even libparted so custom tool fixing this could be created
http://www.gnu.org/software/parted/api/group__PedFileSystem.html