View Single Post
Old 06-25-2012, 09:26 PM   #28
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by UnknownUser View Post
heres the output from mount, from inside chroot:
/dev/loop/2 on / type etx3 (rw,noatime,errors=continue,data=writeback)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
none on /proc type proc (rw,nosuid,nodev,noexec,relatime)
none on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
Hmm...
That must have been retyped, not a cut and paste (s/etx3/ext3/g).

That is a chroot with the minimum general requirements to run.

First, let us not use a moving target (testing), set it up for wheezy (Debian-7) - - which is what "sid" is at the moment.

You will be making these changes from outside of the chroot, without entering (starting) it, so I have used <whatever_path> to indicate your path to the chroot directory location.

In <whatever_path>/etc/apt/sources.list:
deb http://<the same url>/ wheezy main

Or - the current (Debian-6) "squeeze"
That would have less chance of being too new for the Kindle kernel.

Your choice on the above, but when staying with Deb-7 ...

There have been some changes to the FHS implemented in Deb-7

You should find a <whatever_path>/run directory in the chroot tree.
During the transition:
make <whatever_path>/var/run a sym-link to <whatever_path>/run
make <whatever_path>/var/tmp a sym-link to <whatever_path>/tmp

(Your debootstrap **should** have done those things for you, maybe it didn't.)

Look at whatever your using for a chroot setup routine (be it a script or just the commands you manually enter to make it runnable) ....

You will find the usual:
mount -t proc proc <whatever_path>/proc
mount -t sysfs sysfs <whatever_path>/sys
mount --rbind /dev <whatever_path>/dev
(check that one, your report looks like --bind was used, not --rbind - but then your report isn't a cut and paste, so I can't know for certain.)

In addition to that, you should find:
mount -t tmpfs tmpfs <whatever_path>/run
mkdir -p <whatever_path>/run/{lock,shm}
mount -t tmpfs tmpfs <whatever_path>/run/lock
mount -t tmpfs tmpfs <whatever_path>/run/shm
mount -t tmpfs tmpfs <whatever_path>/tmp

Enter the chroot and try again - it might not even blow up, but if it does, just post the details.

Remember that after you exit the chroot, you have to undo the "make runnable" steps in the reverse order.
AND there isn't an --runbind equivalent, you get to umount /dev/pts and any other sub-directories of /dev before you can umount /dev.

You should not get any "device busy" messages while taking down the chroot structure from outside of it.
If you do - then either something is still running inside, or you are doing the umounts in the wrong order. THINK! (en_IBM).

If you should do an "apt-get install ..." inside of the chroot, remember that Debian will gratuitously start any daemons involved.
You will have to stop those manually before exiting the chroot with the respective /etc/init.d/<feature> stop command.

Usually, you will get a lot of experience using lsof before you can get the chroot taken down cleanly.

Last edited by knc1; 06-25-2012 at 09:32 PM.
knc1 is offline   Reply With Quote