HowTo use chroot for setting current shell`s "/" ?

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

HowTo use chroot for setting current shell`s "/" ?

#1 Post by sunburnt »

I was thinking chroot may solve path problems for running apps. in odd places.
If it will change the root to an apps. dir. in the current running shell,
then all it`s deps. will be found, libs. and all the other files placed in the dir.

As I understand it, the specified dir. will become / for paths starting with / .
I`m not sure what will be different about relative paths, probably nothing.

### Of course if apps. were written with relative paths, then no problem.

From the Man. page for chroot:
chroot changes the root directory to that specified in path.
This directory will be used for path names beginning with /.
The root directory is inherited by all children of the current process.
Error running chroot in an app. dir.:

Code: Select all

sh# chroot /mnt/sdb3/apps_Puppy/breakout2/LBreakout2
chroot: cannot run command `/bin/bash': No such file or directory

### And while trying to run the app.:
sh# chroot /mnt/sdb3/apps_Puppy/breakout2/LBreakout2 bin/lbreakout2
chroot: cannot change root directory to bin/lbreakout2: Not a directory
sh# 
The current path is: /mnt/sdb3/apps_Puppy/breakout2/LBreakout2
And in it is the /dir./file: bin/lbreakout2


### And this:

Code: Select all

cd /new-root
pivot_root . old-root
exec chroot . sh <dev/console >dev/console 2>&1
But when run:

Code: Select all

sh-4.1# pivot_root . old-root
pivot_root: No such file or directory

sh-4.1# pivot_root . ../0
pivot_root: Invalid argument

sh-4.1# pivot_root --help    
BusyBox v1.16.2 (2010-06-19 18:02:46 GMT-8) multi-call binary.

Usage: pivot_root NEW_ROOT PUT_OLD

Move the current root file system to PUT_OLD and make NEW_ROOT
the new root file system
### I don`t get what the last Help line means:
............. Move the current root file system to PUT_OLD

### It`s rather unclear exactly what each of the 2 commands is doing.
.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#2 Post by Karl Godt »

1) then you need a bash binary with its ldd depends in your app dir too, probably all the /bin and /sbin at least if not also /usr/bin .

Its easier to chroot to a complete full installation then into a separate folder on the partition ie chroot /mnt/sdb2 .

2) pivot_root you can see in action in /sbin/init script of Puppy 5 series :

You need to create a folder old_root at least .

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#3 Post by sunburnt »

Hey Karl; I kinda figured the app. dir. might need to be complete.

This is the error with the link: /tmp/0/bin/bash => ../../../bin/bash

Code: Select all

sh-4.1# chroot /tmp/0
chroot: cannot run command `/bin/bash': Too many levels of symbolic links
So I copied the real bash file to /tmp/0/bin and got this error:

Code: Select all

sh-4.1# chroot /tmp/0
chroot: cannot run command `/bin/bash': No such file or directory
The first one saw the link, but it`s like the second one didn`t see bash.

It seems that you`re right... RATS!!!
If you can see a way to get it to work, it might be a real god send.
But it looks like I`m barking up the wrong tree ( Puppy joke :lol: ).

I`m hoping to find a silver bullet that will make misplaced apps. work.
I really don`t like the mixed bag of tricks I`ve used to make AppDirs.
Want something that`s reliable and allows placing the app. anywhere.
The junction would do it, but it has to work for all deps. in all apps.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#4 Post by jamesbond »

The following example works. You need static busybox (get it from puppy's initrd). For chroot example, the busybox needs "sh" applet (try "busybox sh" to see if exist). For pivot_root example, you need busybox with "pivot_root" applet (otherwise you cannot return to your original root and have to reboot - you've been warned). Of course preferably the busybox has "ls", "cat", and other applets for investigation and poking around.

chroot example

Code: Select all

mount -t tmpfs tmpfs /mnt/data
cp /your/static/busybox /mnt/data
chroot /mnt/data ./busybox sh
...
# do anything you want, remember you only have busybox there
# chroot only affect the current shell process
./busybox ls
...
exit  # when done
umount /mnt/data
pivot_root example

Code: Select all

