Chroot environment locks up?

[knc1]

Originally Posted by UnknownUser

So I created a Debian image file and am trying to set it up as a chroot system on the KT. I tried both creating my own image, and using someone elses image from somewhere on these forums.. can't remember exactly where.

Would you please bring me up to date here?

Are we now using the "someone else's" image?

Are we now using the one you built yourself?
Thread is tagged "K5" - which arch are you using, armel or armhf?

[aditya3098]

Armel, afik

[geekmaster]

dasmoover had a debian image that installed with an extension for yifanlu's touch menu. You could do apt-get to install stuff from the debian repo when chrooted to it.

I also used an arm BackTrack image that was larger than 2GB, so to fit it on vfat, I removed stuff from it I was not using, then copied its files to a 2GB image file. I played with nmap on the kindle a bit. I also had kismet working on the kindle. I also have a working "John the Ripper" that runs on the kindle, but a LOT slower than on a host PC.

But that was on the K3. On the K5, I only had success with chroot on diags. Both I and dasmoover had virtually bricked our K5's trying to do chroots from main (until I developed "select boot" to debrick my and dasmoover's K5s).

[UnknownUser]

Originally Posted by knc1

Would you please bring me up to date here?

I made a new image from stable today, until now, I had been using an image I made from the testing repos. both created with deboostrap with arch=armel.

Both of them freeze while doing things on the kindle, but are fine when copied back to a host PC and ran with user-mode qemu.

with the squeeze image, I didn't need to call apt-update, since it was already done on the host-pc before copying over. I even managed to do an apt-get install from the kindle without it crashing! unfortunately, it wasn't that the problem went away, it just seems like it just managed to finish before freezing. I tryed to install another larger package, and froze while unpacking...
( good news though! I can play tetris as long as I like! )

regarding diags mode, Theres two reasons I see why I don't really want to go that route:
1. no ssh access means I have to flash a new image there, which I'm nt sure I'm ready to do at this point.
2. from information in several posts before, you seem to say that it drains batteries several times faster than main mode.

however I might end up there soon...

[knc1]

Originally Posted by UnknownUser

I made a new image from stable today, until now, I had been using an image I made from the testing repos. both created with deboostrap with arch=armel.

Both of them freeze while doing things on the kindle, but are fine when copied back to a host PC and ran with user-mode qemu.

with the squeeze image, I didn't need to call apt-update, since it was already done on the host-pc before copying over. I even managed to do an apt-get install from the kindle without it crashing! unfortunately, it wasn't that the problem went away, it just seems like it just managed to finish before freezing. I tryed to install another larger package, and froze while unpacking...
( good news though! I can play tetris as long as I like! )

There once was a major problem with "apt-get update" in that it used a tremendous amount of memory.
That should have been dealt with by now, but perhaps it still requires more resources than are available.

One way to minimize the resource requirements -
have an absolute minimum number of repositories listed in /etc/apt/sources.list

If that doesn't do it - now that you are running Deb-6 (which should be a fairly close match in age with the Kindle kernel) - - -
It will not be changing that often - you can copy off you chroot environment file and do the "apt-get update" and "apt-get dist-upgrade" under qemu - say once every 2 or 3 months.

The two hung processes you noticed both take large amounts of ram - the log rotate only needs it briefly but it probably made its request at "just the wrong time" during the apt-get update fetch.

You should be able to manage when (and if) the log rotate daemon runs - it is usually a cron job. Do a crontab -l and edit it with crontab -e as required to make it behave.

PS:
This is not impossible to do - I run Debian on my NSLU-2 with only 32Mbyte of ram, and have successfully rebuilt the Debian base install packages from source (twice).
Added note: It does take awhile - like days, its only a 233Mhz machine.

[geekmaster]

Originally Posted by UnknownUser

regarding diags mode, Theres two reasons I see why I don't really want to go that route:
1. no ssh access means I have to flash a new image there, which I'm nt sure I'm ready to do at this point.
2. from information in several posts before, you seem to say that it drains batteries several times faster than main mode.

however I might end up there soon...

No need to flash diags_ssh. That was just for convenience. You really only need to copy the missing /usr/local files (dropbear). I also changed the PW to mario, but that is optional. You can copy those files with a RUNME.sh script...

There have been reports of some newer firmware erasing files from /usr/local to break SSH on a reboot though...

P.S. On my K3, running in chroot, it took 12 hours to build X11. Builds in a K5 should be faster...

[ThomasT]

The same problems with apt-get as described above, including a heavily bricked K5, happend to me, too.
After replacing

 mount -o loop -t ext3 /mnt/us/debian.ext3 /mnt/debian

