K5 Chroot environment locks up?

[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.
The problem came up when I try to use apt. It seems to lock up the entire filesystem somehow. for instance, running apt-get update will freeze in the middle of stuff (not always at the same point mind you...). Anytime any process trys to access parts of the filesystem, they hang as well. for instance, after apt hangs, I can call "ls /" fine, but "ls /mnt/us" will freeze... If I try to access a book from the kindle UI, the UI freezes... only thing I can do is a hard reset to fix it.

Seeing as how other people seem to have gotten this to work already, I'm kinda stuck as to why this is happening. Any advice here would be greatly appreciated!

[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.
The problem came up when I try to use apt. It seems to lock up the entire filesystem somehow. for instance, running apt-get update will freeze in the middle of stuff (not always at the same point mind you...). Anytime any process trys to access parts of the filesystem, they hang as well. for instance, after apt hangs, I can call "ls /" fine, but "ls /mnt/us" will freeze... If I try to access a book from the kindle UI, the UI freezes... only thing I can do is a hard reset to fix it.

Seeing as how other people seem to have gotten this to work already, I'm kinda stuck as to why this is happening. Any advice here would be greatly appreciated!

You need to give a lot more detail of what you have done.

Normally, it would not be possible to "see" parts of the file system outside of the chroot.

So as an example of the missing information:
Did you try the reported "ls" commands from inside of the chroot?
If so, have you done some filesystem commands that make you think you should be able to see the file system outside of the chroot?

What all have you done to start the chroot prior to entering it?

Use this link for reference:
http://www.gerv.net/hacking/how-to-ask-good-questions/

[UnknownUser]

oky then. heres what I've done:

- created a debian disk image using debootstrap, and completeing the --second-stage bit with qemu.
- moved the image onto the /mnt/us partition
- used the script from http://xkid.biz/wordpress/?p=4
- ssh into the kindle
- execute the chroot script
- in the chroot:
--- add debian testing repo into sources.list
--- apt-get update
here the output from apt:
Get:1 http://ftp.debian.org testing InRelease [190 kB]
Get:2 http://ftp.debian.org testing/main armel Packages [5710 kB]
Get:3 http://ftp.debian.org testing/main Translation-en [3886 kB]
100% [2 Packages bzip2 0 B]

- in another ssh session with the kindle, outside the chroot (after apt hangs):
--- ls / (works just fine)
--- ls /mnt (hangs)

also, other programs seem to get stuck.
as mentioned, the framework locks up trying to access a book (the user guide in my case). from running ps outside the chroot, tinyrot also seems to gets stuck, for example.

[geekmaster]

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.
The problem came up when I try to use apt. It seems to lock up the entire filesystem somehow. for instance, running apt-get update will freeze in the middle of stuff (not always at the same point mind you...). Anytime any process trys to access parts of the filesystem, they hang as well. for instance, after apt hangs, I can call "ls /" fine, but "ls /mnt/us" will freeze... If I try to access a book from the kindle UI, the UI freezes... only thing I can do is a hard reset to fix it.

Seeing as how other people seem to have gotten this to work already, I'm kinda stuck as to why this is happening. Any advice here would be greatly appreciated!

This problem was discovered by myself, dasmoover, and others when the K5 first came out. Even a wget can lockup the device. After loop mounting a debian image, while booted from main, there is not enough free RAM to do much that is useful. I verified this with extensive free memory monitoring while trying various commands.

I discovered that loop mounts are MUCH more useful (more free RAM) while booted from diags, which does not load the framework (cvm and Xorg).

If you can stop and unload the framework without making the K5 reboot itself, you may be successful booting from main too. If you just kill cvm or Xorg (commonly done on earlier kindles), the K5 just reboots itself.

In some cases, K5 devices seem to have bricked themselves while trying to use a loop mount, but I think now that it was just a dead battery. Battery charging does not work well while booted from diags (at least on the original diags kernel), and a K5 can act bricked if it has an almost dead battery and an ENABLE_DIAGS file.

You can read more about it in some older posts about optware and loop mounts.

[knc1]

Originally Posted by UnknownUser

oky then. heres what I've done:

- created a debian disk image using debootstrap, and completeing the --second-stage bit with qemu.
- moved the image onto the /mnt/us partition
- used the script from http://xkid.biz/wordpress/?p=4
- ssh into the kindle
- execute the chroot script
- in the chroot:
--- add debian testing repo into sources.list
--- apt-get update
here the output from apt:
Get:1 http://ftp.debian.org testing InRelease [190 kB]
Get:2 http://ftp.debian.org testing/main armel Packages [5710 kB]
Get:3 http://ftp.debian.org testing/main Translation-en [3886 kB]
100% [2 Packages bzip2 0 B]

- in another ssh session with the kindle, outside the chroot (after apt hangs):
--- ls / (works just fine)
--- ls /mnt (hangs)

also, other programs seem to get stuck.
as mentioned, the framework locks up trying to access a book (the user guide in my case). from running ps outside the chroot, tinyrot also seems to gets stuck, for example.

You are running out of free memory without any swap available.

You do not need a lot, just enough to work around some VFS problems not solved until last week's kernel release.
Half of your RAM (128mb) will do fine.

There are network file systems that will let you put the swap on another machine accessed over whatever networking you have installed.
For casual use, not worth the effort.

Your choices are a swap partition or a swap file, in this case choose a swap file.

Yes, you can run swap on the internal eMMC.
Yes, this will generate eMMC wear that would not otherwise happen.
Yes, this will reduce the amount of time before you have to replace it.
Yes, it is difficult to replace and expensive to hire done. Cheaper to just toss the Kindle when the eMMC wears out.

You will be taking a few years off the devices expected ten year useful life. Where you going to keep this Kindle longer than two or three years anyway?

Got all that? Agreed? All right then:
Use dd to make a 128Mb file of zeros (must be zeros for swap, not a sparse file, swap doesn't do sparse files);
Use mkswap on the filename;
Use swapon <filename> and swapoff <filename> as appropriate.

Enjoy.

Edit: As GM points out, keep the Kindle on the charger whenever your using it this way.

The device type which MMC devices are built on does not do "write", only erase and re-program.
The base device is an EEEProm, it generates its erase and programming voltages internally.
The micro-controller in the MMC device just "fakes" the write command with a "read, merge, erase, re-program" sequence in "erase block" size chunks.
Not only power hungry but a slow process.

On the upside, swap only writes in page size (4096byte) chunks and this eMMC has an erase block size of 4096 bytes. So there should not be any "merge" operation if the file location is erase block aligned. Since you are putting this file on FAT-32, you can (manually) diddle with the file alignment with any decent MSDOS disk editor.

[geekmaster]

Originally Posted by knc1

Yes, you can run swap on the internal eMMC.
Yes, this will generate eMMC wear that would not otherwise happen.
Yes, this will reduce the amount of time before you have to replace it.
Yes, it is difficult to replace and expensive to hire done. Cheaper to just toss the Kindle when the eMMC wears out.

You will be taking a few years off the devices expected ten year useful life. Where you going to keep this Kindle longer than two or three years anyway?

I do not know how effective any write wear leveling is in the kindle, but it is MUCH less effective when there is not much free space for it to "load balance" the writes. Many flash devices are not vfat aware, so do not recognize free space from deleted files (only free space left from a low-level format gets used for write wear leveling). More advanced devices and OS software supports TRIM, which does recognize deleted files as free space to use for wear leveling.

In any case, after a kindle has been used awhile, it would be safe to assume that write wear leveling is not effective due to no unused low-level formatted erase blocks.

So, a good rule-of-thumb is to only use a swap file when you need it (such as during a large compile) and turn it off when not required (using swapon and swapoff commands).

[aditya3098]

[root@kindle root]# swapon /mnt/us/swapfile
swapon: /mnt/us/swapfile: Invalid argument

[aditya3098]

[CODE]
[root@kindle root]# swapon /mnt/us/swapfile
swapon: /mnt/us/swapfile: Invalid argument
[CODE]

[knc1]

Originally Posted by aditya3098

[root@kindle root]# swapon /mnt/us/swapfile
swapon: /mnt/us/swapfile: Invalid argument

And the commands / actions which preceded that command?
http://www.gerv.net/hacking/how-to-ask-good-questions/

[aditya3098]

On the host:

$su
$dd if=/dev/zero of=~/swapfile bs=1024 count=100000
$mkswap ~/swapfile
$cp ~/swapfile /media/Kindle
$umount /media/Kindle

And then on the kindle:

[root@kindle root]# swapon /mnt/us/swapfile
swapon: /mnt/us/swapfile: Invalid argument

[knc1]

Is the host running 32bit, Little Endian, ARM?
If not, that is probably your problem.

[aditya3098]

Originally Posted by knc1

Is the host running 32bit, Little Endian, ARM?
If not, that is probably your problem.

aditya@aditya-desktop:~$ uname -a
Linux aditya-desktop 3.2.0-25-generic-pae #40-Ubuntu SMP Wed May 23 22:11:24 UTC 2012 i686 i686 i386 GNU/Linux

[knc1]

A simple "No" would do.
re-run mkswap on the file after you transfer it to the Kindle, using the Kindle's mkswap command.
Swap files have meta-data, which, among other things, prevents you from trying to restore an x86 hibernation image to an ARM machine.

[aditya3098]

Still not working

[knc1]

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