Chroot environment locks up?

[geekmaster]

When I played with swap files, it was in a debian chrooted K3, using debian apt-get tools. Probably not the busybox version. You would think the busybox version SHOULD work IF they bothered to include it, but then again, that busybox may have been hacked together by the same people that introduced us to 5.1.0.

[aditya3098]

Originally Posted by knc1

Insufficent data to compute an answer.
Please stop wasting our time.

Sorry,
It is still saying "invalid argument" after the mkswap on the kindle.

[UnknownUser]

first off, thanks for all the info guys!
Also, I ran into the same problem with the swap file. It seems that busybox doesnt like using files for swap. heres more info about it from the XDA forums: http://forum.xda-developers.com/arch.../t-586750.html

mounting the file as a loop device works just fine though. for me, here's what I did:
mkswap /mnt/us/swapfile
losetup /dev/loop/7 /mnt/us/swapfile #/dev/loop/7 seems unlikely to be used
swapon /dev/loop/7
free reports 127M of free swap

so with that done, killing a few things (namely framework, pillow, webreader, and kb) I have 200M of free mem plus an additional 127M of swap. looks good to me.

so I tried the chroot env again, still with no luck.
running apt-get update within the chroot freezes up again, this time it got as far as "Reading package lists... 93%", however the same symptoms show up. things freezes up, inside and outside the chroot.
I ran "free" outside the chroot in another shell, and got 7M free, and 154M cached, and the 127M of swap untouched. it seems that memory isnt the culprit here.
Any clues as to where to look next?

[knc1]

Well, if you find you have to use a partition (a device) rather than a file...

Make a file of zeros:
dd if=/dev/zero of=devfile bs=1M count=128

Find first available loop device:
losetup -f
(for example, returns 1)

Turn the file into a block device:
losetup /dev/loop1 devfile

Now setup the entire device (think: swap device) as swap:
mkswap /dev/loop1

Then use that "swap device" for swap:
swapon /dev/loop1

See what "free" has to say;
Also check "cat /proc/swaps"
And "cat /proc/vmstat" will give you an idea of what is happening to your memory.

To reverse the process:
swapoff /dev/loop1
losetup -d /dev/loop1

Which leaves the "devfile" ready to be used next time.
I.E: You don't have to refill it with zeros or run mkswap on it again.

In case memory isn't the problem -
The next question...
enter the chroot, post the output of the "mount" command.

[knc1]

If none of the above fixes your problem, then it probably is because of the release you chose to install with debootstrap.

Why?
The "testing" release has software built for a much newer kernel.

But you only have available the system calls provided by the kernel version that is running the Kindle.
Your apt-get update **should** have bailed out on a -EINV but maybe it didn't.

[geekmaster]

Originally Posted by UnknownUser

first off, thanks for all the info guys!
Also, I ran into the same problem with the swap file. It seems that busybox doesnt like using files for swap. heres more info about it from the XDA forums: http://forum.xda-developers.com/arch.../t-586750.html

mounting the file as a loop device works just fine though. for me, here's what I did:
mkswap /mnt/us/swapfile
losetup /dev/loop/7 /mnt/us/swapfile #/dev/loop/7 seems unlikely to be used
swapon /dev/loop/7
free reports 127M of free swap

so with that done, killing a few things (namely framework, pillow, webreader, and kb) I have 200M of free mem plus an additional 127M of swap. looks good to me.

so I tried the chroot env again, still with no luck.
running apt-get update within the chroot freezes up again, this time it got as far as "Reading package lists... 93%", however the same symptoms show up. things freezes up, inside and outside the chroot.
I ran "free" outside the chroot in another shell, and got 7M free, and 154M cached, and the 127M of swap untouched. it seems that memory isnt the culprit here.
Any clues as to where to look next?

That looks similar to what I did. Loop mounted swap files. Except on a K3, and it let me do bigger stuff. It looks like it helped you some if apt-get made more progress.

Perhaps your apt-get temp or cached files are filling /tmp or /var/local? Make sure they go to /mnt/us...

[aditya3098]

It worked when I put the swap file in the debian.ext3
UPDATE: Only the swap works. It swaped on, but the thing still freezes.
Trying...

[aditya3098]

I wonder if it will work with debian stable/testing/oldstable? My internet is currenty VERY slow...

[UnknownUser]

How would it be possible to fill up /var or /tmp, since apt is chrooted, and there are no mount points for /var or /tmp?
could it be that the image is filling up? 500MB seems like it would be enough though.

when I get back from work, maybe I'll try making a new image from stable, or maybe oldstable like aditya mentioned.

[knc1]

Originally Posted by UnknownUser

How would it be possible to fill up /var or /tmp, since apt is chrooted, and there are no mount points for /var or /tmp?
could it be that the image is filling up? 500MB seems like it would be enough though.

when I get back from work, maybe I'll try making a new image from stable, or maybe oldstable like aditya mentioned.

