I hope ... it is the last question from me. Do I need to edit etc/fstab to add permanent root about that "mount /dev/mmcblk0p4 /mnt/debian" or there is better method? What options/argumennt other that "/dev/mmcblk0p4" and "/mnt/debian" I need to put?

Add1: Seems I have bigger problem. When I try to mount /dev/mmcblk0p4 to /mnt/debian my phone starts loading the CPU at 100%. This does not allow me even to try the ED on the phone.
Sure I will try to serch the tread and the forum, but if you already have the idea what is causing this, please help.

Editing fstab is pointless since the file is rebuilt on boot. You can figure out how to permanently mount things by following the comments at the top of /etc/fstab, it tells you which scripts build it. I can't give you a definite answer since that depends on what flavour of Maemo you have installed (stock, CSSU, testing, Thumb...). Editing those scripts is not for the faint-hearted and I would not recommend it if you are not familiar with Linux.

On the positive side, you don't have to do any of that. Just edit your /hone/user/.chroot accordingly to run ED from a partition rather than image (let the comments in the file guide you). That way you won't mount your extra partition on boot but ED will mount it on start and unmount it on close.

Btw what happend to the folder based chroot? I thought someone was going to push a new update to easy chroot including the new goodies.

I guess that "someone" was me? Well, directory based chroot works nice here, and should do for anyone who is willing to follow steps described "few" pages ago (required to modify some chroot automagic scripts).

Of course, it would be much better to upload a fixed version to repos. The problem is, that my chroot setup is so much modified - sometimes in ugly way - that it no longer looks like what easy-chroot installs by default, at all.

Properly integrating those changes/fixes/improvements into more general-purpose package that would be at quality level in-pair with currently packaged chroot would require quite some time, and sadly, I don't have that free time ATM. I'm not sure when I'll have few spare days to clear this mess.

/Estel

Actually i wasnt pointing out anyone specific, i just thought somone might have created a package or script so i just asked. Thanks, ill read the pages and try to create a stable script. Btw which one is most recent and stable squeeze image? The ones on qoles site are of year 2009, so can you post a link or pm me link of a squeeze image? And is wheezy stable? I do remembe it having problem with some apps, i dont use chromium but i do use gimp. Thanks.

I don't consider wheezy stable for ED, as it:
a) requires chromium from squeeze, as wheezy one segfaults on armel
b) have problems with glibc. So far, it manifested itself only by crashing gparted, but have potential for other problems
c) GIMP from Wheezy crashes on ED, when trying to change font settings, while using "insert text" tool. Reasons are unknown, no one tested if it is ED problem, or related to whole armel, like chromium problem.

As for "which squeeze image is most recent", I have no idea. I'm using my one (squeeze-img-estel, or something like that), upgraded to latest.

/Estel

Hello again. Seems that the mounting exist without doing anything by me. If I click icon from ED image and it starts even after reboot. Now all generally is working. Just I have met one problem - when wifi is on (in my case) and I start LXDE the left and up-left part of the screen (with taskbars etc.) flickers and I can not do anything. Tried to search the tread with "LXDE+flickers" and similar words, but found things not explaining my problem and it's solution. Have anyone met the same problem?
Otherwise it is very good thing, but unfortunately it did not make what I wanted. Iceweasel was able to install the bank certificates. Establishes the https connection. Since here all fine. But when I decide to sign a transaction the bank site opens second windo to choose the certificate to sign and to enter the master pass of the browser. And here is the problem. The second window is with fixed dimensions which are out of the LXDE dimensions. Then I can't see if the cursor is on the place to enter the master pass and then to push the button "OK" at the bottom of this screen. If there is a way to zoom the whole LXDE probably it will work. I tried ctrl+- but it does not work on this second window. On the main it is working.
Have a nice day

I've never seen this.
It sounds like like Maemo/Hildon/whatever challenges the claim of the ED window to be on top of everything else.

shot in the dark:
Does the flickering go away if you unmaximize the ED window by pressing Ctrl+Backspace and the return to it?

None that I know of.
Theoretically you should be able to create a virtual desktop within ED that is bigger than the N900's screen. I never tried that with xephyr and a touch screen, so I don't know if it actually works or if the result would be useable.

