Quote:
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.