euphoric215: there should be no spontaneous rebooting of your tablet.

After downloading the image, your tablet should sit for about 15 minutes "unzipping" the image file, but this will make your tablet very sluggish. It shouldn't freeze it, nor cause it to reboot. Even weirder is the symptom of freezing and rebooting in the middle of the download.

I believe there's something more seriously wrong with your tablet.

First, make sure your tablet is running the latest version of OS2008.
Also, make sure you don't have the internal memory card corruption problem.

I don't know what else the problem might be...

Thank you! I did have the corruption problem. In fact, my mccblk0p1 reading (1922972) was closer to my blk1 reading (1966080--still too big) than my blk0 (7862272--suspiciously close to the size of my external card, and quite close to the mccblk1p1). Anyway, I reformatted both cards.

At first, that seemed to work. I got over 50% of the download before it crashed. However, after that it started crashing every 5-10%. I got frustrated and re-flashed the device. I then downloaded the image on my XP desktop and copied it onto the external card via usb (faster, having now waited several hours in all for that download, lol), and this time the installer recognized it and successfully completed the process. Yay! Success!

I don't know what the problem was in the end, but everything works great now. Thanks for your help! And great work, btw!

Hello,

Thanks for this neat hack.

Anyway i've got a little problem : i can't run 2 instances of "debbie" at the same time. This prevents me from running the Debian HW keys with any debian application (because xbindkeys is killed when the application is launched)

Here is how to reproduce :
In a second term window (while leaving the first one open) :
Second command fails and the first one is killed with a message "Session terminated, killing shell... ...killed."

And then i'm left in a inconsistent state (some directories mounted, some other not), and I get a file /debian/var/lock/chroot-complete in my root filesystem

To have the thing work again, i need to manually clean all the mess (umounting remaining directories, removing the loop device and cleaning /debian)

From a quick look at the ezchroot script : it shouldn't do the "/debian/var/lock/chroot-complete already mounted here! Unmounting..." thing, because image is the same, but i didn't look any further


I'm using Chinook & last easy* packages :
Any idea ? and sorry for long post

Thanks,
Eric

Thank you very much, eber42, for testing the new packages, and for posting such a detailed bug report.

You are correct, it should NOT unmount like that. That code was added to allow users to run a second image instead of the first image, but it is unmounting even when the image file is the same.

I will fix that bug ASAP (this evening) and post the fix.

As always, if you need a working version, the version in Extras should do the trick. But I would prefer you to keep beta testing...

UPDATE: It's a dumb bug. I wrote "echo /debian/var/lock/chroot-complete" instead of "cat /debian/var/lock/chroot-complete". You'll see a fix when I get home.

New versions in the qole.maemobox.org repository. I think these are the last beta-test versions; I'll probably put them into Extras later this week.

easy-chroot
- fixed the bug found by eber42

easy-deb-chroot
- replaced qole's bizarre one-line keyboard with pton's sane two line mini-keyboard

Qole, Thanks for this quick fix,
It works nicely now.

But I think you had two different issues:

• Detecting image change when it wasn't the case: this one is fixed
• Leaving the device in an inconsistent state when changing image (i.e. calling closechroot from ezchroot): i've not checked this one because i've got only one image.

And don't worry, i'll continue to use beta version (stable software is boring )

I think calling closechroot from within the script should be safe if you are going to mount a new image. However, if the closechroot fails, as it did in your case, it should cause the whole script to fail. It looks like the main problem in your case was that the closechroot command failed but it continued to try to mount the new image anyway.. That was somewhat disastrous...

Qole, i'm revisiting my isomount (ext2run) and was trying to figure out how to decouple the mount/chroot in your ezchroot.

Looking at your ezchroot it appears to use a lock file? But that lock file determines whether you should do both... mount and chroot. I dont see how to make it do only the chroot.

Im adding a new method for ext2 appliance which I'm calling ext2graft which allows calling script before and after chroot while image is still mounted. If your ezchroot script i want to use that for chroot but can't figure out how to prep the script.

Here's my script i'm trying to wedge it into... any ideas?
http://wardenclyffetower.com/MaemoFi.../ext2graft.txt

This script is not for most ext2 appliances, but for rare ones that need full control, but covers all the areas i need to handle (without knowing beforehand whether the appliance even needs a chroot).

pipeline: the "lock" file ($CHROOT/var/lock/chroot-complete) determines if the given partition/image has been mounted already on the given directory. If it is already mounted, it skips the mount and goes on to the chroot. If something else (another filesystem) is mounted there, the script calls "closechroot" to unmount/close the mounted fs, then it goes on to mount the given fs and then chroot into it.

(this was the part that was broken and eber42 found)

Would you like me to break this into two scripts, a mounting script and a chroot script? I would have the chroot script call the mounting script at the proper place. That might also give me some better control over error states... hmm...

The "lock" file would be used for the mounting stage, rather than the chroot stage, since it really can only be used to determine that something is mounted, not whether you are chrooted into that directory...

Also, please note that my most current scripts are in the easy-chroot package on my repository. Use those rather than the ones from the post attachment. I'll repost the scripts when I upload to Extras.

I believe i have the latest scripts which i got from your repo.

Hmm, this is tricky from a policy point of view. Ok so your lock flag/file determines whether the fs has been mounted+binds.

I guess i'm looking for the mount operation to be atomic (done by my script) and binds+chroot to be other operation done by ezchroot.

I don't want to be too intrusive so i'll just make a few suggestions/requests to clarify how this might be reworked/reworded. I'm not certain anyone other than myself would benefit so i have no problem manually chrooting using my old way if you dont want to support this level of control....

- Perhaps the lock file could be renamed to something like fixture-setup. Only because this reminds me of nunit/junit tests where you setup and teardown the fixture but in between you run many operations.... but the chroot is not part of the setup, its one of the operations.

- I'm thinking i want to ask if you can add parameterized flags to control mount/binds+performancetweaks/chroot operations independently. Could just be 1 1 1 or for my instance 0 1 1 and perhaps default to 1 1 1 if those params are not passed. Then if those flags are set you would use those instead of the flag file. I suppose the closechroot would have act the same way.

The downside is that the 'flag' is not preserved between invocations, so at that point you would be passing responsibility to the calling script to make sure that subsequent operations (on a single mount) keep the mounted fs in a proper state (avoiding re-symlinking on a single mount or mounting twice).

I could add this logic to my scripts (for my purpose), since I dont support simultaneous chroots on a single mount. I currently 'own' my mountpoints (created as part of deb install) which have a default file ext2mount.txt i can test for to see if mountpoint is 'free/available'.

Since i have backup solution, it might be best to let this sit for awhile until you get a handle on how other people want to use these scripts. But i have gained alot from this and earlier iterations of your chroot scripts so thanks to you and benson for working all this out so that i can use it for the myriad of permutations i intend to bend it to