maemo.org Bugzilla – Bug 2940
oversized partition on N810 internal card from factory
Last modified: 2009-01-14 17:32:53 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
1. buy new N810, complete wizard
2. (maybe optionally) test media player with supplied videos, start map
application, watch tutorial, disable key an touchscreen sound (for clean dmesg
3. shutdown, power on, start xterm, type dmesg and see something like
[ 1.257812] mmcblk0: mmc1:0001 000000 1966080KiB
[ 1.257812] mmcblk0: p1
[ 1.257812] mmcblk0: p1 exceeds device capacity
lots of I/O errors
4. type cat /proc partitions and see
major minor #blocks name
31 0 128 mtdblock0
31 1 384 mtdblock1
31 2 2048 mtdblock2
31 3 2048 mtdblock3
31 4 257536 mtdblock4
254 0 1966080 mmcblk0
254 1 2007032 mmcblk0p1
This happened me twice with two different new devices. One German one bought in
January and one UK one bought in February. The German one was bought and
pre-tested by someone else so I ignored it but with the UK one I was the first
one to power it on and can verify this really comes straight from factory
without any modifications done by me.
The card still appears to work (unless one looks in kernel log) but will
produce user visible errors sooner or later when filled up more.
Created an attachment (id=715) [details]
kernel log after boot showing i/o errors
Created an attachment (id=716) [details]
master boot record of internal card saved by dd
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 -
the same values including dangerous looking messages on bootup here.
also found same error here
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.
*** Bug 2906 has been marked as a duplicate of this bug. ***
*** 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).
*** Bug 2802 has been marked as a duplicate of this bug. ***
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.
(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.)
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
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.
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. . . .
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"
(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
and there is even libparted so custom tool fixing this could be created