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.

Re: Running Debian in a chroot
 

I PMed Benson the same thing ;)

Re: Running Debian in a chroot
 

Well, I agree with that point. Mostly, my installer is a project to show that installation of Debian on a tablet can happen without distributing around big installation images.

For my sake, having a UI on top of Installer where you can choose "Easy setup (chroot?)" and "Advanced users", where different targets can be chosen, and things just work, is of course the optimal solution.

I agree with this and that's how it is right now in the installer too wrt my "environments". The main itch I had regarding beta3 was that it was very much a single type of environment-image and not very flexible to build "new" environments around.

It would be ideal to be able to start out with a chroot and then click a menu item and it would upgrade it to a bootable Debian, by just running apt-get install nit-boot-support or whatever in the background.

This one I might be a little curious about, - ofcourse, installation process should be possible to start right after getting the tablet - not sure installation process and downloads and such takes less than an hour though :)

Atleast compared to my work with beta3, I've found that having the different boot tricks and user experience seperated in packages, has made it much easier to refactor the system and alter the installation image at will when needed.

Admittedly, distributing tar.gz's or ext2 images of Debian is "easier", and this would obviously still be possible to do even with installer, but using the installer and doing things in .deb's for this gives the flexibility to instantly cook fresh images when the underlying Debian armel port changes or we need to change something about the UI.

So, we can make "easy" plug-and-play images (downloading big tar.gz's from the web/torrent) that are initially made by the installer and simply wget'ed down, or "flexible but still easy", installer that sets up a partition on a MMC and debootstraps the system up to your choice, and allows you to "upgrade" to Booting Debian easily, or "advanced", where you install a full debootstrap with the intended booting/chroot environment on top, etc.

Are we speaking as part of installation or part of UI, or both?

My installer has (pre-startup) dependancies of python, screen and ncurses-base (with an actual UI this might not be needed, but other packages like pygtk would be..)

To install Debian, it requires wget, subversion (getting down packages from svn), binutils (debootstrap), libslang2 (cfdisk), e2fsprogs (mkfs.ext2/ext3), cfdisk, bash3 (debootstrap), and debootstrap.

Excepting cfdisk and bash3 this is retrieved from repository.maemo.org (+ /extras)

That's obvious, since we are both when booting and chrooting interested in the user experience.

Obviously also easy, if we do it with packages and dependencies.

Re: Running Debian in a chroot
 

Benson: (As usual,) Thank you! There are a few much-needed improvements in your scripts, although the indentation is really weird. ;) :)

I'm throwing in a couple of fixes (copy the localtime file and resize the /tmp dir a bit for PDF creation and printing -- I've made the new size another setting in .chroot) and replace the lines where you comment, "I freely confess to confusion; what are these two chars???" (I just chose the weirdest char I could find so that it would never show up, but the whole mess can be replaced with: IMGMMC="`ls -1 /media/mmc?/debian*.img* | head -1`" )...

I'm going to include the .chroot file in my next version, however I am going to comment out everything. I want the defaults to be used in all cases.

I've attached the changes. I've yet to reboot and test them, however :D (the debbie file is unchanged, included only for sake of completeness)

EDIT: Rebooted and tested the new debian script! Found a small bug, wasn't detecting file system type properly. Attachment has been updated.

Re: Running Debian in a chroot
 

Watch out, debbie is broken. Sometrhing's not quoted right, so you can't run a command with arguments (e.g. debbie alsamixer -c0) and have things work...

I'm working on fixing it right now, but the best immediate fix is to shove hilda back in, and change the else clause to still use hilda... That should preserve full functionality, though I haven't tested it as I'm working on fixing it right.
I hope to have a righteous fix by day's end, at the latest; up to you if you want to push an intermediate update, post a warning, or whatever...

Regarding the .chroot; I'd initially tarred it up with a fully-commented .chroot, as you're now shipping, but I messed that up when (after editing .chroot) I had changed the scripts and tried to update the tar. So I just retarred everything (including my now-uncommented .chroot), to get a clean tar, and figured you'd recomment them.