mount -t tmpfs tmpfs /mnt/data
cp /your/static/busybox /mnt/data
cd /mnt/data
mkdir old_root
./busybox pivot_root . old_root
...
# do anything you want, remember you only have busybox there
# pivot_root affects entire system, you see that you won't be able to start anything from the desktop anymore
./busybox ls
./busybox ls old_root
./busybox cat old_root/proc/mounts
...
# when done
./busybox pivot_root old_root old_root/mnt/data
umount /mnt/data
Note: there is also "switch_root", which is used by all current puppies. Warning: DO NOT USE IT, or you will be at the happy end of having your entire / wiped out ...
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#5 Post by sunburnt »

Wow jamesbond, you really are a sleuth and a sneaky guy!

The idea is for a script to do this and run an app. in the new root.
So everything gets dumped when the script`s app. and shell exit.
It seems like that would solve the "not being able to return" problem.

You used tmpfs, is that the only way it`s gonna work?
I`d like to make the app`s. dir. the new root while the app`s. running.

pivot_root has the old root inside it, right?
So it would be possible to get at the rest of the system?
Obviously the O.S. still has to work normally for the app. in the jail.
This seems to be the real problem to overcome, or be defeated by.


This makes the idea of a "junction" or "multi. target link" seem easy.
I was telling Karl that the kernel reads link info. and parses paths.
The current normal link can hold a path, but the kernel can`t use it.
All that`s needed is a little code to thread the 2 processes together.
Making a new link over the old one changes the multi. link`s paths.
So a multi. link in place of /lib or /etc could point to many app. dirs.
As with $PATH, the path order sets hierarchy like a union`s layers.
Much simpler than a union, no cpu load, and none of it`s problems.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

Static busybox

#6 Post by Karl Godt »

Hers a static 1.18.3 upx in case Lupu still uses 1.4 .
Should have all common applets included .

Newer pups may have 1.18, 1.19 or 1.20 i think in intrd.gz

http://murga-linux.com/puppy/viewtopic. ... 889#522807

And yes, i think i have wiped once a full installation too as jamesbond described (was Xubuntu-10.04) or was it rm -rf instead of rmdir .. :Oops:

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#7 Post by sunburnt »

Loosing what`s in the Save file`s bad enough, but a full install.!
If you backup your Save file then recovery is easy.
And don`t you just love those Squash files! A solid foundation...

I really try to stay away from rm -r , it`s a recipe for disaster.

I`ll give the upx file a try and see what luck I have experimenting.

Thanks Karl and jamesbond.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#8 Post by Karl Godt »

And don`t you just love those Squash files! A solid foundation...
I don't know if i love them, but they are really practical and handy .

What i don't love really don't love is the standard Puppy icon for them .
Attachments
application-puppy-sfs-red2.png
(3.03 KiB) Downloaded 2451 times
application-puppy-sfs-red.png
(2.93 KiB) Downloaded 2458 times

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#9 Post by sunburnt »

I agree, it`s pretty ugly, something being squashed makes sense.

I tried to make one, but I don`t know how to work mtPaint.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#10 Post by jamesbond »

sunburnt wrote:Wow jamesbond, you really are a sleuth and a sneaky guy!
You can call M and recommend a promotion for me :) Been tired of living in the fields, too much excitement can get to your nerve :lol:
The idea is for a script to do this and run an app. in the new root.
So everything gets dumped when the script`s app. and shell exit.
It seems like that would solve the "not being able to return" problem.
I'm afraid none can be easily used for that purpose. Chroot is a little bit more prospective.

1. With chroot - the app basically lose all access to the real root; that means if the app uses shared library --- *any share library* (including libc, gtk, etc) --- these shared library must be made available inside the chrooted directory. Symlink isn't enough (because the symlink will point to the original root, which, for all intent and purposes, no longer exist when you run chroot), it has to be the real file. Plus the fact that the app cannot access anything outside the new root - e.g. if the app is an music player, it won't be able to access your MP3 files.
There is a way to go around this, you can make whatever directory in the original root available in the chrooted directory using bind mounts.

2. With pivot_root, I think you can forget it. It changes the root *for the entire system* not only for the shell / app you're trying to run.
You used tmpfs, is that the only way it`s gonna work?
I`d like to make the app`s. dir. the new root while the app`s. running.
In theory this can be used for any filesystem including squashfs, but see my comment above.
pivot_root has the old root inside it, right?
So it would be possible to get at the rest of the system?
yes, but ...
Obviously the O.S. still has to work normally for the app. in the jail.This seems to be the real problem to overcome, or be defeated by.
no, the OS won't work normally after you pivot_root, unless the new root contains all the files used and needed by the OS (which, in this case, you'd end up using something like unionfs anyway)
This makes the idea of a "junction" or "multi. target link" seem easy.
I was telling Karl that the kernel reads link info. and parses paths.
The current normal link can hold a path, but the kernel can`t use it.
All that`s needed is a little code to thread the 2 processes together.
Making a new link over the old one changes the multi. link`s paths.
So a multi. link in place of /lib or /etc could point to many app. dirs.
As with $PATH, the path order sets hierarchy like a union`s layers.
Much simpler than a union, no cpu load, and none of it`s problems.
I'm not sure I'm getting what you mean :oops:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#11 Post by sunburnt »

