A config file would be great but an alternative might be to bind-mount a directory from a larger partition into MyDocs/cities. However, that would require further work to unmount and remount the bind when exporting MyDocs to USB.

Does anywhere know where MyDocs normally gets unmounted to handle the USB access?

Graham

I guess what you are looking for is:
/usr/sbin/osso-usb-mass-storage-disable.sh
/usr/sbin/osso-usb-mass-storage-enable.sh

Just a quick note for anyone skim-reading this thread and considering this:

Don't!

/usr can be done (see earlier in the thread) but you need to modify the startup files, or else the device will not boot successfully..

/etc - I don't see how this could work. You need /etc on the root partition so that /etc/fstab can be read in order to know how to mount the other partitions! I think this would come under "impossible", and certainly shouldn't be tried by anyone who hasn't got a plan to deal with /etc/fstab

(ok, you could have a skeleton /etc/ in place on root partition and mount the full blown one over it.. Good luck! )

No, I know about those. They do not unmount anything. Something must be unmounting MyDocs before calling those.

I guess it is /usr/sbin/ke-recv -- is that open source?

Graham

Ah. Found it: /usr/sbin/osso-mmc-umount.sh

If you mount anything into /home/user/MyDocs you need to edit /usr/sbin/osso-mmc-umount.sh to unmount them before it tries to unmount the MyDocs device itself.

And then remount them in /usr/sbin/osso-usb-mass-storage-disable.sh.

Actually, we really need to create an infrastructure for handling additional mounts which would handle the /etc/fstab manipulation and the mounting at boot time, and the unmounting and remounting of anything which is using the VFAT partition before exporting it.

Graham

FYI: I've started fixing ke-recv and system-services, and porting GNU parted.
see my post http://talk.maemo.org/showpost.php?p...5&postcount=48

This feels so familiar...

I was an avid Zaurus c760 hacker back in the day, building a custom debian, then using pdaXrom, openzaurus, angstrom, etc.

I'm very happy Nokia's gone the honorable (and long-term inevitable, I believe) route of open, transparent and empowering design... and as I said in the hello thread .. a well supported debian-in-pocket system is like a dream come true to me.

But, it is a shame Maemo doesn't use a cleaner fs layout. It really should be based on initrd for initial booting ("flash rom" .. 16mb or so), that mounts 32gb root (/) from the MMC. That's it, that's all.

IMHO there's no real performance argument... if program data keeps flushing executable/lib cache, tune the VM to flush buffers earlier, etc. If worse comes to worst, add another 32mb physical RAM (I know, too late for that, but still).

Then give the user an option of creating a loopback VFAT fs off the mmc (of whatever size), or let them choose the SD card exclusively if they want.

So much simpler, and no space restrictions.

Updates shouldn't be flashed to the device .. they should be distributed with apt, so they don't need to rewrite /.

A soft restore procedure could wipe everything except /home and unpack a fresh system without damaging user files. A hard restore could wipe and reinit the mmc.

Minor complaints aside, go Nokia! You guys rock! Can't wait for my n900 to get here.

Is it possible, to use the eMMC as rootfs and the NAND as swap?
Maybe someone already tested, would be interesting for me if there are differences in performance...

AFAIK a hidden NAND is already used as swap.
PR1.1 seems to have made it easier to integrate a boot menu (and to boot from eMMC)
http://mer-project.blogspot.com/2010...e-in-pr11.html

No, swap is on mmcblk0p3 by default.

Already installed the bootmenu, but how to boot into debian partition or clone rootfs to eMMC?