Re: Running Debian in a chroot
 

Drat! I noticed a problem, but I thought it was something I was doing wrong...

I'll disable the download for now..

Re: Running Debian in a chroot
 

Benson:

Since we're re-releasing, we might as well add another bonus feature.

I'd like to have the GTK stylus environment variable (that Darken found) set by default in the chroot, since this enables tap-and-hold right-click in all GTK apps regardless of WM. (as long as libgtkstylus has been installed)

Any ideas how to do this cleanly?

Re: Running Debian in a chroot
 

Well...
One option is to pull in a full file of environment variables that should be set.
+ Versatile, generic, and easily configurable. All done in the non-chroot side.
- Not the right way to accomplish this.

I can't even put my finger on why that's less right, but I've got a strong instinct that the right way is to toss stuff in the user's .cshrc in Debian, and maybe set one environment variable to enable easy detection that we're running chroot from there.
+ Rightness; even greater flexibility.
- Shell-specific, involves tossing junk down into the chroot.

The other is to do just this one, with one line in debbie.
+ Works well enough and avoids making philosophical decisions. Stays out of the way of anything the user does with their shell's configuration.
- A bit ugly, I guess. And requires fixing /etc/sudoers...

Alas, sudo is setup to nuke the environment, making the above fail in debbie.
So that suggests one line in debian, which is uglier.
-Horrible. Don't do.


I think, for now, that the debbie one-liner's the best solution, and I'm putting it in my newly uploaded version. (Coming in 5 minutes, in case you wondered.)

For fixing that, I had to replace the $* in /sbin/debian with "$@"; this is somewhat less portable, but I think I remember that it's clean in all modern /bin/sh. Definitely good in busybox ash. (Bash documentation on the distinction.) Once you get what exactly the difference is, you can see this is exactly the sort of thing $@ was added for...

/usr/bin/debbie was fine, as far as quoting goes.

Modded it to pass environment variables rightly (su was stomping them), but still needs sudoers tweak:
Note that the second line suffices, for our purposes, instead of the ALL = NOPASSWD: ALL that we've been using. Your call which to go with; by letting the user chroot to an arbitrary FS image, they already own the system if they want it. It's not any better security-wise, but might save someone somewhere from doing something stupid. The first line, though, lets us pass GTK_MODULES through, which we need.

Re: Running Debian in a chroot
 

So what was the problem? The $* needed to be replaced with $@ ?

So I have to add the "Defaults" line to my sudoers hack? I can do that.

Re: Running Debian in a chroot
 

Here it is. To be clear, the $* -> "$@" is the only change in debian, so you can just change that..

Re: Running Debian in a chroot
 

To undo the process, will uninstalling the easy-deb-chroot be enough?

Re: Running Debian in a chroot
 

Sorry, missed this....

The $* needed replaced with "$@" in /sbin/debian only; /usr/bin/debbie had "$*" which was correct for it. (All quotes significant here...)

Exactly. Without that, it'll work as before, but the stylus tweak will fail silently.

Re: Right Click in Debian chroot with an n800
 

Hi, psykosis,

I really like the look of your solution. I would prefer to use the + key, but the big question I have is:

If you're using xmodmap already (like we're doing for IceWM and the N810 keyboard), will this hack interfere with your already-loaded keymap? I'm hoping that each time you run xmodmap in your click-scripts it will only affect the mouse buttons, but if it erases the other mappings, I'll have to steer clear of this...

Re: Running Debian in a chroot
 

Yes. Oh, and deleting your big image file (if that's what you're using). Especially with this new version; there's no dependencies so there's no messy overhead :D

Re: Running Debian in a chroot
 

I just want to clarify something about my Debian chroot project.

The big image file is purely for the convenience of folks who don't know how to format or mount a partition, and don't want to be bothered doing the apt-get installs for themselves. I have found the image file to be an inferior way to run apps, myself. It is significantly slower than a dedicated partition, and, to keep it more newbie-friendly, I have to keep it quite small, so it is very close to running out of space.

