So it's acceptable that any savvy user needs to hand move large directories just to run the *official package updates*?

defect.

It would have used fat32 for the .debs, not for unpacking and installing them.

I had already moved /var/cache/apt/archives to the opt partition, so using apt-get on the commandline for me isn't any different from the gui package manager in that regard. It still failed due to no space left on device.

*Sigh*

I guess you'll be happy to read the numerous hacks that were introduced with the 1.0.1 update (and also the ones that were available already before it). So no, it's not doing the same.

And if this boters you, feel free to: a) waste your time using bootmenu to place the operating system wherever you want,
b) stop complaining and start benchmarking/materializing the solutions already described on the wiki page
or c) return the device.

Wow, take a chill pill mate.

All I'm asking for is an official solution instead of a bunch of manual workarounds.

I see it's a work in progress, ok. The fact that it is a work in progress being weighed up by the community though does reinforce my perspective of it being a design flaw/defect though so please stop being smarmy in your responses :P

I would call it a design error.

I'm quite happy with the device and smiling that i have a linux system on my mobile phone. Anyway the issue with small rootfs is really annoying!

For me it seems that the device was never intensive testet before
production. Installing a few apps can fill up your rootfs within
the first day after purchase. Everybody is talking about the big
success of mobile apps and Nokia designs a Smartphone that ...

I'm using linux desktops since year and moved some folders to the
home partitition and so on ... but beside it's a bit risky ... it's for sure
not a solution for everybody!

Now i hesitat to start the update via app manager with only 54MB left.

Design error???

Personally I think trying to design around the 256MB limitation of the fast storage is a difficult one and not something to be candidly labelled as a design error.

The main issue is we need to OS to run off the fast chip, but we also need to try to conform to POSIX standards which makes partitioning a nightmare. Especially if apps are ported over using standard paths. Symlinking is a workable solution, and much better then the horrible implementation of unionfs in terms of the EeePC *shudder*, which also suffered from the need to balance between speed, storage size and cost.

*EDIT*
Just want to say I really hope they don't use NTFS, we are having enough trouble with FAT never mind waving another red flag....

I think there needs to be a virtual storage driver that can present other storage as VFAT so the N900 can be OS agnostic in terms of mounting it as an external storage. Waaaayyy beyond my abilities

The speed increase gained by using the OneNAND instead of putting everything on the eMMC and booting off of it is more than worth the issues it causes.

I turned off most of the repositories (extras, -devel, -testing, and Ovi) before updating which left me with ~63MB free, and the update ran without a blip. Soon as it was done, I re-enabled them. Sitting at 45MB free now.

Cool, thanks ... managed to have ~ 70MB free

Why?
App manager didn't work for you?

In my case I had over 50mb free before I tried to update. I had installed packages only from official repos but I still could not update OTA and it asked me to update via PC. I decided update using apt-get, but rootfs filled up. Eventually I managed to perform the update, but in my opinion rootfs space is insufficient.

It is true that average user wont use apt-get. BUT, before update I did only thinks which average user would do: install programs from official repositories and I could not update using package manager. So definitely everything didnt work as they should have. It is possible that some (normal) user cannot even do the update because of these issues.