I understand that historically having a 'base system' partition separate from the 'user/application' partition was essential when doing whole-image updates to avoid erasing things the user had put on the device themselves or the user's data. However, in light of the move to in-situ updating using a proven package management system, isn't this scheme just an annoying and unnecessary legacy limitation?

The OS updates yesterday, which replaced about 100 packages on my device, failed because the 200mb root partition just didn't have enough room to apply them all in one go. I don't have anything but the official base packages in there either. All my installed apps and personally-compiled stuff live in /opt. I've made sure of this to keep as much of that root partition free as possible.

The fact that official updates, which hit all at once, can't all be applied to the stock-standard root partition with it's current constricting size is evidence that this way of thinking is incorrect for this platform!

Surely the process of 'optifying' packages is cumbersome at best as well.

Isn't it time to migrate away from this split partition way of thinking and just make /opt and / one large 2gb partition?

It would save so much time and trouble.....

(Further more, shouldn't it be possible to have both the user's 30gb partition and the mmc card as filesystems other than fat32? Sure this would break using the usb mass storage gadget driver with windows boxes, but so what, I should be able to make that choice not have it made for me. fat32 is far too limiting! file size limitations, permissions and attribute limitations.. I can't use this!)

What does everyone else think?

I know there's posts out there to address this..

There is this brainstorm where solution #1 is similar to what you're asking. It's discussed here and this also talks about repartitioning.

The problem with the single /, or using the 2GB for / and the rest for the FAT32 /home/user/MyDocs is the same problem with using a small / and "hoping" every package is optified. Your root filesystem fills up and shuts down. Granted.. using a single 32GB / reduces this greatly as there is much more space (but also all user stored data will fill it up) - and using the 2GB/30GB idea means you only get 2GB worth of packages.. which honestly is a lot less than it sounds.

The ideal solution would be to separate / from all the data directories (/usr, /var, /lib).. this would hopefully keep the system from getting bricked when the filesystem fills up and can at least be recovered.

Thanks for the info.

however your point regarding 2/30 is that, currently, /opt IS only 2gb, so the issue you pointed out is actually currently in effect anyway. the 2/30 split would alleviate the rootfs being unable to handle official updates though :P

Regarding moving the entire flash disk to a single 32gb /, this isn't ideal.. specially for those who do want a large fat32 usb-sharable partition for using the device as a usb disk on windows systems.. but I do feel combining / and /opt as they are currently set up is a huge step forward from having 200mb / without adding any new issues to anyone from any camp...

http://wiki.maemo.org/Opt_Problem

Thanks, I see now that it is a separate chip...

Even discounting my idea, the current setup is still broken. apt-get upgrade failed yesterday due to the volume of official package updates hitting all at once. I had to manually move /usr/share off of /, symlink it, then re-run the upgrade to get back to a working system. Bottom line is / is too cramped to be used as the rootfs, period...



How can this be fixed? Or do we just write it off as the n900 design being broken and try to return them on the grounds of defect and buy an n910 or whatever comes out next?

"Defect"? I understand you can be a purist and dislike the symlink forest, but I've installed a shitload of nonoptified packages (including Samba and the whole of sunrpc, nfs, samba and inetd) and I still have 58 MiB free. And I didn't delete a single locale...

It was _less than a year ago_ that we were happily using a device with ONLY the 256MiB chip -- no ext3 partition. Though to be fair, heavy data files were usually installed to the FAT32 sdcard, and the base system was smaller.

You shouldn't really be able hit the rootfs limit without installing non-extras-stable packages.

I had 50mb free, ran apt-get upgrade without devel or testing enabled, and the *official* packages, of which there were about 100 or so, bombed out due to insufficient space. I call this a defect, as an end user who simply opens the box, gets it online, then runs apt-get upgrade will see it fail and end up with broken *system* packages.

Furthermore, the typical end user won't know how to recover from this, either manually or through a reflash..

You failed the test already, since "a normal user" isn't exactly supposed to run apt-get upgrade.

In fact, the official updater would have used the FAT32 volume for the downloaded packages. And redirected you to use the NSU in case something was very wrong on your rootfs.