I consider my project to be mainly about the chroot scripts and the little tweaks we can do to integrate the Debian and maemo environments. That's why Benson and I have been working towards making our scripts work well with whatever version of Debian you have. I personally use a dedicated partition and only switch to the image file when I need to test something out for someone with a problem or question.

I would welcome someone from the bootable Debian camp having a go at making the chroot scripts (/sbin/debian especially) completely "bootable Debian beta4 friendly". I want to be able to chroot into a bootable partition without damaging it in any way.

I especially would like to find an elegant way to make sure that the root and user accounts are aligned with maemo upon chrooting without trashing any extra accounts (such as the mpd user from beta3).

Re: Running Debian in a chroot
 

I will try this as soon as I get a stable Beta4 setup and running. In all honesty it shouldn't be too hard.. biggest problem will be users, like you mention, because the new installer creates the users at install time and the UID/GID's are now totally different than the default maemo.. where-as in beta3 most all the accounts were the same except a few were missing and there was 2 unneccesary accounts with different UID's.

Now the actual chroot/iceWM launching shouldn't be a problem.. the only issues I really see is maybe dbus related for permissions, or sharing files between the maemo and the debian side; because of permissions.

Re: Running Debian in a chroot
 

Qole - just a thought.. what exactly is the point to copying the /etc/passwd and group files from maemo?? That doesn't actually fix any permissions on the filesystem...

in beta3 you notice no difference because user already has the same 10000 UID as on maemo.. so it's unnecessary and does nothing but break mpd and any other unique users.

in beta4 or any other OS.. if your /home/user was created with a different UID.. say 148, and you copy /etc/passwd from maemo to /debian you will still be unable to access /home/user.. the permissions will show UID/GID 148:148 on the directory instead of saying user..

passwd and group really just give easy names to UID/GID matches.. changing the names to a different UID doesn't actually change any permissions.. only new ones created.. which would create for a rather unstable environment..

If my logic is wrong let me know..

Re: Running Debian in a chroot
 

The chroot script mounts maemo /home/user over the Debian one, plus several other maemo system folders (including /tmp); we need to synch permissions so maemo and Debian play nice together.

Re: Running Debian in a chroot
 

Ohhhh right... I forgot about those.. I really need to reload your newer scripts.. i've completely slashed the crap out of the other ones for unique situations lol.

OK .. so I understand the point now when dealing with /home.. I left my /home in tact in the debian side because I made changes to files in there when I was booted into it.. I wanted to make a completely seamless environment whether I was booted or chrooted into the debian side.

Re: Running Debian in a chroot
 