That`s what I was thinking, all the deps. have to be in the dir. Too much.

Bind mounts are like regular mounts as they cover up what`s preexisting.
So to have /usr/share in the dir. will be a problem mounting on it.
Only paths that don`t exist in the dir. can be brought in, correct?

# I suppose complete stand-alone apps. could work this way?
But it`s hard to see how an app. would show a GUI, or do I/O.


### A multi. target link.

A link: /lib
................... => /usr/lib
................... => /usr/local/lib
................... => /mnt/sdb1/lib

Try this: ln -s /usr/lib:/usr/local/lib:/mnt/sdb1/lib /lib0

Hover over it in ROX Filer and you`ll see the path is there.
But ROX shows it as dead because it`s unusable.

So the kernel just needs a small piece of code to thread it`s
path parsing code with the link recognition code to make it work.
There`s probably other things I haven`t forseen, ROX, etc.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#12 Post by amigo »

You don't have to copy all deps into the chroot. Use 'mount --bind' to make the real root files available inside the chroot. bind them under the dir which will be the chroot before chrooting into the dir. You don't need pivot_root usually -that's usually used at the end of an initrd. Of course I mean to use the *real* mount and not some busybox or script front-end thingy...

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#13 Post by sunburnt »

Thanks amigo, I hope this doesn`t qualify as a "script thingy".


# NEW Update: I have / bind mounted on /tmp/0 for testing.

All of the entire file system is available except mount points.
But the partition links are good in /root, so all of it is accessible.

But it has no $PATH, even though I set it and export it in the script: setchroot.

Code: Select all

#!/bin/sh
#########	Bind mount dirs. and chroot, or exit and umount.

if [ `mount |grep /tmp/0` ];then
	exit
	umount /tmp/0
else
	PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/X11R7/bin:/root/my-applications/bin:/root/my-applications/sbin
	export PATH

	mount --bind / /tmp/0

	[ $? -eq 0 ]&& chroot /tmp/0 &&

		[ $? -gt 0 ]&& umount /tmp/0
fi
# This is looking more possible to do... Now how to add the AppDir.
.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#14 Post by amigo »

chroot should be invoked like this:

Code: Select all

chroot dir command
Also, you need a copy of chroot under the chroot for full functionality. If you want an interactive chroor you call it like this:

Code: Select all

chroot dir /bin/bash
To leave the chroot, use 'exit'. experiment using the 'pwd' command to verify you are really in the chroot.
By 'script thingy', I was referring to that horrendous thing called 'mount' which is used by Puppy. I still cannot understand why you would use such an abhorrant thing -especially when the 'real' thing is there all along (FULL-mount) -oh, but that isn't the real thing either -just a cut-down busybox version....
Another thing, you have doen the easy thing by binding '/' under your chrott, but if you want to limit the 'exposure' or availability of items, you can always create several bind points:

Code: Select all

mkdir mychroot mychroot/etc mychroot/bin
mount --bind /etc mychroot/etc
mount --bind /bin mychroot/bin
Running multiple commands as an argument to chroot is a bit tricky -cat them together into a single variable argument:
CHROOTCMD="first-command ; second-comand"
chroot dir $CHROOTCMD
Or place the command sto be run under the chroot into a script which you copy into the chroot area before running the chroot command:

