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

qole | # 251 | 2008-07-26, 08:27 | Report

I PMed Benson the same thing

Stskeeps | # 252 | 2008-07-26, 08:39 | Report

Originally Posted by

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)

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.

Originally Posted by

[*]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

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.

Originally Posted by

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.

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

Originally Posted by

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?"

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.

Originally Posted by

There should never be a point when the user has to touch the command line. Every choice should have a gui menu.

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

Originally Posted by

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.

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)

Originally Posted by

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

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

Originally Posted by

[*]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!),

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

The Following 2 Users Say Thank You to Stskeeps For This Useful Post:
fatalsaint, qole

qole | # 253 | 2008-07-27, 04:49 | Report

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

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

Originally Posted by Benson View Post

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.qole.tar (8.5 KB, 123 views)

Last edited by qole; 2008-07-27 at 05:13.

Benson | # 254 | 2008-07-28, 13:57 | Report

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.

qole | # 255 | 2008-07-28, 15:40 | Report

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

I'll disable the download for now..

qole | # 256 | 2008-07-28, 16:55 | Report

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?

Code:

export GTK_MODULES=libgtkstylus.so

Benson | # 257 | 2008-07-28, 19:34 | Report

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:

Code:

Defaults env_keep+=GTK_MODULES
user ALL = NOPASSWD: /sbin/debian

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.

qole | # 258 | 2008-07-28, 19:51 | Report

Originally Posted by Benson View Post

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

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

Originally Posted by Benson View Post

Modded it to pass environment variables rightly (su was stomping them), but still needs sudoers tweak:

Code:

Defaults env_keep+=GTK_MODULES
user ALL = NOPASSWD: /sbin/debian

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.

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

Benson | # 259 | 2008-07-28, 19:51 | Report

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

Attached Files

debscripts.tar (8.0 KB, 98 views)

ch8xy | # 260 | 2008-07-28, 20:40 | Report

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