[Debian] Running Debian in a chroot - Page 25 - maemo.org

Benson | # 241 | 2008-07-23, 18:47 | Report

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

Originally Posted by

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.

Originally Posted by

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!)

Originally Posted by

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.)

Originally Posted by

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.

Originally Posted by

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.

Originally Posted by

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.

Originally Posted by

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:
tekplay

fatalsaint | # 242 | 2008-07-23, 19:05 | Report

On Maemo:

Code:

# cat /etc/passwd
user:!:29999:29999::/home/user:/bin/sh

On Debian:

Code:

# cat /etc/passwd
user:x:29999:29999::/home/user:/bin/sh

The important thing is the 29999.. the user account permissions will work same without copying the maemo passwd file over the debian passwd file. Most other maemo users appear to have the same UID/GID as well.. It also appears the Maemo passwd file has not been shadowed <booooooooooo!>. That shouldn't make a difference one way or the other.. the UID/GID are the important ones and all the ones I'm seeing where they are the same, are the same.

Well.. except messagebus and haldaemon...

Benson | # 243 | 2008-07-23, 19:23 | Report

Originally Posted by fatalsaint View Post

It also appears the Maemo passwd file has not been shadowed <booooooooooo!>. That shouldn't make a difference one way or the other.

Especially since none of the accounts have passwords...

fatalsaint | # 244 | 2008-07-23, 19:25 | Report

Yeah but still... i set a root password and there it is in silly encrypted old-style passwd form instead of where it should be, in shadow

They may not come with passwords out of the box.. but they come with the ability to set them.. should have shadowed the empty password file

Benson | # 245 | 2008-07-23, 19:36 | Report

Well, don't use passwords. Real men use public-key authentication.

psykosis | # 246 | 2008-07-25, 13:36 | Report

While I could find methods on the board to make a "switch" key to allow for toggling between right click and left click, I had not found a direct way to make a simple "press a button and touch for right click" that is more transparent, however I have found a solution that seems to be working great, at least for my Enlightenment environment, however I am fairly confident it would work under IceWM, etc.

Install xbindkeys (as root)

PHP Code:

apt-get install xbindkeys
Edit the .xbinkeysrc file (as user)

PHP Code:

vi ~/.xbindkeysrc
Add these lines to .xbindkeysrc

PHP Code:

"r-mouse" F8 "l-mouse" release + F8
Create the r-mouse and l-mouse scripts As root, create a /usr/bin/r-mouse file that contains:

PHP Code:

#!/bin/sh /usr/bin/xmodmap -e "pointer = 1 2 3"

and as root, create a /usr/bin/l-mouse file that contains:

PHP Code:

#!/bin/sh /usr/bin/xmodmap -e "pointer = 3 2 1"
Make these scripts executable: As root:

PHP Code:

chmod a+x /usr/bin/l-mouse chmod a+x /usr/bin/r-mouse
Run xbindkeys: as user, run xbindkeys and then while your holding F8 (aka the "-" key on the n800), and touches should be a right click.

On an semi-related note, I tried modifying the program that was a solution to the right click issue on the Zaurus, however it appears to have some issues (I could only, depending how I set it up, have the right clicks register for windows or for the desktop, not both). If anyone wants to play with it, here is the binary and source. The program takes two arguments:
cmouse [Button] [State] where Button = 1(left), 2(middle), 3(right) and State = 0(Release), 1(Press), and 2(Press and Release)

The Following 3 Users Say Thank You to psykosis For This Useful Post:
mthmob, qole, tekplay

qole | # 247 | 2008-07-25, 18:36 | Report

Benson, can you please get me your correctly formatted chroot script asap? I want to post my Bundyo-Benson-Build this weekend. All I'm aiming for in this release is a clean-up of the maemo side; updating the chroot side will require a lot more work and some clever scripting...

Last edited by qole; 2008-07-26 at 00:05.

qole | # 248 | 2008-07-25, 21:59 | Report

@ Stskeeps:

I do believe there should be two projects, or at least two sub-versions of a single project.

I don't think it needs to be divided along the chroot / boot line, however; nor does it need to be divided along any other technical line, like where you put your rootfs (image file, bootable partition, directory in a big bootable maemo partition, etc).

The "Tablet Debian" project needs to have two sub-projects:

Advanced users (both bootable and chroot)
Plug-and-play / Easy set-up (probably chroot / multi-WM via xomap or Xephyr)

My interest, as you may have noticed, is the plug-and-play flavour.

The highest priority in this is to ensure that it "just works." Someone with no Linux background can buy a tablet at Best Buy, come home and set it up, get the hang of OS2008, then install Debian within the hour. All technical aspects are servants of that goal. The most important question to ask when working on this project is, "will this make things easier?"

There should never be a point when the user has to touch the command line. Every choice should have a gui menu. Also, the impact on the existing OS2008 should be as small as possible. Don't install anything that isn't absolutely necessary. The project should have as few maemo dependencies as possible (preferably none), and it should be dead-simple to uninstall.

Also, since new users have higher expectations, we should focus on speed and optimization of applications.

The advanced user flavour is also important, but the priorities are different:

making sure things are very flexible (I want to boot and chroot to my Debian rootfs... in fact, I want to be able to choose which of my three Debians I want to mount and use!),
menu-driven gui is not necessary here, the user should know how to edit a config file and apt-get install from the root prompt, etc. Of course, good clear instructions are always important.
making sure that we have access to advanced features of Debian (sshd, cupsd, wireless, bluetooth, etc)
installing as little as possible "out of the box"; the user should start with a basic debootstrap rootfs, then they can add "layers", such as "(1) make bootable," and "(2) add xfce4 window manager"
backwards compatibility with plug-and-play Debian; users can install plug-and-play and then, when they're ready, "upgrade" their rootfs to the advanced flavour

Last edited by qole; 2008-07-25 at 22:05.

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

Benson | # 249 | 2008-07-26, 01:31 | Report

Well, here it comes...

debian

Reads configuration from ~/.chroot; all defaults are the same.
Since hilda is now obsolete (see below) it now drops a file in /debian/tmp/ to mark chroot ready; this is actually more robust, as cancelling after the filesystem is mounted won't leave it persuaded everything's cool.
The mount point may be changed from the default of /debian

debbie:

debbie with no arguments now drops you to a non-privileged chrooted shell.
hilda is now obsolete; debbie now passes su through to debian, as needed for above; eliminating one Debian-side script is a nice side-benefit.)
DISPLAY is preserved, if it exists. (I think it should always be set, normally to :0.0, but not sure.) Good for multi-Xomap, USB-VGA, or otherwise multi-X-server configs, with no change for standard config.
User to drop to is now configurable; defaults to user, of course, but can be set...
Reads the same ~/.chroot as debian

.chroot

Example config with defaults documented in comments.

Overall comments: Changed a lot of things that were set as environment variables (export FOO=bar) are now shell variables (FOO=bar); indentation is changed to "correct"

style, efforts to safely quote things to prevent complete breakage in the event of empty or space-containing definitions...

EDIT: Updated tar. All better now, sorry about that.

Attached Files

debscripts.tar (10.0 KB, 121 views)

Last edited by Benson; 2008-07-27 at 02:31.

The Following 3 Users Say Thank You to Benson For This Useful Post:
fatalsaint, psykosis, qole

debernardis | # 250 | 2008-07-26, 08:07 | Report

Benson, could you control your tar file please? sbin/debian appears damaged.

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