Code: Select all

mkdir mychroot mychroot/tmp
cp myscript mychroot/tmp/myscript
chroot mychroot /tmp/myscript
In 'src2pkg' I use a combination of 'mount --bind' along with a temporary unionfs to create a safe way to install software in an out-of-the-way place when creating packages -for cases where there is no DESTDIR support. This avoids the problem of having the chroot have read-write access to the bind-ed content.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#15 Post by sunburnt »

As always, you`re a fountain of info. amigo. Thanks!

The Q that comes to my mind is: How would I/O be done?
And how would X and the desktop work if they are not available?
I`m sure there`s probably many things I haven`t even thought of.

It will be tough going listing everything needed in the chroot.
This is why I figured that most of the dir. tree is needed inside.

The mount covers up anything inside, so the same problems still exist.
If a file is needed in /usr/bin and the app. exec. is there too, problem.
Add to $PATH and $LD_LIBRARY_PATH to fix misplaced exec. and libs.
In /usr/share probably only the apps. dirs. are needed, so no mount.


# So the premount chroot dir.: /usr/APP/bin , /usr/APP/lib , /usr/share .
Mount all in: / . And in /usr mount: /bin, /sbin, /lib, /local, /X11R7 .

# Does this sound like a good plan?

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#16 Post by sunburnt »

### FORGET ALL THIS... It`s much too complex and isn`t a solution.


### I finally found what I`ve been looking for.

I wanted a link that points to many targets.
I found a mount that combines many targets ( the reverse ).
It`s like a union without the complexity and problems.
Tests showed it had no cpu load ( it`s just a mount ) and no ram use.!
It can be used to combine partitions into one, and dirs. too.
# And... It got 5 a star rating.!

It`s called "mhddfs", it uses Fuse and is simple to use.
It merged 2 dirs. with files and another with a link as it`s path.
# NOTE: Be sure to use the / at the end of the mount point or it adds /root ( don`t know why...).

Code: Select all

@@@@ To mount:
sh-4.1# mhddfs /tmp/0,/tmp/1,/root/docs/0 /tmp/7/ -o allow_other

mhddfs: directory '/tmp/0' added to list
mhddfs: directory '/tmp/1' added to list
mhddfs: directory '/root/docs/0' added to list
mhddfs: mount to: /tmp/7/
mhddfs: move size limit 4294967296 bytes

@@@@ To unmount:
sh-4.1# fusermount -u /tmp/7

@@@@ This allows all users access. Not just mount creator:
 -o allow_other
There are a few other utilities like it, most are for merging HD partitions.

This will make the difference in easy to make and use app. packages.
And also for rearranging the Linux file system for a new type of O.S.
Attachments
mhddfs_0.1.28-1_i386.zip
From Ubuntu Lucid, so good for most Puppies I think.
Puppy Lucid528 has everything else that`s needed ( Fuse ).
(24.13 KiB) Downloaded 323 times
Last edited by sunburnt on Wed 20 Jun 2012, 08:40, edited 6 times in total.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#17 Post by disciple »

I was looking at that the other day, but I couldn't quite figure out the advantage over unionfs...
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#18 Post by sunburnt »

Simpler is the main thing I see... So fewer problems ( white-out files ).

It seems better suited to combining small parts of the dir. tree than a union.

And with virtually no system usage, you can use it many many times!

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#19 Post by disciple »

How does it enable "deleting" if it doesn't use white out files?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#20 Post by Karl Godt »

sunburnt wrote:Simpler is the main thing I see... So fewer problems ( white-out files ).

It seems better suited to combining small parts of the dir. tree than a union.

And with virtually no system usage, you can use it many many times!
FWIW : I had my first Puppy crash since i upgraded to more recent hardware ( MWDMA 4GB HDD to DMA-100/133 HDD ) with racy-5.2.2 which uses unionfs : X showed console with X-cursor and panic was something with unionfs (flash pendrive PUPMODE=13) .

Racy-5.3 again uses aufs .
I used Unionfs in the kernels in Wary and Racy 5.2.2, and I thought that all was well.
Unionfs letting us down?

Post Reply