What should work is to move the window by selecting the "move" option from the window menu and then dragging the window to a position where you can reach the input field and button.
This will at least work once but might not work a second time if you have to move the window to a place where you can't reach the window menu again. In that case you migt want to have a look at wmctrl. It's a cli tool which (among other things) allows you to move windows, so you could call it from a terminal to move the brower window to the right position. In connection with xbindkeys you could even bind that window move to a keyboard shortcut.

The minimizing with Ctrl+Backsp and then maximizin does not work. If I minimize, switch-off the wifi and then maximize back it it is OK. I mean even if it flickers because wifi is ON if I turn it OFF flickering disappear and the task bars are accessible.
The other thing with the movement of the window will try these days.

I may have made some progress towards a Jessie dist-upgrade. At least I managed to dist-upgrade my basic ED image.

What I did is basically going through the source code of Debian's eglibc package and change every relevant kernel version check from 2.6.32 to 2.6.28, which would be these files:
Unfortunately while the libraries still build some eglibc testsuite checks will fail, causing Debian's debuild not to build packages from them. So I had to make sure the testsuite results would be ignored, which can be done by making sure the compare script always exits with error code 0, which can be done by simply uncommenting the penultimate line in this file:
debuild will then build a whole bunch of custom packages from the eglibc source code, but as far as I can tell, only libc6 and libc-bin will actually be needed. You'll find those two packages in the link [1] (which should work for at least 30 days). The rest can be taken from the debian repository.

Using custom packages for a dist-upgrade is a bit tricky, especially when these packages are the very core of a Debian installation. I tried to install the modified libc6 and libc-bin packages via dpkg prior to the dist-upgrade, but got an error because the packages locales and locales-all could not be deconfigured.
My quick&dirty solution was to simply uninstall them (warning: this temporarilly broke my keyboard support, xvkbd's on-screen keyboard still worked, but only partially - letters and cursors worked, numbers and special characters didn't) and reinstall them after I upgraded libc6.

Then I set my libc6 and libc-bin on hold to make sure they won't be replaced by packages from the Debian repository and ran the dist-upgrade.
edit: For some reason I had to reinstall lsb-release afterwards.


The tricky thing of the whole process is that you'll need a working Jessie/armel installation to build these packages in the first place. So it's some kind of a vicious circle. I managed to break it by using a Jessie/armel chroot on my Cubieboard2, which took about 8 hours to build the packages. In parallel I started the same task in a qemu-arm machine on my Desktop PC (i7-2700k) which is running for almost 48 hours now and I expect it to run at least another 24 hours.
Cross-compiling for armel on an x86 machine should be the fastest (from previous experiments with compiling eglibc in amd64 I'd expect it to take an hour on my Desktop-PC) if you know how too do that. I don't.
However, once you have a working Jessie installation on your N900 theoretically you should be able to build newer versions of eglibc on your own in maybe a day or so. I haven't tried though and of course there's always the watchdog.

As some kind of a disclaimer, I honestly have no idea what results will come from my changes. There may be no regressions compared to Wheezy at all but it may also eat your children.
I think I read either in the libc6 or udev changelog that it will break udev, but I haven't tried and at least from my point of view there's little use for udev in ED in the first place.
One thing I have noticed is that LXDE's cpu monitor doesn't work properly anymore. It shows single peaks every few milliseconds no matter if the device is idle or under full usage. Also Jessie seems to be quite a bit slower than Wheezy. I have no idea if these problems are due to my changes or due to the ever-growing age difference (and therefore potential incompatibility) between Maemo and Debian and a general tendency of software to bloat as time (and versions) go by.

Of course since Jessie is still testing this workaround may not work anymore when Jessie is released. In fact the very next update to eglibc or any package that depends on it (which is virtually the whole distribution) may break it.

Oh, and before you ask: Jessie will neither fix the gparted, nor the gimp problem encountered in Wheezy. I checked both. At least for gimp I suspect some underlying outdated Maemo libraries to be the real reason, not ED itself. But unfortunately I can't remember where I got that idea from. I may try to verify this by running an ED image on my Cubieboard2 (where both programs work fine natively) but I'm not sure yet since answering this question seems completely academic to me.


[1] http://netload.in/dateikeNBnk8xOg/eg...ulu.tar.gz.htm