by

 mount -o loop -t ext3 /mnt/base-us/debian.ext3 /mnt/debian

everything works fine.
This avoids file transfers through that strange mount loop on /mnt/us. RAM monitoring with

 free -s 5

shows always more than 6 MB free RAM.

As I don`t understand that strange /mnt/us loop, I don`t know, whether this is save. Up to now it works.

BTW: I have no swap file/partition. Debian version is testing. /etc/issues says wheezy/sid.

[geekmaster]

Originally Posted by ThomasT

The same problems with apt-get as described above, including a heavily bricked K5, happend to me, too.
After replacing

 mount -o loop -t ext3 /mnt/us/debian.ext3 /mnt/debian

by

 mount -o loop -t ext3 /mnt/base-us/debian.ext3 /mnt/debian

everything works fine.
This avoids file transfers through that strange mount loop on /mnt/us. RAM monitoring with

 free -s 5

shows always more than 6 MB free RAM.

As I don`t understand that strange /mnt/us loop, I don`t know, whether this is save. Up to now it works.

BTW: I have no swap file/partition. Debian version is testing. /etc/issues says wheezy/sid.

That is strange, but interesting. I and others have experienced locked up kindles when using loop mounts on /mnt/us. But I thought we were supposed to avoid using /mnt/base-us/.

Can somebody please explain the difference between /mnt/us and /mnt/base-us, and when we should use which one, and why the startup scripts generally use /mnt/us?

Is there a reason why a loop mount would hang on /mnt/us but work on /mnt/base-us, or is that just coincidental here?

Thanks.

[twobob]

Originally Posted by geekmaster

That is strange, but interesting. I and others have experienced locked up kindles when using loop mounts on /mnt/us. But I thought we were supposed to avoid using /mnt/base-us/.

Can somebody please explain the difference between /mnt/us and /mnt/base-us, and when we should use which one, and why the startup scripts generally use /mnt/us?

Is there a reason why a loop mount would hang on /mnt/us but work on /mnt/base-us, or is that just coincidental here?

Thanks.

When they are mounted /mnt/us has exec permissions and the other does not.

That is of course only from my reading of the DIAGS monolithic startup script.
but I have to believe the code is cut-pasted from the main startup. but in terms of mounting details the permissions are set differently

permissions based nomenclature. If there was another permission I missed then you can find it in the upstarts mount section but that was the big difference I noticed between the two calls.

[knc1]

Anything that upsets the operation of the kernel's VFS layer should have left messages in the kernel message file.

That message may not have survived the system hang.
If that is why no message is seen, monitor the kernel's operator console port.

[eureka]

Originally Posted by geekmaster

Can somebody please explain the difference between /mnt/us and /mnt/base-us, and when we should use which one, and why the startup scripts generally use /mnt/us?

/mnt/base-us is the real partition mounted. A filesystem proxy /sbin/fsp (built on top of FUSE) sits between /mnt/us and /mnt/base-us, so that requests to /mnt/us are passed through that proxy to /mnt/base-us.

Unfortunately, I don't know for sure whether these requests are modified by proxy in any way and, if so, when and how they are modified.

Once I've read on this forum that fsp serves for holding requests on pause if real parition isn't available at the moment. But I didn't check this theory (or, maybe, fact?) by myself, because I don't know how to do it.

[geekmaster]

Originally Posted by eureka

/mnt/base-us is the real partition mounted. A filesystem proxy /sbin/fsp (built on top of FUSE) sits between /mnt/us and /mnt/base-us, so that requests to /mnt/us are passed through that proxy to /mnt/base-us.

Unfortunately, I don't know for sure whether these requests are modified by proxy in any way and, if so, when and how they are modified.

Once I've read on this forum that fsp serves for holding requests on pause if real parition isn't available at the moment. But I didn't check this theory (or, maybe, fact?) by myself, because I don't know how to do it.

So perhaps the proxy /mnt/base-us is what prevents the loop mount lockups by modifying or delaying loop accesses to /mnt/base /mnt/us?

[eureka]

Originally Posted by geekmaster

So perhaps the proxy /mnt/base-us is what prevents the loop mount lockups by modifying or delaying loop accesses to /mnt/base?

But there is no /mnt/base.

[geekmaster]

Originally Posted by eureka

But there is no /mnt/base.

Typo. Fixed. See previous post.

[eureka]

Originally Posted by geekmaster

So perhaps the proxy /mnt/base-us is what prevents the loop mount lockups by modifying or delaying loop accesses to /mnt/base /mnt/us?

Perhaps. Perhaps not. I don't know for sure. (BTW, it is /mnt/us => proxy => /mnt/base-us, not the other way. Access to /mnt/base-us isn't proxied.).