Problem with this is (no idea, just shooting possible problems, correct me pls if anyone knows) all those hildon-*, maemo-* and osso-* files might be needed on bootup and as opt is mounted later on remounting whole /usr(/bin) could result in reboot loop. Just guessing. Linking non-essential for start files from there should be easier...

How about mounting both /opt and /usr from /sbin/preinit? That's about as early in the boot process as one can go, and shouldn't require anything from /usr.

Also, another option could be to leave a skeleton set of files in /usr on the NAND to bridge the gap before the mount is done. However, this would make things more than a bit complicated.

Too newb here to see anytning wrong with this approach, but seems like you could mount MyDocs at the same time and move whole bulk to eMMC, so there is probably a reason why it hasn't been done before. Wish someone more knowledgable in that aspect could chime in

Okay, everybody, settle down.

/usr contains lots of binaries that are ran on startup on any other Linux system, if you want to actually do some useful stuff.

The problem here is, you moved it to a different partition. WAT DO?

You need to mount /usr, even before anything else has been mounted. genfstab is in usr, so that's a no-go.

You'd have to load modules for /home filesystem, mount /home from preinit, mount /home/opt/maemo/usr to /usr, then just let pymaemo-optify mount /home/opt to /opt.

Geez, genfstab is ******ed. Why can't we replace that POS with whatever GNOME's having nowadays to detect external media?

Sorry, too newb to discern whether your last sentence was rhetorical, but in case it wasn't, would it be doable? GNOME should be GNuish, if we could load it somehow early on boot, could this possibly result in free rootfs space? Or would the scenario right above be feasible? Amount of rootfs is one of the few but painful unsolved problems on N900

To be honest, I *never* even encountered any problem with rootfs space. At current point, with many things installed, I've 50 MB free, and still I "fail" to see any reason, why I should like to move most often use files/binaries/whatever out of very fast NAND to slow eMMC.

/Estel

Well, most libraries behave very badly when symlinked out of rootfs. So when you apt-get libboost1.42-all-dev you will be left with few mb out of your current 50 (yeah, full libboost is a cow). Then you start following all optifying instructions out there, get back to around 40mb free and another cow-dev comes around, you end up <10mb, optify some more... neverending story really.

EDIT: about speed: copy 10mb file for a test to your ultrafast NAND, you will not end up with 40mb left, more like 43-45, depending on how compressed it is. I assume that it is compression on the go for rootfs (if someone has better explanation, lets hear it), which makes microB binary for example start much faster from slower eMMC as it then is uncompressed and starts almost instantly. From compressed NAND it uses more CPU and takes longer to start (at least my experience).

Those who "never" had this problem probably joined in 2011 and I wonder if they ever even read the long threads about this problem that were produced just before the N900 was released to the common people.

We just need DeviceKit. As long as the kernel exposes mmcblk1 as removable, this thing'll pick it up.

(NOTE: GNOME used to do this with HAL scripts. Maemo uses HAL, and I don't think pulling out HAL is a good idea. P.S. HAL is deprecated everywhere!)

Anyways, we'll need to simply remove whatever part of a script runs genfstab.awk, and uses variables set by that thing in every damn bootup script.

Would implementing only udisks from the DeviceKit work (leaving network, audio, input, display etc to HAL)?

EDIT: first block - udisks requires gudev (at least configure says so), svn pulled quite empty sourceforge tree with gudev.mdp/mds and traylib/test.cs, nothing in ./src per se :/ Maybe ubuntu armel gudev package will work?

Nope. Requires libgudev which requires libudev0 (this ubuntu deb installs fine) AND requires libglib2.0-0 >= 2.22.0 (vs 2.20.0 on device): (http://maemo.org/community/maemo-dev...lib_on_maemo5/ bad things can happen?)

Forcing ubuntu libs worked, buuut udisks requires even newer libglib according to configure >=2.31.13... this is not gonna work Oneiric got only 2.30.
Would forcing Precise libglib be a 'very bad idea' or just a 'bad idea'??

Passing variables to see how many other things are missing:
libglib, libgio 2.31.13, libpolkit-gobject-1 0.92, libpolkit-agent-1 0.92.... no way