No mounts within the chroot of /var or /tmp?

That might be your problem.

As I posted above - enter the chroot, type the "mount" command without any options and post the result.

I would also like to see the contents of /proc/self/mounts from inside of the chroot.

[geekmaster]

Originally Posted by UnknownUser

How would it be possible to fill up /var or /tmp, since apt is chrooted, and there are no mount points for /var or /tmp?
could it be that the image is filling up? 500MB seems like it would be enough though.

when I get back from work, maybe I'll try making a new image from stable, or maybe oldstable like aditya mentioned.

Yes. My image kept filling up. I had to keep growing it, but it eventually hit 2GB, and the vfat cannot hold a bigger file. The debian repository cache files take a LOT of space. You can flush them, but you need to get them again to install more stuff.

[UnknownUser]

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)

[knc1]

Originally Posted by UnknownUser

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.

[UnknownUser]

well, quite a bit of info there. sorry about the copy stuff, I'm not really sure how to copy things out of a terminal, especially wthout a middle mouse button...

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

I thought wheezy was the current testing branch, and sid is the unstable branch?

I stuck with my current image, but I'll try again with a squeeze version later. after all the changes you mentioned, changed the /dev mount to --rbind, the symlink for /run was there, but not /tmp, so I fixed that as well. it blew up again -_-
heres the output this time: (double checked for typos )
Get:1 http://ftp.debian.org testing InRealease [190 kB]
Get:2 http://ftp.debian.org testing/main armel Packages/DiffIndex [7876 B]
Get:3 http://ftp.debian.org testing/main Translation-en/DiffIndex [7876 B]
Get:4 http://ftp.debian.org testing/main armel 2012-06-25-0215.32.pdiff [87.0 kB]
Get:5 http://ftp.debian.org testing/main armel 2012-06-25-0215.32.pdiff [87.0 kB]
Get:6 http://ftp.debian.org testing/main 2012-06-25-0215.32.pdiff [6780 B]
100% [5 Packages rred 27.7 MB]

looking at the running processes from outside the chroot, "rred" is stuck, listed as "sync_b" under the WCHAN column, and tinyrot which is frozen as well, is stuck in "sync_p". might that help at all??
theres plenty of free RAM, and I dont believe the image is out of disk space. (without clearing the apt cache from previous crashes, there was still over 200MB of space on the image before trying again)

about the /var/run/lock bit though, should it mount the locks from the original filesystem instead of a new tmpfs? perhaps theres some sort of clash between the two systems accessing the disk?

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

if only I could get the CHANCE to take it down cleanly...I'm still a bit puzzled why theres no way to terminate any of the hung processes. not even a reboot command over ssh brings it down.

[knc1]

Originally Posted by UnknownUser

well, quite a bit of info there. sorry about the copy stuff, I'm not really sure how to copy things out of a terminal, especially wthout a middle mouse button...


I thought wheezy was the current testing branch, and sid is the unstable branch?

I stuck with my current image, but I'll try again with a squeeze version later. after all the changes you mentioned, changed the /dev mount to --rbind, the symlink for /run was there, but not /tmp, so I fixed that as well. it blew up again -_-
heres the output this time: (double checked for typos )
Get:1 http://ftp.debian.org testing InRealease [190 kB]
Get:2 http://ftp.debian.org testing/main armel Packages/DiffIndex [7876 B]
Get:3 http://ftp.debian.org testing/main Translation-en/DiffIndex [7876 B]
Get:4 http://ftp.debian.org testing/main armel 2012-06-25-0215.32.pdiff [87.0 kB]
Get:5 http://ftp.debian.org testing/main armel 2012-06-25-0215.32.pdiff [87.0 kB]
Get:6 http://ftp.debian.org testing/main 2012-06-25-0215.32.pdiff [6780 B]
100% [5 Packages rred 27.7 MB]

looking at the running processes from outside the chroot, "rred" is stuck, listed as "sync_b" under the WCHAN column, and tinyrot which is frozen as well, is stuck in "sync_p". might that help at all??
theres plenty of free RAM, and I dont believe the image is out of disk space. (without clearing the apt cache from previous crashes, there was still over 200MB of space on the image before trying again)

about the /var/run/lock bit though, should it mount the locks from the original filesystem instead of a new tmpfs? perhaps theres some sort of clash between the two systems accessing the disk?



if only I could get the CHANCE to take it down cleanly...I'm still a bit puzzled why theres no way to terminate any of the hung processes. not even a reboot command over ssh brings it down.

The quickest test I can think of is to copy this chroot back off of the Kindle and see if the above also happens under qemu.

You mentioned running the second stage of debootstrap under qemu, so you should not have any trouble doing the normal apt-get update and apt-get dist-upgrade.

Plus - its a lot easier to stop things that Debian starts while running under qemu. ;-)
Plus - qemu is a lot less fragile than the Kindle.

Finding a difference in the behavior will help in determining where to look for the problem.