pichlo: you should gather all the information about directory based chroot in one place - otherwise it'll all become practically lost (when ed thread becomes 350 pages long. A new thread for the tutorial would be the best. I might help with packaging if you decide to push dir ed scripts to devel.

Is the barebone image this one: http://qole.org/files/basic-debian-chroot-fs.tar.bz2 ?

Yup, that's the one. Note that unlike all other images which are literally that, images that you can mount, this one needs unpacking into a prepared space, be it an image, partition or a directory.

My and Estel's experience with directory based ED is summarized in the (currently) last three or four pages. I never thought about creating a new thread for that. It seems appropriate to talk about it here and frankly, I was not expecting much interest from anyone except the die-hard geeks.

Yeah, but you know, as the thread gets larger it'll all be lost. Or you can just summarize everything in one post and ask qole to put the link in the OP. It'd be nice to post the updated scripts. I can push them to extras-devel.

There was a plan to start new thread (as it's not beta, anymore), after releasing fully working Wheezy image. In last few pages, I've also mentioned, that I gathered all fixes to qchroot&friends from last few months, added my minor tweaks (to fix stupid things like mounting Maemo's /home/user, then unmounting it again 0.5 second later), and I'm planning to release updated ED package into repos.

Now, the problem with Wheezy, is that it contains shitload of problems re ARM, that mainstream doesn't seem to be interested in fixing. Particularly, gparted spazms out due to glibc error:
...which I'm sure isn't gparted problem, as I tested reverting to versions, that were working before (and even older - tested to as old ones as lenny). This imply mentioned glibc problem, which, in turn, may mean that many other programs may not work properly (just no one tested wheezy ED as thoroughly to detect them).

There are also smaller, but irritating things, like GIMP crashing on text input brush, or chromium not working at all (I'm using Squeeze one in Wheezy, as workaround). The latter for sure applies to whole ARM, not only our humble case, and is present+untouched (by mainstream) for AGES.
---

Now, this probably could be work-arounded by doing some strange Squeeze-Wheezy mix (downgrading glibc, altering dependencies, maybe recompiling some things to use older component), but we already had it with lenny/squeeze mix at ED origins, and I'm not going to even come close to trying it, again. Currently, I'm rather considering downgrading to Squeeze as a whole (mainly, due to this glibc problem, other thing are workaroundable by downgrading particular programs)..

/Estel

// Edit

The thing is, that it's not problem with mounting chroot dir itself. Things that doesn't get mounted are:
...and other like that, while /home/.debian itself is mounted OK. I've even prepared a dummy script in /etc/event.d/, that displays notification text first (requiring closing it by hitting OK), and invoke 'debbie exit' only afterwards - so, I was able to wait few minutes from device bootup, to filter out timing problems. To no avail - it's acting the same.

What made me curious, is that those things shouldn't behave differently with partition or directory based ED *at all*. It's no a real problem, as I said, just... strange.

BTW, pichlo, I'm pretty sure, that you underestimate impact of your directory-based ED ressurecting Many people were using partition-based ED (as opposed to image file-based), for performance reasons. For sure, just like I advocated it in the past, I'm going to do so with directory-based one. There is simply no reason to do separate partition, now* - directory is superior in every way.

*except for fact, that filesystem corruptions caused by N900 unexpected reboots, during ED usage, would result in ED separate partition corruption (most likely) *only*, while having it on /dev/mmcblk0p2 means corrupting home filesystem, *if* corruption happens.

But, in reality, it is not as dangerous as it sounds - in such cases (just like with separate partition for ED), only ED directory entries may get corrupted (in cases, where real Maemo home entries get spoiled too, even separate partition wouldn't help). So, backuping OptFS and restoring it on mkfs'ed p2 (backupmenu way) works 100% reliably (and we need to just nuke chroot dir, and restore it from backup, like with every else normal file/directory).

Benefits due to space-savings clearly outweight it.

/Estel

I have a small problem - 3,73GB sd card with one fat and two swap partitions as recomended in flopswap. This gives me 2216mb for ED. Estels image is to big. I have tried to download Sulus image and install open office in it but failed after some error. So I have decided to download the smalles file which marmistrz was talking about. When trying to extract the file to fat32 partition is says the the file system doesn't cover symbolic links. I have tried to use other file systems but no luck. Generally speaking I would need jus ED with open office or libre office. Other programs are not needed and never used. Any hints how to do it? noob hints I mean

Sounds like you could:

a) use directory-based ED on your home (best performance)
b) put image under MyDocs, then shrink it by uninstalling what you don't need
c) use 8GB sd cards, they're cheap as ice nowadays (3$ or so on polish wannabe-ebay auction site - heck, I bought mine 32GB Sandisk class 4 for 16$ inc. shipping).

Is the ED squeeze sources.list somewhat different than for desktop?

d) format your 2216MB partition as ext3.

Just for clarification, as he may not get whole idea - then, extract content of image to this partition, and use it as partition-base ED (3GB partition uses space for "free space" too, in reality, it's around 2GB). But, that would make you tight on available space, unless you uninstall unneeded stuff.

If i were You, I would got for a directory-based design, anyway - the faster you switch to a better option, the more performance you get. And if willing to use LibreOffice (I don't recommend depreciated OpenOffice, which is now more corporate than FOSS, in spirit), using image-based ED will hurt your performance a LOT (few people made comparisons, buried somewhere in this thread - differences were more than noticeable).

/Estel

As recomended I have formated the parition to ext3. Now I could copy all the files from my pc but trying to start ED gives me "you have no debian.img.ext2 file on your memory card". I have tried to search what does it mean to "use it as partition-base ED" but came out with nothing.