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 log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 2.2007.50-2 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 log) 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 - 1966080
the same values including dangerous looking messages on bootup here.
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.
*** 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 that small.
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 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