To the beta4 (not sure why it's called beta4, :)
and chroot discussion,

I took some time to edit debscripts to fit NIT-Debian. A patch to build
anything from is at http://bsd.tspre.org/~stskeeps/debbie.patch.

An overview of additional/removals:

* Get DEBUSER from $CHROOT/etc/tablet_user, as we don't rely on user being
'user', and store choice of tablet user in /etc/tablet_user.

* Mount sysfs on $CHROOT/sys

* mkdir -p $CHROOT/media/mmc{1,2},usb

* Mount /home/user onto /home/$DEBUSER instead

* Don't copy /etc/hosts - it's not needed, we have a perfectly good one in
Debian

* I have some doubts regarding /etc/resolv.conf - as it seems to overwrite
the link made by resolvconf .. but I haven't got proper WLAN here in the
mountains (only GPRS over BT, and my Debian isn't set up for that just yet..)

* Do not copy group, passwd. When we install debian the tablet user will
have uid 29999 and gid 29999 and things should go fairly smoothly after
that?

* Do not copy calibration, instead run our x-server-prepare script which
sets up pointercal - this should probably be some thing where it only
installs a new one if the user has set another screen calibration than the
default model ones..

Re: Running Debian in a chroot
 

For arguments sake the users name is "joe".

The default user created currently in nit-debian is with UID/GID 1000 and I have no user with 29999 in my /etc/passwd file...

I was thinking of running something similar to removing the mount of the home directory altogether.. and running something like this:

$DEBGRP = `cat $CHROOT/etc/group | grep user: | cut -d: -f3`
find /tmp -user user -exec chgrp $DEBGRP {}\;
find /tmp -type f -user user -exec chmod g+rw {}\;
find /tmp -type d -user user -exec chmod g+rwx {}\;

That would take all "user" owned files in maemo in the /tmp and give them group readable/writable to the "joe" group on the debian side.

The problem I think in mount /home/user over /home/$DEBUSER(joe) without changing the debian /etc/passwd file is that the user "joe" will have UID/GID 1000 (on my debian) while /home/joe will have UID/GID 29999.. so the Debian will think the the "joe" user does not have rights to his own home directory. If we don't mount over the top of /home/joe .. and give r/w permissions to whatever /tmp files necessary for him to interact with the display and dbus.. it should work...

Only downside is the inter-operability between maemo and debian.. IE if a user makes a change to XCHAT in maemo, and the home drives are linked, then the change will take effect in Debian if the user launches xchat.. as an example..

The other option is to change the nit-debian installer to manually set the UID/GID on user creation.. and create the user with UID/GID 29999 .. this way they will match on maemo and debian and no tricks will be necessary for the user to read/write home and /tmp files.

fatalsaint: the 29999 uid/gid is in my commit queue so it will be added when i'm properly online again:)

Re: Right Click in Debian chroot with an n800
 

Hi Qole - While I have not explicitly tested this with the n810 keyboard (due to lacking of an n810), I am under the impression that it is incremental (e.g. it doesn't reset previous items unless specified). I'll try redefining another key and see if it remains preserved through execution of the mouse flipping scripts.

An alternative is for someone more knowledgeable than myself to figure out why that C++ program seems to only affect windows or the root window, but not both at once (although, if it only affects windows, it still could be useful for OS2008 games and the like potentially).

Re: Running Debian in a chroot
 

Benson, there is still something wrong with Debbie. She doesn't play well with the Weasel. "debbie iceweasel" produces an error about you shouldn't be running with sudo and how you should use the -H parameter, then it sits for a while, then silently fails...

PS: I am typing this in Iceweasel ("sudo debian hilda iceweasel" works fine)...

Re: Running Debian in a chroot
 

Hmmmm.... I'll take another look, I guess. Strange, but it's just possible that the brokenness is with the iceweasel script... Just don't take that seriously until I get a chance to check it out; I probably don't have things right yet...

Re: Running Debian in a chroot
 

I was wondering if there is a way to make the softwares fast, specifically the openoffice.I see the loading is slow and also the functionality is slow.for example when you open the File menu, it opens slowly once and then its working normal..same with loading and rendering a document.IS it possible to make the whole process fast.for example by loading the chroot when OS2008 is booted or initialized or maybe preloading the openoffice libraries..maybe I am missing some reading of these threads about performance issues.How to improve the performance..

Re: Running Debian in a chroot
 

Well, here's an upgraded debbie; I will warn that iceweasel now looks horrible here, but I think that's because I clobbered something else, not from debbie.

And I feel quite bad about all the glitches with my scripts; sorry about the inadequate testing. This was, of course, an existing problem, which iceweasel detected properly.

Re: Running Debian in a chroot
 

I wouldn't feel too bad Benson.. this is all bleeding-edge/experimental/development stuff when you get into debian.. if someone thinks they can plop on debian and have everything be perfect at this point they are dreaming... But it's certainly getting there.. and you've been a real help to that end as far as I can see..

Well done!

Re: Running Debian in a chroot
 

Yes he should. :D

Well, to Benson, this stuff has been obvious for a long time.

Yes, Benson has been one of the biggest helps to me all along. My thanks as well.

Re: Running Debian in a chroot
 

debernardis has an openoffice-specific optimization thread here.

There are other, more complicated ways to make things faster, for instance, you can make a new partition and put your Debian stuff there (instead of in the debian.img.ext2 file); that is quite a bit faster.

Re: Running Debian in a chroot
 

I followed your link and read that post. I'll have to give Benson credit -- he even knew the XHTML tags necessary to properly represent "pie in the sky" ideas in the browser.

;)