View Single Post
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#241
One thing to note: while I'm editing/rewriting some scripts for qole, this is definitely his project, and I'm using a strange hybrid of it and Beta3; when he gets back, it may be revealed that I completely goofed some of my understanding on these issues...
Originally Posted by Stskeeps View Post
After reading through 24 pages of Debian chroot posts.., just a summary and some questions / various coherent and incoherent stuff

"In-maemo" packages/editings:

* 'Debbie script'/Hilda etc that executes command in chroot (and mounts if needed), no X session needed, and views in maemo Xserver
* Methods for starting full debian X session, like /etc/init.d/chroot-start-xephyr-xsession is a way to do

* Application .desktop files that runs the debbie/chroot script for easy access, using matchbox as WM (maemo's)
* Maybe matchbox movable windows hack & sudo tricks

- My installer can download and dpkg -i stuff that's needed to support this through easy configuration
Ways of storing installation image:
* ext2/ext3 image files
* tar zxf onto a partition (johnx's beta3)

I'm personally not fond of image files but I guess they're good enough when there's no partitioner (which we do have in NIT-Debian).
Or for scenarios where we have a "easy debian" deb (that would bootstrap the system and set default settings?) - but I haven't seen "bootable" ext2/3 images?
AFAICT image files are only used for chrooting; it's possible, I think, to boot from an image file, but makes little sense. The one thing that is gained is the ability to resize to minimize disk usage, without repartitioning, but I don't see repartitioning as all that evil. In either case, resize2fs is needed.

X-server possibilities:

Straight to OS2008 X display.. (chroot run)
Xephyr (ability to have in a Maemo WM window, both fullscreen and not?)
VNC method (slow..?)
Xserver-omap on another virtual console (enabling switch between Maemo and Debian in both user interfaces through chvt?)
- does this have performance penalty?
- advantages of this would be similar scripts for boot and chroot for starting X session? (see http://trac.tspre.org/projects/nit-d...it.d/x-session).
- I do all the GTKSTYLUS etc tricks in Xsession instead, but I guess that also means that the goal is a X session, not just a debian app with target on Maemo X display..
VNC is slow; Xephyr's definitely the way to go for nested access.

I'm pretty sure there's no performance penalty for 2nd Xomap; no benchmarks, though. Correct that chvt is needed to switch, and at present seems the only way. (I'm running this right now.)

It has the advantage of being completely independent of the chroot, and also completely useful outside the chroot; I've already got plans to work on this as a separate project, designed to work cleanly with or without chroot, with the plan to get it in extras-devel. (And thence to extras, eventually.)

It probably also benefits from similarity with Xsisusb startup, at some point...

Actually, just realized this can be accomplished two ways. What I'm doing is running Maemo FVWM2 in Maemo Xomap, and using this all-Maemo X session to run individual chroot (and Maemo) apps. But you could also chroot to Debian and launch a new Debian Xomap, and a Debian WM... Interesting.

Actually, maybe (Debian? or not?) [xg]dm is the answer? At least gdm, I know, can be used to spawn new X servers on an as-desired basis. It should be possible to use that directly on boot, and also through chroot (or also run a Maemo ?dm for chroot use)... Just thinking out loud, I'm not sure on the details.

(Also, I hadn't even got to figuring out where the gtkstylus setting was done, so it's presently not implemented in chroot on mine. Thanks for that info!)

Maemo-Debian interaction, /etc/group, /etc/users..:

Just viewing differences of those between maemo and my setup..
for the sake of the tablet-user (which i have a package creating), there's nothing saying that we can't have the useradd command
set a specific UID/GID (29999/29999) for the user when adding. Is there any other technical reason why they should be shared?
Well, in my case, at least, any user or group owning files on my SD's first partition (for general purpose storage and data transfer) must be the same, because I'm running ext3 there. Mainly those are user.users, but it's safe to keep them the same. Beyond that, I'm not sure of any other reasons. (Honestly, I should check that they are the same; I inadvertently wiped my boot /etc/passwd with the chroot version, but so far everything works.)

DBUS communication? What issues are there with communicating with in-Maemo hald/dbus from Debian?
That's one for Qole, as I'm not doing it the same way.

Maemo-Debian UI interaction - scripts that "make life easier" when in chroot such as switch back to OS2008, etc.
I guess it would be possible to detect if we booted or we chrooted, either through environment variables or other things,
so we could have a package adding different tricks for UI interaction with Maemo, that just doesn't
initialize in booted Debian (and maybe some that doesnt activate in chrooted Debian either).
I had some effort at this for keeping separate passwd,group, etc., but was hoping to ditch it. The way I was trying to keep things straight did not work well, and needs some rethinking.

Besides some of the observations given in this, I see no reason whatsoever that chroot and boot version can't be two sides of the same thing
- and maybe even that the installer sets up chroot initially but user can also choose to dual-boot and boot into the same Debian session.
Possibly; I think having both set up is the most generally useful scenario, if we can pull it.

In any case, it could be interesting to combine the creativity of the chroot people and the booting people to give a better user experience, instead
of two groups working on exact same thing..
Absolutely; I think we'll come out ahead if these projects can be merged.
 

The Following User Says Thank You to Benson For This Useful Post: