Re: Running Debian in a chroot
 

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

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

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

That's one for Qole, as I'm not doing it the same way.

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.

Possibly; I think having both set up is the most generally useful scenario, if we can pull it.

Absolutely; I think we'll come out ahead if these projects can be merged.

Re: Running Debian in a chroot
 

On Maemo:
On Debian:
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...

Re: Running Debian in a chroot
 

Especially since none of the accounts have passwords... ;)

Re: Running Debian in a chroot
 

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

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

Re: Running Debian in a chroot
 

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

Right Click in Debian chroot with an n800
 

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.

1. Install xbindkeys (as root)
   PHP Code:

   ---

   apt-get install xbindkeys 


   ---

2. Edit the .xbinkeysrc file (as user)
   PHP Code:

   ---

   vi ~/.xbindkeysrc 


   ---

3. Add these lines to .xbindkeysrc
   
   PHP Code:

   ---

   "r-mouse"
    F8
"l-mouse"
    release + F8 


   ---

4. 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" 


   ---

5. Make these scripts executable: As root:
   
   PHP Code:

   ---

   chmod a+x /usr/bin/l-mouse
chmod a+x /usr/bin/r-mouse 


   ---

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

Re: Running Debian in a chroot
 

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

Re: Running Debian in a chroot
 

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

1. Advanced users (both bootable and chroot)
2. 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

Re: Running Debian in a chroot
 

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" :p 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.

Re: Running Debian in a chroot
 

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